Implémentation TDD

VérifiéSûr

Remplacer les déclarations mock par du code réel, garantir la parité des signatures et exécuter les vérifications et tests jusqu'au vert.

Spar Skills Guide Bot
DeveloppementAvancé
23/07/2026
Claude Code
#tdd#effect-ts#type-safety#test-driven-development#workflow

Recommandé pour

Synthèse automatique

Cinquième étape du workflow TDD Weft : remplace les mocks `declare` par du code réel en conservant exactement la même surface d'exports, puis boucle jusqu'à ce que les vérifications et les tests passent.

Points forts

  • Impose une passe explicite de parité de signatures entre les exports implémentés et la surface mockée, là où le typecheck seul est insuffisant
  • Boucle verte outillée avec `vp check --fix` puis `vp run check` et `vp run test`, en évitant les faux positifs de la règle du pack
  • Règle de pause claire : toute déviation renvoie vers /spec et /mock plutôt que de laisser dériver silencieusement le code
  • Fournit des standards d'implémentation précis (Effect, erreurs typées, Services/Layers, Schema aux frontières I/O)

Limites

  • Fortement couplé à l'écosystème Weft : commandes `vp`, `graphify` et étapes /spec, /mock, /unit-test, /e2e supposées existantes
  • Ne couvre que l'étape d'implémentation ; il faut avoir déjà produit des tests en échec via /unit-test
  • Les standards imposés (Effect, pas de JSX) sont prescriptifs et peu adaptés à une base de code non-Effect
Quand l'utiliser

À utiliser juste après /unit-test, quand les mocks et les tests rouges existent et qu'il faut écrire l'implémentation réelle.

Quand l'éviter

À éviter si vous n'utilisez pas le workflow Weft ou si aucun mock ni test en échec n'a encore été produit.

Analyse de sécurité

Sûr
Score qualité80/100

The skill is a conventional TDD implementation loop: replace `declare` mocks with real code, then iterate lint/typecheck/test until green, plus an AST-only graph update. The only commands invoked are project-local build/test CLIs (`vp`, `graphify`); there is no network fetchery, no curl|sh, no credential access, no destructive filesystem operations, and no instruction to bypass safety checks. The `--fix` step mutates files but is bounded to formatting/lint repair, which is inherent to the stated task.

Points d'attention
  • •Runs project build/test tooling (`vp check --fix`, `vp run check`, `vp run test`) that auto-edits source files; scope is limited to formatting/lint/typecheck fixes.
  • •No allowed-tools declared, so the agent's tool permissions are unbounded by this file, though nothing in the instructions abuses that.
Comment cette analyse est faite

Exemples

Passer au vert après le mock
Les tests de /unit-test sont rouges et les mocks sont en place dans src/billing/invoice.ts. Lance /implement pour remplacer les declares par la vraie implémentation et boucler jusqu'à ce que vp run check et vp run test passent.
Vérifier la parité de signatures
/implement — implémente les fonctions mockées de src/auth/session.ts, puis fais la passe de parité de signatures contre la surface du mock et signale toute divergence avant de continuer.

name: "implement" description: "Step 5 of the Weft TDD workflow. Use after /unit-test's red phase: replaces the declare mocks with real code in-place, enforces signature parity with the mock surface, and loops vp check --fix → vp run check → vp run test until green. Finishes with graphify update."

/implement: Implementation + green loop (TDD step 5)

Replace the declare mocks with real code, keeping the surface identical, until all checks and tests are green.

When to run

  • Previous step: /unit-test (tests exist and a red run is recorded).
  • Next step: /e2e.
  • Gate (exit): vp run check and vp run test both green, signature parity confirmed, graphify update . run.

Procedure

  1. Replace mocks in-place. In the feature's source file, replace each declare statement with its real implementation. Same file, same exports, same signatures. Keep the JSDoc written in /mock (update prose only if behavior details demand it).

  2. Implementation standards: Effect patterns throughout, tagged errors (the union declared in /mock), Services/Layers for shared capabilities, Schema at unknown/I-O boundaries, pipe(effect, ...) preferred, Option for optionality, readonly data, explicit type guards. Effect.gen vs pipe by readability. No JSX-style patterns.

  3. Signature-parity pass (explicit, not assumed). Diff the implemented exports against the mock surface committed in step 2:

    • No export added, removed, or renamed.
    • No signature changed (parameters, return types, generics, error union).

    Typecheck alone does not catch additions or loosened types. Do this pass deliberately. Any deviation triggers the pause rule: stop implementing, return to /spec and /mock to update spec + surface (and /type-tests + /unit-test if affected), then resume here.

  4. Green loop. Repeat until both are clean:

    1. vp check --fix: auto-fix formatting/lint (safe here: packages just packed by the run tasks).
    2. vp run check: pack, then format/lint/typecheck. Must be green.
    3. vp run test: pack, then run all node/jsdom tests. Every test from the red phase must now pass; no other test may regress.

    Never use bare vp check / vp test as validation. They skip pack and report false cross-package errors (the pack rule).

  5. Update the knowledge graph: run graphify update . (AST-only, no API cost).

  6. Hand off. Next step is /e2e.

