De la Spec à la Prod : Mon Workflow Skill IA
Livrez du code production avec des agents IA. Un workflow skill en 10 actions : focus, plan, spec-review, spike, ship, fix, 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
- 6 quality gates : lint, typecheck, build, test, E2E, preuve TDD
- Tests E2E-first avec hiérarchie d'évitement des mocks
- Debugging scientifique dédié avec règles de prévention
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. 10 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—en boucle jusqu'à ce que tous les ACs passent |
fix | Debugging scientifique avec investigation par hypothèses et anti-cascade TDD |
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 tests suivent un protocole E2E-first. Chaque critère d'acceptation est mappé vers un test E2E par défaut. Les tests unitaires sont réservés aux fonctions pures uniquement. Une hiérarchie d'évitement des mocks impose les systèmes réels :
| Priorité | Stratégie |
|---|---|
| 1 (meilleur) | Système réel (test DB, API sandbox) |
| 2 | Docker/conteneur |
| 3 | Équivalent in-memory |
| 4 (dernier recours) | Mock (uniquement pour les APIs tierces sans sandbox) |
Mocker son propre code—services, base de données, endpoints HTTP, authentification—n'est jamais autorisé. Chaque mock exige un commentaire de justification.
Le TDD est structurellement enforced : chaque test doit échouer d'abord (RED_CONFIRMED), puis passer après implémentation (GREEN_CONFIRMED). Le skill trace tout dans un registre de scénarios E2E—pas de raccourcis.
6. Fix : Debugging scientifique
Les corrections de bugs ont leur propre action dédiée :
L'agent classifie le bug (simple, complexe ou hautement complexe) et adapte son investigation :
- Bugs simples (cause claire, fichier unique) : pas d'investigation, directement au fix
- Bugs complexes : test d'hypothèses séquentiel, probabilité la plus haute en premier
- Bugs hautement complexes : investigation parallèle depuis plusieurs perspectives—traceur de chemin d'exécution, inspecteur d'état, investigateur d'historique, analyseur de concurrence
Chaque cause racine doit passer une validation en 3 points avant tout changement de code :
- Explique : Est-ce que ça rend compte de TOUS les symptômes observés ?
- Prédit : Peut-on nommer le changement exact qui corrigera le bug ?
- Reproduit : Peut-on faire apparaître et disparaître le bug à volonté ?
Puis l'Anti-Cascade TDD entre en jeu :
- Baseline : Enregistrer l'état complet de la suite de tests
- Red : Écrire un test E2E de régression qui échoue (RED_CONFIRMED)
- Green : Implémenter le fix, le test passe (GREEN_CONFIRMED)
- Diff : Relancer toute la suite—comparer au baseline. Tout nouvel échec = le fix a introduit des régressions
- Scan : Chercher les bugs cousins dans le codebase (même pattern ailleurs)
- Learn : Mettre à jour la spec si liée, proposer des règles de prévention pour la config de l'agent
La phase LEARN est ce qui rend ça composable : après chaque correction, l'agent propose max 2 règles de prévention pour que la même classe d'erreur ne se reproduise pas. Les règles sont toujours proposées—jamais auto-appliquées—et ciblent les fichiers de config de l'agent.
7. 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 fait tourner les 6 gates :
| Gate | Scope |
|---|---|
| Lint | Fichiers modifiés |
| Typecheck | Projet complet |
| Build | Projet complet |
| Test | Tests liés |
| Registre E2E | Tous les critères d'acceptation mappés vers des tests E2E |
| Preuve TDD | Chaque GREEN_CONFIRMED a un RED_CONFIRMED préalable |
La couverture tourne en gate advisory—alerte sur les baisses de plus de 5% mais ne bloque jamais.
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.
8. 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 |
9. 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é.
10. 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—chacun mappé vers un test E2E avec preuve TDD (RED_CONFIRMED avant GREEN_CONFIRMED). 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, enforce le TDD E2E-first, et apprend même des bugs pour empêcher la même classe d'erreur de se reproduire.
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 qui doivent passer avant que le code soit considéré terminé. Le quick pass (lint, typecheck sur les fichiers modifiés) tourne après chaque édition. Le full pass (lint, typecheck, build, test, registre E2E, preuve TDD) tourne avant complétion. La couverture est advisory.
Tests E2E-First — Par défaut, on écrit des tests end-to-end. Les tests unitaires sont réservés aux fonctions pures sans I/O ni effets de bord. Une hiérarchie d'évitement des mocks impose les systèmes réels (test DB, API sandbox) plutôt que les doubles de test. Mocker son propre code n'est jamais autorisé.
Anti-Cascade TDD — Protocole de correction de bugs qui empêche les fixes d'introduire de nouvelles régressions. Baseline la suite de tests complète, écrire un test de régression qui échoue (RED), implémenter le fix (GREEN), puis comparer la suite complète au baseline (DIFF). Tout nouvel échec signifie que le fix a introduit des régressions.
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.
