La spec vient en premier.Et vous la lisez avant le code.

La boucle : spec, relecture, plan, relecture, tâches, construction

Au lieu d’un gros prompt et d’un tas de code, le travail passe par des documents, chacun vérifié par vous avant l’écriture du suivant.

1. Spec : quoi et pourquoi

   Ce que la fonctionnalité doit faire, pour qui, et ce qu’elle ne doit pas faire. Pas de noms de fichiers, pas encore de choix techniques.

2. Plan : comment

   L’approche : quelles parties changent, dans quel ordre, avec quels risques. Le plan répond à la spec.

3. Tâches : petites étapes

   Une checklist que l’agent peut parcourir et cocher, chaque tâche assez petite pour être vérifiée.

4. Construction

   C’est seulement maintenant que l’agent écrit du code, à partir de documents que vous avez déjà lus.

Un modèle de spec court

Une spec n’a pas besoin d’être longue. Six titres suffisent pour repérer la plupart des malentendus :

# Feature name

## Goal
## Non-goals
## Users
## Requirements
## Edge cases
## Open questions

Non-goals et Open questions sont ceux que l’on saute et dont les agents ont le plus besoin. Un agent à qui l’on dit ce qu’il ne faut pas construire, et ce qui reste à décider, pose des questions au lieu de deviner.

Le faire dans Claude Code, Codex et Cursor

Tous les trois peuvent écrire les documents, et chacun a un plan mode pour l’étape de planification : le plan mode de Claude Code, le plan mode de Codex et le plan mode de Cursor.

Pour rendre la relecture automatique, mettez une règle dans CLAUDE.md ou AGENTS.md : après avoir écrit une spec ou un plan, l’agent vous l’envoie avec request_review dans DotMD et attend. L’agent s’arrête alors après chaque document et attend vos commentaires ou votre approbation, sans consommer de tokens pendant l’attente. DotMD peut ajouter la règle pour vous : voir CLAUDE.md et AGENTS.md.

Une relecture qui passe à l’échelle

Le chat est un mauvais endroit pour relire un document. Vous lisez plutôt la spec mise en forme dans DotMD, vous sélectionnez le passage faux et vous appuyez sur ⌥⌘M. Le commentaire est lié à ses lignes, l’agent sait donc exactement de quoi vous parlez. Vous pouvez écrire tous les commentaires d’abord et les envoyer d’un coup.

Quand l’agent les a corrigés, chaque changement s’affiche dans le fichier : ancien texte en rouge, nouveau en vert, à côté du commentaire auquel il répond. Accept ou Reopen pour chacun. DotMD liste aussi les changements que personne n’a demandés. Voir Relire les changements.

Pour un second avis, faites d’abord relire par un autre agent. Une spec écrite par Claude Code et commentée par Codex vous arrive avec les lacunes évidentes déjà signalées, et vous décidez quelles remarques l’auteur reçoit : Un agent relit un agent.

Outils pour le développement piloté par la spec

• Du Markdown simple dans le dépôt. Un dossier docs/specs et le modèle ci-dessus forment une installation complète.
• Les plan modes. La façon propre à chaque agent de planifier avant de construire.
• GitHub Spec Kit. Une boîte à outils open source qui donne à votre agent des commandes pour chaque étape et écrit spec.md, plan.md et tasks.md pour vous : GitHub Spec Kit.

Quel que soit votre choix, les documents sont des fichiers Markdown, et DotMD les lit tous.

Questions sur le développement piloté par la spec

Plus de questions