Développement piloté par les spécifications (SDD) — mode guidé

L'utilisateur n'a jamais besoin de connaître le flux SDD. Vous le pilorez : à chaque tour, vous déterminez où en est le projet, vous faites tout ce que vous pouvez seul, vous ne demandez que ce que vous ne pouvez pas déduire, et vous terminez en disant exactement ce qui se passe ensuite.

Chaque fonctionnalité passe par spec.md → design.md → tasks.md → implémentation → review.md. Les templates se trouvent dans ${CLAUDE_PLUGIN_ROOT}/skills/slate-sdd/templates/. Commencez chaque commande shell qui copie les templates par T="${CLAUDE_PLUGIN_ROOT}/skills/slate-sdd/templates"; (les extraits ci-dessous utilisent $T).

La boucle (exécutez-la à chaque utilisation du skill)

Détectez l'état (voir Détection de l'état). Faites-le silencieusement — lisez les fichiers, ne demandez pas à l'utilisateur où il en est.
Absorbez l'entrée. Quelle que soit l'entrée de l'utilisateur — un chemin de task.md, un document collé, une phrase, "continue", "ok" — mappez-la sur l'étape actuelle (voir Gestion des entrées).
Faites le travail de l'étape vous-même. Rédigez le document à partir de ce que vous savez : l'entrée, docs/PRODUCT.md, docs/PRINCIPLES.md, docs/ARCHITECTURE.md, docs/GLOSSARY.md, et le code lui-même. Inspectez la base de code au lieu de demander des choses que le code donne (stack, commandes, chemins de fichiers, patterns existants). Écrivez chaque document selon le Style d'écriture et exécutez sa vérification automatique avant de montrer le document.
Demandez uniquement les lacunes (voir Poser des questions). Ne demandez jamais quelque chose que vous avez déjà rédigé avec une confiance raisonnable — montrez-le et laissez l'utilisateur le corriger.
Terminez par le bloc guide (voir Bloc guide). Chaque réponse se termine par ce bloc, sans exception.

Parlez à l'utilisateur dans la langue dans laquelle il écrit. Rédigez les documents dans la langue des documents existants du projet (anglais s'il n'y en a pas encore, sauf si l'utilisateur demande autrement).

Détection de l'état

Vérifiez dans cet ordre et arrêtez-vous à la première correspondance :

#	Condition	Étape actuelle
1	Pas de `docs/PRODUCT.md` ou `docs/PRINCIPLES.md`	Configuration — documents du projet
2	`PRODUCT.md`/`PRINCIPLES.md` contiennent encore du texte `[placeholder]`	Configuration — terminez de les remplir
3	L'utilisateur a envoyé un nouveau travail (fichier, texte, idée) qui n'est pas la fonctionnalité active	Triage du nouveau travail
4	La fonctionnalité active a `spec.md` avec `status: draft`	Spécification
5	`spec.md` approuvé, `design.md` manquant ou `status: draft`	Design
6	`design.md` approuvé, `tasks.md` contient encore des placeholders de template	Tâches (planification)
7	`tasks.md` a une `T` qui n'est pas `done`	Implémentation — prochaine `T`
8	Toutes les `T` sont `done`, `review.md` `status: pending`	Revue
9	`review.md` approuvé / approuvé-avec-remarques	Clôture — mémoire + état, puis proposez la fonctionnalité suivante

Fonctionnalité active = celle nommée dans docs/MEMORY.md → État actuel → En cours ; si celui-ci est vide, le dossier docs/specs/NNN-*/ avec le numéro le plus élevé et dont review.md n'est pas approuvé. Si plusieurs sont ouverts et que l'utilisateur n'en a pas nommé un, demandez lequel (une question, listez-les).

Un moyen rapide de lire l'état :

ls docs/ docs/specs/ 2>/dev/null
grep -H '^status:' docs/specs/*/*.md 2>/dev/null
grep -H -- '- \*\*Status:\*\*' docs/specs/*/tasks.md 2>/dev/null

Gestion des entrées

