De la Spec à la Prod : Mon Workflow Skill IA
Livrez du code production avec des agents IA. Un workflow skill en 9 actions : focus, plan, spec-review, spike, ship, review, done. Agnostique.
Je livre des fonctionnalités production plus vite que jamais. Pas parce que j'écris plus de code—mais parce que j'en écris à peine.
La différence, ce n'est pas le modèle IA. C'est le processus autour.
Le Problème
La plupart des développeurs utilisent les agents de codage IA comme une fenêtre de chat. Demander du code, le coller, demander des corrections, perdre le contexte, recommencer. Ça ship—parfois. Mais la qualité est inconsistante, le processus chaotique, et rien ne se transmet d'une session à l'autre.
- Pas de définition claire de 'terminé'
- Pas de code review systématique
- Pas de quality gates sauf si on y pense
- Impossible de reprendre après perte de contexte
- Les apprentissages disparaissent à chaque session
- La spec définit 'terminé' avant que le code existe
- Code review à 9 perspectives, automatique
- Lint, typecheck, build, test à chaque changement
- Le fichier spec permet une reprise de session parfaite
- Rétros et mises à jour mémoire après chaque fonctionnalité
Je voulais un système où je définis quoi construire, et l'agent gère toute la boucle d'implémentation jusqu'à ce que le code soit prêt pour la production.
Alors j'en ai construit un.
Le Workflow Skill
Un cycle de développement structuré pour agents de codage IA. 9 actions, de l'idée au code livré :
| Action | Ce qu'elle fait |
|---|---|
focus | Scanner le codebase pour identifier la prochaine tâche, priorisée par impact |
plan | Créer une spec avec critères d'acceptation et analyse d'impact codebase |
spec-review | Challenge adversarial de la spec avant le début de l'implémentation |
spike | Exploration time-boxée pour les inconnues, décision go/no-go à la fin |
ship | Implémenter, tester, reviewer, corriger—en boucle jusqu'à ce que tous les ACs passent |
review | Code review multi-perspective (9 perspectives, scalée par risque) |
done | Validation finale, rétro, mise à jour mémoire, archivage |
drop | Abandonner proprement, conserver les apprentissages |
workflow | Afficher l'état actuel et suggérer la prochaine action |
L'idée centrale : la spec est la source de vérité. Tout en découle—implémentation, tests, review, validation.
Le Workflow Complet
1. Focus : Sur quoi travailler ?
Pas d'idée de quoi construire ensuite ? Demandez au codebase :
L'agent lance des scans parallèles sur tout le projet—qualité du code, tests manquants, failles de sécurité, problèmes de performance, accessibilité. Les résultats reviennent scorés par impact, effort et risque-si-ignoré.
Il produit une liste de tâches priorisées et crée des specs dans specs/backlog/ pour les éléments prioritaires.
Au lieu de décider quoi faire, le codebase vous le dit.
2. Plan : Définir ce que "Terminé" veut dire
On ne commence pas par le code. On commence par une spec.
L'agent lit d'abord le codebase—patterns existants, code lié, conflits potentiels. Puis il rédige une spec avec :
- Parcours utilisateur : Qui fait quoi, et pourquoi (ACTOR/GOAL/PRECONDITION/POSTCONDITION)
- Critères d'acceptation (ACs) : Format GIVEN/WHEN/THEN—testables, objectifs
- Scope items : Exactement ce qui sera construit, traçable vers les ACs
- Impact codebase : Fichiers concernés, dépendances, breaking changes
La spec passe 13 règles de validation avant le début de l'implémentation. Trop grosse (>8 heures) ? Elle est découpée. Critères d'acceptation vagues ? L'agent refuse.
Aucune spec ne passe la gate si "terminé" n'est pas clairement défini.
3. Spec-Review : Challenger avant de construire
Avant d'écrire une seule ligne de code, challengez le plan :
L'agent lance une analyse adversariale de la spec :
- Cas limites manquants
- Scope qui ne trace pas vers les critères d'acceptation
- Hypothèses potentiellement fausses
- Angles morts dans l'analyse d'impact
Attrapez les problèmes dans la spec—pas en production.
4. Spike : Explorer avant de s'engager
Pas sûr de l'approche ? Lancez une exploration time-boxée :
Limite de temps stricte (défaut 1h, max 4h). Le résultat est une décision GO/NO-GO—pas du code. Le code du spike est jetable, supprimé avant de continuer. L'apprentissage est consigné.
Ça évite de s'engager sur une approche avant de savoir si elle fonctionne.
5. Ship : La boucle d'implémentation
Une fois la spec solide :
L'agent entre dans une boucle :
On ne fait pas du pair programming. On délègue. L'agent gère la boucle. Vous reviewez le résultat.
Deux modes s'adaptent au contexte :
- One-shot : Pas de spec nécessaire pour les quick fixes—crée une spec inline, implémente, valide
- Loop : Une spec active existe—itère jusqu'à ce que tous les critères d'acceptation passent
Les corrections de bugs ont un traitement spécial avec l'Anti-Cascade TDD :
- Baseline : Enregistrer l'état de la suite de tests
- Red : Écrire un test de régression qui échoue
- Green : Implémenter le fix
- Diff : Comparer la suite complète au baseline—détecter les régressions introduites par le fix
- Scan : Chercher le même pattern de bug ailleurs dans le codebase
6. Quality Gates : Validation automatique
Chaque batch d'éditions déclenche un quick pass :
| Gate | Scope |
|---|---|
| Lint | Fichiers modifiés |
| Typecheck | Fichiers modifiés |
Avant de marquer done, un full pass tourne :
| Gate | Scope |
|---|---|
| Lint | Fichiers modifiés |
| Typecheck | Projet complet |
| Build | Projet complet |
| Test | Tests liés |
Le skill auto-détecte l'outillage. Biome ou ESLint ? Vitest ou Jest ? pnpm, yarn ou bun ? Il lit les fichiers de config et se débrouille.
Pas de setup spécial. Validation production dès le premier jour.
7. Review : Neuf perspectives, scalées par risque
Le code review tourne automatiquement pendant la boucle ship—et à la demande :
| Perspective | Question | Quand |
|---|---|---|
| Correctness | Est-ce que ça fait ce qu'il faut ? | Toujours |
| Security | Est-ce sécurisé ? | Toujours |
| Reliability | Est-ce que ça gère les erreurs ? | Toujours |
| Performance | C'est assez rapide ? | Toujours |
| DX | C'est agréable à maintenir ? | Toujours |
| Scalability | État partagé, multi-instance ? | Conditionnel |
| Observability | Debuggable en production ? | Conditionnel |
| Testability | Logique complexe couverte ? | Conditionnel |
| Accessibility | Clavier, lecteur d'écran, contraste ? | Conditionnel |
La profondeur du review s'adapte au risque :
| Scope | Profondeur |
|---|---|
| 1-2 fichiers, risque faible | Rapide (5 perspectives) |
| 3-5 fichiers | Standard |
| 6+ fichiers ou risque élevé | Approfondi (les 9) |
| Contexte de déploiement détecté | Mode production |
8. Done : Valider, apprendre, archiver
Quand tout passe :
Validation finale :
- Tous les critères d'acceptation passent
- Quality gates verts
- Les nouveaux comportements ont de nouveaux tests
- Pas de problèmes bloquants en review
Puis une rétro tourne automatiquement :
- Estimation vs temps réel
- Ce qui a marché, ce qui n'a pas marché
- Patterns appris
L'agent propose des mises à jour mémoire—patterns de codage, conventions du projet, anti-patterns découverts. Elles sont écrites dans la config de votre agent pour que la prochaine session démarre plus intelligente.
La spec s'archive dans specs/shipped/. Historique consigné. Savoir conservé.
9. Drop : Abandonner sans perdre
Parfois une fonctionnalité ne fonctionne pas :
Capture pourquoi c'est abandonné. Préserve les morceaux réutilisables. Documente les leçons "si on y revient." Archive dans specs/dropped/.
Pas d'abandon silencieux. Chaque fonctionnalité abandonnée enseigne la suivante.
Pourquoi ça produit du meilleur logiciel
Qualité spec-driven
La spec définit ce que "prêt pour la production" signifie avant que le code existe. Les critères d'acceptation sont testables. Les scope items tracent vers les ACs. L'agent valide contre la spec—pas au feeling.
La qualité est structurelle, pas accidentelle.
Livraison le jour même
Tout est scopé pour livrer aujourd'hui. Les fonctionnalités de plus de 8 heures sont découpées. Le système de tiers l'impose :
| Taille | Cérémonie |
|---|---|
| < 5 LOC | Aucune—on fait, c'est tout |
| < 30 LOC | Spec en commentaire inline |
| < 100 LOC | Template mini |
| 100+ LOC | Spec complet avec state machines |
Pas de sprints de deux semaines. Pas de surcharge de cérémonie. Les idées shipent le jour où elles naissent.
L'humain contrôle le déploiement
Le skill ne lance jamais git push ni de commande de déploiement. L'agent gère la qualité du code. Vous gérez la production.
Cette séparation compte pour la confiance. Je délègue la boucle de build parce que je sais que l'agent ne touchera rien d'irréversible sans demander.
Résilience de session
Le contexte se perd. Ça arrive. Le fichier spec permet une reprise parfaite :
L'agent lit la spec, vérifie l'état actuel, reprend exactement là où il s'est arrêté. Pas de "rappelle-moi ce qu'on construisait."
Agnostique
Pas verrouillé sur un seul outil. Le même skill fonctionne avec Claude Code, Codex, OpenCode, Cursor, Windsurf, Aider—tout agent qui lit les fichiers SKILL.md.
Le paysage des outils IA évolue vite. Le workflow reste portable.
Pour commencer
Le workflow skill est disponible sur skills.sh/bntvllnt/agent-skills/workflow :
Ou copier directement depuis le repo :
Le flux
Pas de config nécessaire. Le skill auto-détecte l'outillage du projet.
Compromis
Ce n'est pas magique. De vrais compromis :
Overhead pour les petits changements : Un fix de typo d'une ligne n'a pas besoin d'une spec. Le skill détecte les changements triviaux et saute la cérémonie—mais parfois on veut juste éditer et commit.
Courbe d'apprentissage : Le format de la spec et les actions prennent du temps à intégrer. La première semaine semble plus lente. Après, c'est plus rapide qu'avant.
Qualité de l'agent variable : La boucle est aussi bonne que l'implémentation de l'agent. Les algorithmes complexes et le code métier spécifique nécessitent toujours un review humain attentif.
Consommation de tokens : Le review multi-perspective et les corrections itératives consomment des tokens. Ça vaut le coup pour le code production. Excessif pour les scripts jetables.
Pourquoi j'ai construit ça
Le momentum compte plus que la perfection.
Avant, je perdais la moitié de mon énergie dans le processus—où j'en étais ? Qu'est-ce que je construisais ? Est-ce que j'ai testé ce cas limite ? Maintenant la spec contient tout l'état. Les quality gates tournent automatiquement. L'agent review son propre code depuis 9 perspectives avant même que je le regarde.
Le résultat : du meilleur logiciel, livré plus vite, dès le premier jour.
Ship, observer, ajuster. Chaque jour.
Si ça résonne, le skill est sur skills.sh/bntvllnt/agent-skills/workflow. Le source est sur GitHub.
Glossaire
Critères d'acceptation (ACs) — Conditions testables qui définissent quand une fonctionnalité est "terminée." Écrits au format GIVEN/WHEN/THEN. Exemple : GIVEN un utilisateur envoie 100 requêtes en 1 minute, WHEN il envoie la requête 101, THEN il reçoit un status 429 avec un header Retry-After. Chaque scope item trace vers au moins un AC. Si on ne peut pas écrire un AC, c'est hors scope.
Scope Items — Les tâches d'implémentation spécifiques qui remplissent les ACs. Chaque scope item mappe vers un ou plusieurs ACs, créant une traçabilité bidirectionnelle.
Quality Gates — Vérifications de validation automatiques (lint, typecheck, build, test) qui doivent passer avant que le code soit considéré terminé. Le quick pass tourne après chaque édition ; le full pass tourne avant complétion.
SKILL.md — Le format de fichier standard pour définir les skills d'agent. Tout agent de codage IA qui lit les fichiers SKILL.md peut charger et exécuter le workflow skill.
Plus d'articles sur la construction logicielle dans la catégorie Construire.
