Dev IA Piloté par Specs

Ce que contient ce pack

Ce pack rassemble les cinq outils pilotés par spec qui rendent le coding IA auditable. Chacun s'attaque à une partie différente de la boucle spec → agent → review, et ils se composent bien dans un seul projet.

OpenSpec et Planning with Files sont la paire porteuse. OpenDeepWiki donne à l'agent le contexte de codebase nécessaire pour écrire une spec compétente, et Rivet est la couche visuelle pour les équipes qui préfèrent les graphes de nœuds au markdown.

Pourquoi piloté par specs

Le "vibe coding" — dire à l'agent ce que vous voulez et espérer le meilleur — fonctionne pour de petites tâches et s'effondre sur tout ce qui dépasse une journée. Trois problèmes s'accumulent :

• Drift. L'agent perd la trace de l'intention à travers de nombreux tours. Chaque nouveau tour redérive les buts depuis l'historique de chat, ce qui est lossy.
• Audit. Quand la PR atterrit vous ne pouvez pas dire ce que l'agent pensait construire. Les reviewers reverse-engineerent l'intention depuis les diffs de code.
• Branching. Trois tentatives concurrentes sur la même feature n'ont pas de source de vérité partagée.

Une spec corrige les trois. L'intention vit dans un fichier markdown que l'agent lit à chaque tour (pas de drift). Le diff entre versions de spec est la piste d'audit (pas de reverse-engineering). Les tentatives concurrentes forkent la spec de la même façon qu'elles forkent le code (branching propre).

Installer en une commande

# Installer le pack entier
tokrepo install pack/spec-driven-ai-dev

# Ou choisir la paire cœur
tokrepo install openspec
tokrepo install planning-with-files

OpenSpec atterrit comme répertoire specs/ plus un subagent Claude Code qui le lit et le met à jour. Planning with Files installe un hook qui demande à l'agent d'émettre un PLAN.md avant d'éditer du code. OpenDeepWiki tourne comme processus séparé qui crawl votre repo et sert un wiki interrogeable. Rivet est une app desktop et s'installe via npm install -g @ironclad/rivet.

Pièges courants

• Specs trop grossières. "Construis un flow de checkout" est un objectif, pas une spec. Une spec utilisable liste des critères d'acceptation, cas limites, et items hors-périmètre. Le template OpenSpec impose cette structure ; résistez à l'envie de supprimer les sections que vous trouvez inconfortables.
• Specs trop fines. Une spec de 500 lignes pour un patch de 20 lignes est de la sur-ingénierie. Adaptez la profondeur au risque : petits patches un paragraphe, features multi-semaines le template complet.
• Pourrissement de spec. Quand l'implémentation diverge de la spec, la spec devient un mensonge. L'agent suivra le mensonge. Gardez la spec vivante : chaque PR la met à jour ou note explicitement la déviation.
• Confondre fichiers de planification avec specs. PLAN.md est la trace de raisonnement de l'agent pour le prochain lot de travail ; la spec est l'artefact durable. Ne les confondez pas ; le fichier de plan est jetable.
• Rivet pour tout. Rivet brille pour les flows prompt ramifiés ; il est excessif pour les tâches de coding one-shot. Utilisez-le quand le graphe ajoute de la clarté, pas par défaut.

Relation avec d'autres packs

• Anthropic Builders livre le runtime de l'agent ; ce pack ajoute la couche spec dessus.
• Toolkit Prompt Engineering affine le langage utilisé dans specs et plans.
• Eval & Guardrails LLM vous laisse asserter que la sortie de l'agent matche les critères d'acceptation de la spec.

Quand ce pack seul ne suffit pas

Le dev piloté par specs suppose que vous savez déjà ce que vous voulez. Pour le travail exploratoire — "qu'est-ce que ce produit devrait même être ?" — commencez par un processus de découverte (interviews, prototypes, sketches), puis traduisez les findings en specs. Sauter cette étape produit des specs joliment formatées pour le mauvais produit. Le pack est un multiplicateur de force pour la clarté, pas un substitut.