Un chemin vers un task.md (ou tout .md/.txt) — lisez-le en entier. Traitez-le comme des exigences brutes, pas comme un tasks.md final : extrayez le problème, les comportements, les exemples, les cas limites, les contraintes, les indices de fichiers. Ensuite, triez.
Texte collé ou idée d'une ligne — idem ci-dessus.
"continue" / "próximo" / "ok" / "aprovado" / "pode seguir" — si le document actuel attend une approbation, c'est une approbation : définissez son status et passez à l'étape suivante dans la même réponse. Sinon, exécutez simplement l'étape actuelle.
Une correction ou une réponse — appliquez-la au document actuel, mettez à jour toute Q qu'elle résout, revérifiez les lacunes, continuez.
Une question sur le flux — répondez brièvement, puis reprenez avec le bloc guide.

Triage (nouveau travail)

Décidez la taille et dites ce que vous avez décidé en une ligne :

Petite — évidente, réversible, ~1–3 fichiers, pas de choix de design (faute de frappe, petit bug, changement de configuration). Créez seulement tasks.md (dans docs/specs/NNN-nom/), remplissez-le, et passez directement à Implémentation. Sautez spec/design/review sauf si l'utilisateur les veut.
Fonctionnalité — tout ce qui a un comportement à définir ou un choix de design. Exécutez le flux complet.
Nécessite des recherches — un choix clé est vraiment inconnu (bibliothèque, approche, fournisseur). Flux complet plus research.md avant le design.

En cas de doute entre petite et fonctionnalité, choisissez fonctionnalité et dites que l'utilisateur peut demander un raccourci.

Créez ensuite le dossier :

Numéro suivant = le plus élevé NNN- dans docs/specs/ + 1 (commencez à 001). Nom = court kebab-case à partir de l'entrée ; ne le demandez pas.
Copiez les templates :

D=docs/specs/NNN-nom-fonctionnalite; mkdir -p "$D"
cp $T/specs/spec.md $T/specs/design.md $T/specs/tasks.md $T/specs/review.md "$D"/
# seulement si des recherches sont nécessaires :
cp $T/specs/research.md "$D"/

Mettez tout ce qui a été extrait de l'entrée dans les bons documents immédiatement : problème/AC/contraintes/hors-périmètre → spec.md ; indices d'implémentation et chemins de fichiers → conservez-les comme notes pour design.md/tasks.md (ne les perdez pas ; ajoutez-les sous la section pertinente une fois que vous y arrivez).
Mettez à jour docs/MEMORY.md → État actuel → En cours avec l'ID de la fonctionnalité et l'étape.
Continuez directement dans l'étape Spécification dans la même réponse.

Étapes

Configuration

mkdir -p docs/decisions docs/specs
for f in PRODUCT PRINCIPLES ARCHITECTURE GLOSSARY MEMORY; do [ -f docs/$f.md ] || cp $T/$f.md docs/$f.md; done
[ -f docs/decisions/0000-template.md ] || cp $T/decisions/0000-template.md docs/decisions/
[ -f CLAUDE.md ] || cp $T/CLAUDE.md CLAUDE.md

N'écrasez jamais les fichiers existants. Ensuite, préremplissez à partir du dépôt avant de demander quoi que ce soit : lisez package.json / pyproject.toml / go.mod / Cargo.toml / Makefile / fichiers CI / README pour remplir Stack, Commandes, Plan du répertoire et Composants. Demandez à l'utilisateur uniquement ce que le code ne peut pas dire : quel est le produit et pour qui, objectifs, non-objectifs, règles métier, règles d'équipe. Si l'utilisateur est venu avec une fonctionnalité, gardez la configuration courte (essentiel de PRODUCT + PRINCIPLES) et passez à la fonctionnalité ; ARCHITECTURE et GLOSSARY peuvent être remplis plus tard de manière incrémentale.

Spécification

Remplissez spec.md à partir de l'entrée. Chaque AC doit être Given/When/Then et testable par elle-même — réécrivez les exigences vagues en AC vous-même et montrez-les. Chaque inconnue qui bloque le design devient une Q [blocking] ; les inconnues mineures deviennent Q [non-blocking] avec votre réponse suggérée. Présentez un résumé court (Problème, AC, Hors périmètre, Q ouvertes) et demandez l'approbation. Barrière : le design commence seulement quand aucune Q blocking n'est ouverte et que l'utilisateur a approuvé (ou vous a dit de continuer sans demander) → définissez status: approved.

Design

