Flux de travail SDD

Le Spec Driven Development traite les specs comme des contrats de développement vivants. Chaque phase d'implémentation est conditionnée par des critères clairement définis, validés automatiquement à chaque transition.

Le cycle de vie

clarify → create_spec → vérification DoR → implement (PLAN.md) → validate → drift detection → done

Chaque flèche est une porte. Vous ne pouvez pas avancer sans satisfaire la Définition de Terminé de la phase précédente.

Phase 1 — Clarifier

Outils : clarify_requirements, reality_check

Avant d'écrire la moindre ligne de spec, faites émerger les ambiguïtés.

Prompt : "Utilise specforge pour clarifier les exigences pour [fonctionnalité] dans le projet [id]"

clarify_requirements génère une liste ciblée de questions — périmètre, cas limites, exigences non-fonctionnelles, dépendances externes — afin que la spec commence avec une intention claire et sans ambiguïté.

reality_check évalue si les exigences sont faisables compte tenu du contexte actuel du projet. Il détecte les situations "impossible pour vendredi" avant qu'elles ne deviennent de la dette technique.

Phase 2 — Créer la spec

Outils : create_spec, design_schema, define_ui_contract, generate_adr

Prompt : "Crée une spec pour [fonctionnalité] dans le projet [id]"

create_spec génère un HU.md structuré contenant :

Section	Contenu
User Story	Qui, quoi, pourquoi
Critères d'acceptation	Critères testables et sans ambiguïté
Checklist DoR	Portes de Définition de Prêt
Indications schéma BDD	Tables, colonnes, relations
Contrats UI	Contrats de composants, gestion d'état
Indications ADR	Architecture Decision Records
PLAN.md	Plan d'exécution étape par étape

Quand une architecture IA native est détectée, la spec génère également :

• Budgets de latence et chaînes de repli
• Critères de versionnage des prompts
• Exigences d'observabilité LLM

Phase 3 — Vérification DoR

Outils : check_readiness, detect_contradictions

Avant que l'implémentation ne commence, vérifiez que la spec est vraiment prête.

Prompt : "Vérifie si la spec SPEC-003 est prête pour l'implémentation dans le projet [id]"

check_readiness évalue :

• Complétude des critères d'acceptation
• Qualité des critères (testables, sans ambiguïté)
• Statut des dépendances (les specs bloquantes sont-elles résolues ?)
• Conformité à la Constitution

detect_contradictions analyse toutes les specs pour détecter les conflits sémantiques — il détecte les situations où SPEC-A dit "les utilisateurs peuvent supprimer leur compte" et SPEC-B dit "les comptes sont immuables".

Phase 4 — Implémenter

Outils : generate_execution_plan, package_handoff, generate_tests

Prompt : "Génère un plan d'exécution pour la spec SPEC-003 dans le projet [id]"

generate_execution_plan produit un PLAN.md avec :

• Étapes du cycle RED/GREEN/VERIFY
• Étapes parallélisables identifiées
• Propriété des fichiers par étape
• Effort estimé par étape

package_handoff regroupe la spec dans un paquet de transfert structuré pour un agent IA — objectif, critères, liste de fichiers, contraintes — prêt pour une implémentation autonome.

generate_tests produit un plan de tests et des fichiers de tests à partir des critères d'acceptation de la spec.

Phase 5 — Valider

Outils : validate, audit, security_check

Après l'implémentation, vérifiez la couverture :

Prompt : "Valide la spec SPEC-003 contre le code dans /chemin/vers/src"

validate vérifie :

• Quels critères d'acceptation sont couverts par le code
• Lesquels sont manquants ou partiellement implémentés
• Pourcentage de couverture global de la spec

audit note l'implémentation de 0 à 100 pour :

• Principes SOLID
• Code propre
• Conformité architecturale
• Violations de la Constitution

security_check analyse la spec contre l'OWASP Top 10 et scanne le code pour des patterns non sécurisés, générant un score de sécurité (A–F).

Phase 6 — Détection de drift

Outils : detect_drift, reconcile_spec

Au fur et à mesure que les exigences évoluent, maintenez les specs et le code alignés :

Prompt : "Détecte le drift dans la spec SPEC-003 pour le projet [id]"

detect_drift rapporte :

• Les critères qui ne correspondent plus au code
• Les violations de la Constitution introduites depuis la dernière vérification
• Impact en cascade : quelles autres specs sont affectées par le drift

Quand le drift est intentionnel (la spec doit être mise à jour) :

Prompt : "Réconcilie la spec SPEC-003 avec les changements d'implémentation dans le projet [id]"

reconcile_spec présente chaque changement pour approbation individuelle et vérifie la conformité à la Constitution avant de sauvegarder.

La Constitution du projet

La Constitution est un ensemble de principes architecturaux immuables extraits de votre CLAUDE.md, .cursorrules ou d'autres fichiers de configuration d'agents IA.

Prompt : "Initialise la constitution pour le projet [id] depuis CLAUDE.md"

Une fois définie, la Constitution est automatiquement appliquée dans create_spec, audit et detect_drift. Les violations sont signalées avant d'atteindre la revue de code.

Transitions de statut

Statut	Description
draft	Spec créée, pas encore prête
ready	A passé la vérification DoR
in_progress	Implémentation démarrée
review	Implémentation terminée, validation en attente
done	Validée et acceptée
blocked	Bloquée par une dépendance

Prompt : "Mets à jour le statut de la spec SPEC-003 à in_progress dans le projet [id]"

Chaque transition exécute la validation DoR/DoD. Vous ne pouvez pas marquer une spec done sans satisfaire les critères DoD.