Rules

  • Implementation must match mock signatures exactly and behavior must match specs.md.
  • If implementation reveals mocks/specs need changes, apply the pause rule: update specs and mocks first, never drift silently.
  • Fix the implementation to satisfy the tests; changing a test is only legitimate when the pause rule has first changed the spec it encodes.

Du fichier au premier essai

Le téléchargement contient exactement le contenu affiché sur cette fiche. Cette copie peut différer de la dernière version du dépôt source.

Consulter la source et ses fichiers annexes

Ce téléchargement contient uniquement SKILL.md. Les scripts, références, modèles et dépendances éventuels ne sont pas inclus. Récupérez les fichiers nécessaires depuis la source en conservant leur arborescence avant de poursuivre.

1. Télécharger le fichier

Télécharger SKILL.md

Depuis la racine d’un projet de test, enregistrez le fichier sous .skill-downloads/tdd-implementation-mrx3xzr7/SKILL.md, ou utilisez la commande suivante. Ce dossier sert à examiner la skill avant son installation.

Commande pour macOS/Linux ou WSL : un shell POSIX et curl sont nécessaires. Sous Windows sans WSL, utilisez le bouton de téléchargement et créez le dossier manuellement.

mkdir -p '.skill-downloads/tdd-implementation-mrx3xzr7' && curl --fail --show-error --location 'https://skills-guides.com/api/skills/tdd-implementation-mrx3xzr7/download' --output '.skill-downloads/tdd-implementation-mrx3xzr7/SKILL.md.part' && mv '.skill-downloads/tdd-implementation-mrx3xzr7/SKILL.md.part' '.skill-downloads/tdd-implementation-mrx3xzr7/SKILL.md'

2. Vérifier les prérequis

Lisez SKILL.md avant de l’utiliser. Si le fichier cite des scripts ou services externes, examinez-les et préparez les accès nécessaires dans votre environnement de test.

Aucune section de prérequis reconnue dans ce fichier. Cela ne signifie pas qu’il est autonome : les bibliothèques, outils et accès peuvent être cités ailleurs dans le contenu ou dans le dépôt source.

Les plateformes de la fiche sont des indications du catalogue. Les chemins ci-dessous suivent la documentation des outils ; ils ne prouvent pas que cette skill y a été exécutée. Aucune version minimale de ces outils n’est attestée pour cette fiche.

3. Charger la skill

Après vérification, copiez le dossier complet dans le projet avec l’une des commandes ci-dessous, puis ouvrez une nouvelle session de l’outil. La commande s’arrête si un dossier du même nom existe déjà : comparez les fichiers avant de le remplacer.

Claude Code
test -f '.skill-downloads/tdd-implementation-mrx3xzr7/SKILL.md' && test -s '.skill-downloads/tdd-implementation-mrx3xzr7/SKILL.md' && mkdir -p '.claude/skills' && test ! -e '.claude/skills/implement' && cp -R '.skill-downloads/tdd-implementation-mrx3xzr7' '.claude/skills/implement'

OpenSkills

OpenSkills doit déjà être installé. La procédure locale install/read est contrôlée avec OpenSkills 1.5.0, qui exige Node.js ≥ 20.6.0. Aucun slug du catalogue n’est résolu automatiquement.

Installation officielle d’OpenSkills
openskills install './.skill-downloads/tdd-implementation-mrx3xzr7'

openskills read 'tdd-implementation-mrx3xzr7'

La lecture doit afficher le contenu du fichier installé et son dossier de base. Elle ne lance ni la skill ni ses dépendances.

Pour un agent qui lit AGENTS.md, synchronisez ensuite l’index. Cette commande modifie AGENTS.md : relisez le diff avant de l’utiliser.

openskills sync

Mode manuel ou autre outil : joignez SKILL.md à une conversation, ou ouvrez-le dans un agent capable de lire les fichiers. Ajoutez les ressources annexes nécessaires. Il n’existe pas de dossier universel reconnu par tous les outils.

4. Faire un premier essai

Utilisez une entrée courte et fictive : un endpoint d’API, un petit document ou un brief d’interface. Dans une nouvelle conversation, joignez le fichier ou donnez son chemin à l’agent, puis adaptez cette demande :

Lis .skill-downloads/tdd-implementation-mrx3xzr7/SKILL.md et applique ses instructions à cet exemple : [décrire une entrée de test]. Indique les fichiers, dépendances ou accès qui manquent. Produis le résultat demandé par la skill sans inventer de données ni exécuter de script non examiné.

Résultat attendu : une sortie correspondant aux instructions de la skill, ou une liste précise des prérequis manquants. Une simple confirmation de lecture ne valide pas le premier usage. Si une ressource externe est indisponible, ce parcours reste à tester.

Skills similaires