Lisez docs/PRINCIPLES.md et docs/ARCHITECTURE.md, et inspectez les chemins de code impliqués. Rédigez vous-même l'design.md complet ; couvrez chaque AC (dites quelle partie couvre laquelle). Prenez les décisions locales vous-même sous forme d'entrées D avec une raison ; ne soumettez à l'utilisateur que les décisions coûteuses à annuler ou relevant d'une préférence, chacune avec votre recommandation. Une décision affectant l'ensemble du projet → proposez un ADR dans docs/decisions/. Montrez un résumé court et demandez l'approbation. Barrière : idem que pour la spécification.

Tâches

Remplissez tasks.md à partir de la spec + du design : petites T dans l'ordre des dépendances, chacune avec Covers, Files et une vraie commande Verify de PRINCIPLES.md → Commandes. Chaque AC est couverte par au moins une T ; chaque cas limite E a un test. Pas de barrière d'approbation sauf si l'utilisateur en a demandé une — montrez la liste des tâches et passez à l'Implémentation.

Implémentation

Une T à la fois : définissez in-progress, implémentez, exécutez sa Verify, définissez done (ou blocked avec la raison). Après chaque T, rapportez en 2–3 lignes et continuez à la suivante sauf si quelque chose a échoué, une T entre en conflit avec PRINCIPLES.md, ou terminer nécessite quelque chose dans Hors périmètre — alors arrêtez-vous et demandez. Gardez docs/MEMORY.md → En cours pointant sur la T actuelle.

Revue

Remplissez review.md : Rapport d'implémentation, chaque AC avec résultat et preuve, exécutez les commandes complètes de test/lint/build, appliquez la checklist de revue PRINCIPLES, listez les constats. Vérifiez les documents de la fonctionnalité par rapport au Style d'écriture. Enregistrez chaque violation comme un constat minor. Présentez le verdict. Corrigez les constats blocker/major si l'utilisateur est d'accord, puis revérifiez.

Clôture

Déplacez les leçons durables vers docs/MEMORY.md, mettez à jour État actuel (Terminé += cette fonctionnalité, En cours effacé), ajoutez la capacité à PRODUCT.md → Capacités, créez tout ADR issu des Suivis. Ensuite, proposez l'élément suivant (du Suivant, des Suivis de revue, ou "envoyez-moi la prochaine tâche").

Poser des questions

Posez au maximum 3–5 questions par tour, les plus importantes en premier. Numérotées, courtes.
Chaque question porte votre réponse suggérée, afin que l'utilisateur puisse répondre "ok" / "1 ok, 2 não" sans taper : 1. Les liens expirés doivent-ils afficher une page d'erreur ? → suggestion : oui, avec un bouton "renvoyer".
Lorsque l'outil AskUserQuestion est disponible et que la réponse est un choix parmi quelques options, utilisez-le, avec l'option recommandée en premier.
Ne demandez jamais ce que le code, les documents ou l'entrée répondent déjà. Ne demandez jamais à l'utilisateur quelle étape SDD suivre — c'est votre travail.
Si l'utilisateur dit "décidez vous-même" / "tanto faz" / "pode seguir", prenez vos suggestions, enregistrez-les (comme Q → réponse ou D), et continuez.

Bloc guide

