spec-driven-development
par addyosmanispec-driven-development est une skill de workflow conçue pour rédiger les spécifications avant le code, puis avancer par étapes — planification, tâches et implémentation — avec une validation humaine à chaque phase.
Cette skill obtient un score de 74/100, ce qui en fait une candidature solide, sans être parmi les toutes meilleures. Pour les utilisateurs de l’annuaire, cela signifie qu’elle est réellement utile pour les agents ayant besoin d’un workflow orienté spécifications, avec assez de structure pour limiter les approximations, mais qu’il lui manque encore des fichiers de support et une documentation packagée pour rendre l’adoption vraiment fluide.
- Déclencheurs d’usage clairement définis : à utiliser au démarrage d’un nouveau projet, d’une fonctionnalité ou d’un changement ambigu, et explicitement pas pour des corrections triviales.
- Workflow opérationnel robuste : quatre phases balisées (Specify → Plan → Tasks → Implement) avec validation humaine à chaque étape.
- Bon niveau de profondeur pratique : un contenu `SKILL.md` riche, avec plusieurs sections, contraintes et exemples de code, qui facilite le suivi du processus par un agent.
- Aucun fichier de support ni commande d’installation : l’adoption repose presque entièrement sur les instructions de `SKILL.md`.
- Livraison en fichier unique : aucun script, aucune référence ni ressource pour renforcer le workflow ou couvrir les cas limites.
Vue d’ensemble de la compétence spec-driven-development
spec-driven-development est une compétence de workflow qui consiste à rédiger d’abord une spécification claire, puis à s’appuyer sur cette spécification pour guider la planification, les tâches et l’implémentation. La compétence spec-driven-development est particulièrement adaptée lorsque vous démarrez une nouvelle fonctionnalité, faites évoluer l’architecture ou partez d’exigences floues et avez besoin de réduire au maximum les hypothèses dans la livraison finale.
À quoi sert cette compétence
Utilisez ce guide spec-driven-development lorsque le principal risque est de construire la mauvaise chose, et pas seulement de la construire mal. Il aide à transformer une idée approximative en source de vérité partagée, qui définit le périmètre, le comportement, les contraintes et les critères d’acceptation avant de passer à l’implémentation.
Cas d’adoption les plus adaptés
Cette compétence convient aux équipes comme aux développeurs solo qui veulent un alignement plus serré avec un relecteur humain, surtout quand une tâche touche plusieurs fichiers, dépend de décisions produit ou est assez vaste pour que “il suffit de coder” entraîne des retours en arrière. Elle est aussi utile pour spec-driven-development dans les workflows de Skill Authoring lorsque vous voulez que la compétence elle-même produise des résultats disciplinés et faciles à relire.
Ce qui la distingue
Sa valeur tient au workflow à étapes verrouillées : spécifier, puis planifier, puis découper en tâches, puis implémenter, avec une validation humaine à chaque étape. Cela la rend plus solide qu’un prompt générique, car elle réduit les hypothèses cachées et force les points de décision plus tôt, au moment où les changements coûtent moins cher.
Comment utiliser la compétence spec-driven-development
Installer et charger le contexte
Pour l’installation de spec-driven-development, ajoutez la compétence à votre configuration d’agent, puis ouvrez d’abord le fichier de la compétence :
npx skills add addyosmani/agent-skills --skill spec-driven-development
Lisez ensuite SKILL.md avant toute autre chose. Ce dépôt n’inclut pas de dossiers d’accompagnement comme rules/, references/ ou scripts/ ; le contexte de la compétence se trouve donc presque entièrement dans le fichier principal de la compétence.
Donner à la compétence un point de départ concret
Le mode d’utilisation de spec-driven-development fonctionne mieux lorsque vous fournissez un objectif, des contraintes et les inconnues déjà identifiées. Une demande faible ressemble à “crée un dashboard”. Une demande forte ressemble à :
“Crée une spec pour un dashboard qui affiche la santé des abonnements, prend en charge les accès par rôles et doit fonctionner avec notre API REST existante. Pose des questions de clarification avant de rédiger la spec. Ne propose pas encore de détails d’implémentation.”
Cela donne à la compétence assez de contexte pour faire ressortir les hypothèses et éviter une conception prématurée.
Suivre le workflow à étapes verrouillées
La compétence est conçue pour s’arrêter à chaque phase jusqu’à validation. En pratique, cela signifie :
- Spécifier le problème et les hypothèses.
- Planifier l’approche une fois la spec approuvée.
- Décomposer le plan en tâches.
- Implémenter uniquement après la revue des tâches.
Si vous sautez les étapes de revue, vous perdez le principal bénéfice de la compétence : moins de reprises dues à des hypothèses non vérifiées.
Lire d’abord, utiliser ensuite
Commencez par SKILL.md, puis servez-vous des sections overview, when to use et du workflow à étapes verrouillées comme règles de fonctionnement. Si vous adaptez cela à votre propre flux d’agent, conservez les points de contrôle de revue et le comportement “poser des questions jusqu’à obtenir du concret”, car ce sont les éléments les plus susceptibles d’améliorer la qualité de sortie.
FAQ sur la compétence spec-driven-development
spec-driven-development est-elle meilleure qu’un prompt classique ?
En général oui lorsque la tâche est ambiguë, transverse ou coûteuse à refaire. Un prompt classique peut produire du code rapidement, mais spec-driven-development est meilleure quand il faut d’abord s’entendre sur ce qu’il faut construire avant que quelqu’un commence à coder.
Quand ne faut-il pas l’utiliser ?
N’utilisez pas la compétence spec-driven-development pour des modifications triviales, des corrections de bugs évidentes ou des changements autonomes sans vraie ambiguïté produit. Dans ces cas-là, la surcharge d’un cycle complet de spec peut être plus lente que le travail lui-même.
Est-ce adapté aux débutants ?
Oui, si vous êtes prêt à répondre aux questions de clarification et à relire les brouillons. La compétence est plus simple à utiliser que d’inventer votre propre processus, car elle indique à l’agent quand s’arrêter, faire ressortir les hypothèses et avancer phase par phase.
Est-ce adapté aux workflows de Skill Authoring ?
Oui, surtout pour spec-driven-development dans Skill Authoring lorsque vous voulez un processus reproductible pour écrire une nouvelle compétence ou faire évoluer une compétence existante. C’est particulièrement utile quand la tâche de création a besoin d’un périmètre clair, de points de validation et d’une spec qui peut être vérifiée avant l’implémentation.
Comment améliorer la compétence spec-driven-development
Fournir des inputs plus précis dès le départ
Les meilleurs résultats viennent d’une description claire de l’utilisateur cible, du résultat attendu, des contraintes et de ce qui reste inconnu. Par exemple : “Migre le flux de checkout sans modifier l’API publique, conserve les événements analytics existants et identifie les risques de dépendance avant la planification.”
Obliger la compétence à nommer les hypothèses
Un mode d’échec courant consiste en des specs vagues qui semblent complètes mais masquent des décisions critiques. Demandez au modèle de lister ses hypothèses avant de rédiger la spec, puis revoyez ces hypothèses avec l’ingénieur humain avant de passer à la planification. C’est souvent là que spec-driven-development fait gagner le plus de temps.
Itérer sur la spec, pas sur le code
Si la première version n’est pas juste, corrigez le périmètre, les critères d’acceptation ou les contraintes avant de demander l’implémentation. Le workflow fonctionne mieux quand chaque révision resserre le contrat, car les phases suivantes dépendent de la précision de la spec.
L’utiliser quand les revues sont coûteuses
La compétence est particulièrement utile lorsque de mauvaises hypothèses coûteraient cher : modifications multi-fichiers, changements d’architecture ou fonctionnalités qui touchent plusieurs parties prenantes. Si la première version de votre spec reste floue, prolongez la phase de spec plutôt que de forcer trop tôt les tâches ou le code.