Spec Kit

Le toolkit spec-driven de GitHub

Spec Kit est le toolkit open source publié par GitHub (Microsoft) sous licence MIT pour pratiquer le spec-driven development : la spécification fait office de contrat, le code en dérive, et des points de relecture recommandés jalonnent chaque artefact. Le dépôt crédite les travaux de John Lam. Den Delimarsky l'a présenté sur le blog de GitHub le 2 septembre 2025 ; la version 1.0 est sortie le 21 août 2026, un an jour pour jour après la première release publique.

Le projet a franchi les 132 000 étoiles GitHub en août 2026 selon la revue Vibecoding (127 800 le 14 août 2026 selon Wavect), des ordres de grandeur horodatés. Il s'utilise avec plus de trente agents de code, dont GitHub Copilot, Claude Code, Gemini CLI, Cursor et Codex : chacun apporte son propre agent, sans surcoût de modèle. La surface de commandes a bougé au fil des versions : le préfixe est désormais « /speckit.* », la ligne 0.16 installe les skills par défaut et la 0.10.0 avait retiré les flags « --ai », ce qui a cassé les tutoriels antérieurs. Spec Kit propose aujourd'hui trois processus : le Spec-Driven Development dans le cœur, le bug fixing et l'idea assessment en extensions optionnelles.

Le cycle en sept temps

L'installation passe par « uv tool install specify-cli » puis « specify init ». Le cycle SDD enchaîne ensuite sept commandes, chacune produisant un fichier Markdown diffable, versionné avec le code. L'exécution reste séquentielle : les tâches tournent une à une, sans parallélisation native.

• Constitution (équipe) : les règles non négociables du projet.
• Specify (agent et humain) : la spécification fonctionnelle, centrée sur le quoi et le pourquoi.
• Clarify (l'humain répond) : point de contrôle recommandé avant la planification.
• Plan (agent et humain) : le plan technique.
• Tasks (agent) : le découpage en tâches.
• Analyze (agent et humain) : vérification de cohérence.
• Implement (agent et développeur) : l'exécution.

Lecture dans le SDLC SFEIR

Rapporté au SDLC augmenté par l'IA de SFEIR, Constitution tient le rôle de Setup ; Specify et Clarify portent Define, Plan et Tasks portent Plan, Analyze sert de contrôle en Review, Implement couvre Build et Verify. La capitalisation reste hors du cycle, et Ship, Ops et Deprecation restent hors champ. SFEIR retient la spec comme contrat et les points de contrôle jalonnés, et ajoute les gates humains formels (Plan isolé, Ship), la capitalisation en deux temps (Compound-1, Compound-2) et la couche aval. La grille complète figure dans le comparatif des méthodes de développement avec agents, l'analyse détaillée dans Spec Kit, la spécification comme contrat.

Forces, limites et voisins

Le parti pris tient en une formule du projet : passer de « code is the source of truth » à « intent is the source of truth ». Clarify, la checklist et Analyze donnent des endroits où rejeter ou affiner avant que le code ne se multiplie. Colin Eberhardt (Scott Logic) a publié le 26 novembre 2025 la critique la plus nette, « Radical Idea or Reinvented Waterfall? » : une « mer de markdown », du temps passé à corriger des specs générées, une inadéquation aux travaux exploratoires. Les documents gouvernent le code par convention, sans mécanisme qui l'impose, et sur un système brownfield multi-modules la structure produit du volume plus que de la fidélité.

Spec Kit convient aux fonctionnalités conséquentes, au travail à plusieurs ou en contexte réglementé, moins aux prototypes jetables et aux petites corrections. Recommandation raisonnable : le piloter sur trois à cinq fonctionnalités représentatives, mesurer le temps de clarification, les défauts échappés et les retouches, et garder tests, revue de sécurité et approbation humaine hors du modèle. Dans la même famille, Kiro porte le spec-driven dans l'IDE d'AWS et OpenSpec vise le brownfield léger : Hashrocket situait en octobre 2025 un changement OpenSpec autour de 250 lignes, contre environ 800 pour Spec Kit (voir OpenSpec, le spec-driven taillé pour le code que vous avez déjà).