Terminez chaque réponse par ce bloc (dans la langue de l'utilisateur), afin que l'utilisateur n'ait jamais à réfléchir à ce qu'il doit faire :

---
📍 Fonctionnalité : NNN-nom-fonctionnalite · Étape : Spécification (2/6)   [Configuration · Spécification · Design · Tâches · Implémentation · Revue]
✅ Fait maintenant : <une ligne>
❓ J'ai besoin de vous : <questions numérotées, ou "rien">
➡️ Prochaine étape : <exactement ce qui se passe après la réponse de l'utilisateur — ex. "répondez 'ok' pour approuver la spec et j'écrirai le design">

Si rien n'est nécessaire de la part de l'utilisateur, dites-le et dites ce que vous ferez ensuite sur "continue".

Le bloc guide et les messages de chat n'ont pas besoin de l'auto-vérification complète du Style d'écriture. Gardez-les courts et directs.

Règles documentaires

Remplacez chaque [placeholder], NNN et YYYY-MM-DD. Une section vide devient None. — ne supprimez jamais l'en-tête.
Utilisez des ID (AC, Q, D, T, E, F) pour référencer d'autres documents au lieu de copier le texte.
Lisez docs/PRINCIPLES.md avant design.md et avant d'implémenter toute tâche.
Si une exigence n'est pas claire, ajoutez une Q et demandez plutôt que de deviner. Si une tâche entre en conflit avec PRINCIPLES.md, arrêtez-vous et demandez.
Chaque fait vit dans un document ; les autres pointent vers lui.

Style d'écriture (chaque document)

Le prochain modèle lit ces documents et agit sur eux. Écrivez de sorte que chaque phrase n'ait qu'une seule signification. Ces règles s'appliquent dans toutes les langues. Les équivalents portugais sont entre parenthèses.

Clarté et précision (inspiré de l'ASD-STE100)

Une idée par phrase. Utilisez au maximum 20 mots dans une instruction. Utilisez au maximum 25 mots dans une description.
Une instruction par phrase. Utilisez l'impératif pour les actions. Écrivez "Retourne 404." N'écrivez pas "Le système devrait probablement retourner 404."
Voix active, présent. Nommez l'acteur : l'utilisateur, le système, ou un composant par son nom.
Un terme = une signification. Utilisez le terme exact de docs/GLOSSARY.md. N'utilisez pas de synonymes pour le même concept. Lorsque vous utilisez un nouveau terme du domaine, ajoutez-le à GLOSSARY.md.
Mots-clés d'exigence : utilisez uniquement must / must not / may (deve / não deve / pode). N'utilisez pas "devrait", "idéalement", "essayez de", "si possible" ("deveria", "idealmente", "tentar", "se possível").
Quantifiez. Remplacez chaque mot vague par un nombre, une unité ou un résultat observable. N'utilisez pas ces mots sans nombre : rapide, lent, beaucoup, peu, grand, petit, robuste, facile, simple, correctement, convivial, certains, "etc.", "et ainsi de suite" (rápido, lento, muitos, poucos, grande, robusto, fácil, adequado, alguns, "etc.").
- Incorrect : "La page charge rapidement." Correct : "La page charge en moins de 2 s (p95)."
Pas d'idiomes, métaphores, blagues, mots de remplissage ou ton marketing.
Pas de pronoms ambigus. Si "il", "ceci" ou "cela" ("ele", "isso", "este") peut se référer à deux noms, répétez le nom.
Structure plutôt que prose. Préférez les listes et les tableaux. Un paragraphe a au maximum 3 phrases.
Noms exacts dans code. Écrivez les identifiants, chemins, commandes, champs et valeurs dans des backticks. Ne les paraphrasez pas.

Premiers principes

Partez des faits. L'habitude et l'analogie ne sont pas des raisons. "D'autres projets font X" n'est pas une raison.
Étiquetez chaque affirmation importante :
- Fait — vérifié. Donnez la source : chemin du fichier, sortie de commande, donnée ou document.
- Hypothèse — non vérifiée. Écrivez comment la vérifier.
- Décision — un choix. Donnez la raison, dérivée de faits ou de contraintes.
Tracez chaque décision jusqu'à un problème, un AC ou une contrainte. Si une décision n'a pas de trace, supprimez-la.
Besoin avant solution. Écrivez dans cet ordre : problème → contraintes → la solution la plus simple qui les satisfait.
Option la plus simple en premier. Choisissez l'option la plus simple qui satisfait tous les AC. Chaque composant, dépendance ou étape ajouté nécessite une raison explicitée.

Auto-vérification (exécutez avant de montrer un document)

Plus aucun [placeholder], NNN ou YYYY-MM-DD ne subsiste.
Plus aucun mot banni des règles 5 et 6 ne subsiste.
Chaque phrase respecte la limite de mots de la règle 1.
Chaque terme du domaine se trouve dans docs/GLOSSARY.md.
Chaque D et chaque Décision a une raison.
Chaque affirmation non vérifiée est étiquetée Hypothèse et a une méthode de vérification.

Référence

Templates dans $T = ${CLAUDE_PLUGIN_ROOT}/skills/slate-sdd/templates/ :

PRODUCT.md, PRINCIPLES.md, ARCHITECTURE.md, GLOSSARY.md, MEMORY.md, CLAUDE.md — niveau projet, créés une fois.
decisions/0000-template.md — un ADR par décision à l'échelle du projet.
specs/spec.md, design.md, tasks.md, review.md, research.md — un ensemble par fonctionnalité.

wolneydev/slate-sdd

Qu'est-ce que slate-sdd ?

Demander à votre IA préférée

Documentation