name: dev-cycle-protocol
description: Orchestrateur du cycle de développement basé sur les rôles — phases allant de la conception du produit (Phase 0) et de la découverte à une version validée, sur le modèle de branchement du projet (intégration, trunk ou branches de release), le rôle de compétence appelé dans chaque phase (product-inception, software-design, quality-assurance, devops-release, user-docs, architecture-docs, plan-memory, code review), un chemin complet pour les fonctionnalités et un chemin court pour les petites corrections, le backlog du projet avec les epics et les bugs avant tout nouveau travail, la feuille de route des releases, GitHub Spec Kit comme exécuteur optionnel de la spécification, de la planification et de l'implémentation, les passerelles d'approbation de l'utilisateur (baseline produit, plan, approbation du candidat de release, la passerelle de release : fusion en production ou promotion du candidat), la configuration partagée .dev-cycle.json et la vérification automatisée des passerelles. À utiliser lors de toutes les tâches produit, conception logicielle, exploration, implémentation, revue et release.
🛡️ Protocole du Cycle de Développement (dev-cycle-protocol v4)
Chemins :
<skills_root>est le dossier qui contient cette compétence (le parent du dossier de cetteSKILL.md). Utilisez le chemin absolu réel lors de l'exécution des commandes. Exécutez-les depuis le dépôt du projet (ou passez--dir) : une session qui commence au-dessus, comme une session cloud dans/home/user, lirait autrement le mauvais dossier.Moteur : les scripts déjà traduits en Rust (IMP-005) s'exécutent via le lanceur, écrit ici
"<skills_root>/dev-cycle-protocol/bin/dev-cycle" <skill> <script> [args](shells sh : Linux, macOS, Git Bash). Sous PowerShell, exécutez& "<skills_root>/dev-cycle-protocol/bin/dev-cycle.ps1" <skill> <script> [args]. La première exécution télécharge le moteur pour la machine et vérifie sa somme de contrôle.
dev-cycle-protocol orchestre le travail logiciel comme une équipe de spécialistes. Il possède les phases, les passerelles et quel rôle intervient quand ; chaque compétence de rôle possède son propre artefact, ses règles et son vérificateur. Il est indépendant du langage et du projet.
Langue : parlez à l'utilisateur dans la langue qu'il utilise, mais rédigez chaque artefact du projet en anglais : code, commentaires, documentation, ADR, plans, tests manuels, messages de commit et descriptions de pull request. Un projet peut définir une autre langue de documentation dans
.dev-cycle.json(architecture_docs.language).
🧭 Démarrer une Session (/dev-cycle)
L'utilisateur commence par une commande, /dev-cycle (avec une idée produit ou une requête, ou seul). Elle exécute le diagnostic (onboard diagnose sur le moteur), indique en une ligne que le projet est à jour et continue, ou affiche les options dans l'ordre recommandé : un plan en cours, un candidat de release en attente, des bugs bloquants ouverts, une configuration manquante (configuration, modèle de branchement, branche d'intégration, Spec Kit), une baseline produit manquante, les prochains éléments de la release en cours, la requête. Un nouveau dépôt va en Phase 0. Un dépôt qui n'a jamais utilisé le protocole reçoit une liste de configuration initiale, confirmée en une fois ou élément par élément ; rien n'est écrit avant que l'utilisateur confirme. Lorsque l'utilisateur demande du travail sans la commande, exécutez d'abord le même diagnostic.
👥 Rôles
| Rôle | Compétence | Possède |
|---|---|---|
| Orchestrateur | dev-cycle-protocol | Phases, passerelles, le chemin pour chaque modification, .dev-cycle.json, le diagnostic /dev-cycle, la configuration Spec Kit et la constitution générée |
| Produit | product-inception | Phase 0 : la baseline produit, docs/product/VISION.md et TECH_SPEC.md |
| Planificateur | plan-memory | Le backlog avec les epics (docs/BACKLOG.md, commande /backlog), la feuille de route (docs/ROADMAP.md), les fichiers de plan dans docs/plans, les jalons, la détection de dérive |
| Architecte | software-design | Principes de conception, style d'architecture, section conception des plans, revue structurelle |
| Documentation technique | architecture-docs | TECDOC.md, docs/architecture, ADR |
| QA | quality-assurance | Stratégie de test automatisée, suite de tests manuels organisée, exécutions de candidats de release |
| DevOps | devops-release | Le modèle de branchement, CI, versions, candidats de release, releases, observabilité |
| Rédacteur technique | user-docs | README et documentation utilisateur finale |
| Relecteur | code-review | La relecture de chaque pull request sur sa plateforme : commentaires de ligne avec un niveau, jamais d'approbation |
| Mémoire de session | session-memory | Le contexte de session du développeur lui-même |
| Feedback Gedo (temporaire, désactivé par défaut) | gedo-feedback | Ce qui ne va pas avec Gedo dans le travail réel, enregistré pour le backlog de Gedo pendant que le projet utilise Gedo (gedo.enabled) |
| Exécuteur de spécification (optionnel) | GitHub Spec Kit | Le détail d'une fonctionnalité dans les Phases 1, 2 et 4 : specs/NNN-slug/ (spécification, plan, tâches) |
Un rôle est un ensemble de règles et un vérificateur, pas une personne distincte : chargez la compétence de rôle lorsque sa phase commence, suivez-la, et exécutez son vérificateur avant de quitter la phase. Spec Kit est un outil, pas un rôle : le protocole décide quand il s'exécute et vérifie ce qu'il produit (voir "Spec Kit").
🏛️ Principes
- Conception : code modulaire avec des responsabilités claires, SOLID, Clean Code, erreurs explicites, motifs uniquement lorsque nécessaire, dans le style d'architecture du projet (
software-design). - Preuve : chaque modification est prouvée par des tests automatisés ; les tests manuels couvrent uniquement ce qui ne peut pas être automatisé, dans une suite organisée (
quality-assurance). - La documentation décrit aujourd'hui : les docs techniques et le README sont modifiés sur place ; l'historique vit dans Git et les notes de version (
architecture-docs,user-docs). - Les plans sont partagés et complets : les plans approuvés sont des fichiers versionnés dans le projet (
plan-memory). - Livraison sécurisée : branches à courte durée de vie sur le modèle de branchement du projet, CI sur chaque pull request, candidats de release, la passerelle de release de l'utilisateur (
devops-release). - Sécurité : pas de secrets dans Git, migrations de données rétrocompatibles, un chemin de retour arrière pour chaque release.
- Les bugs d'abord : les bugs ouverts de sévérité
critical,highetmediumsont planifiés et corrigés avant les nouvelles fonctionnalités, améliorations et ajustements ; un buglowva dans la prochaine release au plus tard ; aucun bug connu ne reste non trié (une sévérité, et une release pour ceux qui ne bloquent pas). Seul l'utilisateur peut explicitement accepter le risque. Rien de trouvé n'est perdu, c'est corrigé maintenant ou capturé dans le backlog. - Suivi jusqu'au bout : l'agent suit CI et les releases jusqu'à la fin et corrige ce qui échoue ; les décisions de l'utilisateur (approbation du plan, acceptation du candidat, la passerelle de release) ne sont jamais prises par l'agent.
- Pas d'attribution IA, nulle part : aucun artefact ne nomme une IA, un modèle ou un agent de codage comme auteur, co-auteur, relecteur ou source : commits et leurs en-têtes, tags, branches, pull et merge requests, revues et commentaires de revue, issues, plans, documentation, notes de version et commentaires de code. Tout est écrit par l'identité Git du dépôt (
devops-release). La configuration dont un projet a besoin pour ses outils (un dossier de paramètres d'agent, un nom d'intégration) est technique, pas une attribution. Le texte posté via un outil autre quepr_sync(un outil de plateforme, un connecteur, la page web) est d'abord vérifié avec"<skills_root>/dev-cycle-protocol/bin/dev-cycle" dev-cycle-protocol _no_ai --file <text>, et relu après publication : un pied de page, un lien ou un marqueur que l'outil a ajouté (« Généré par ... », un lien de session ou de thread d'agent) est immédiatement supprimé. La passerelle 8 refuse également les commits dont l'auteur ou le commiteur est une identité IA.
🧭 Choisir le Chemin
| Chemin | Quand | Phases |
|---|---|---|
| Inception | Un nouveau produit à partir d'une idée, ou un projet existant sans baseline produit (adoption) | 0, une fois par produit ; puis le chemin complet pour les premiers éléments de la feuille de route |
| Complet | Nouvelles fonctionnalités, refontes, modifications de données ou de schéma, modifications de commandes, configuration, formats de fichiers ou API publiques, modifications CI/release, tout ce qui couvre plusieurs modules | 1 à 7 par modification ; 8 à 10 par release |
| Court | Petites corrections de bugs, documentation uniquement, tests uniquement ou corrections de typos qui tiennent dans une petite pull request et ne modifient aucune interface ou donnée | 1, 4, 5, 6 (uniquement ce qui est affecté), 7 |
Pour le chemin court, la requête de l'utilisateur est l'approbation lorsqu'elle nomme le changement (« corrige le crash dans X ») ; sinon décrivez le changement en une ou deux phrases et attendez le feu vert de l'utilisateur. En cas de doute, utilisez le chemin complet.
🔄 Le Cycle
graph TD
P0["0. Inception produit (une fois)<br/>product-inception, gate 0 (utilisateur)"] -.-> P1
P1["1. Découverte<br/>orchestrateur, plan-memory, software-design"] --> P2["2. Plan<br/>plan-memory + tous les rôles"]
P2 --> G3{"3. Approbation du plan<br/>(utilisateur)"}
G3 -- "questions / modifications" --> P1
G3 -- "approuvé" --> P4["4. Implémentation sur une branche<br/>software-design"]
P4 --> P5["5. Tests automatisés<br/>quality-assurance"]
P5 --> P6["6. Documentation<br/>architecture-docs, user-docs, quality-assurance"]
P6 --> P7["7. Revue et PR dans la base de travail, CI verte<br/>reviewer, software-design, devops-release"]
P7 -. "prochaine modification" .-> P1
P7 --> P8["8. Candidat de release<br/>devops-release, quality-assurance"]
P8 --> G9{"9. Acceptation<br/>(l'utilisateur exécute les tests manuels)"}
G9 -- "Échec / Bloqué" --> P4
G9 -- "tout Pass" --> G10{"10. Passerelle de release (utilisateur)<br/>fusionne dev dans main, ou promeut le candidat"}
G10 --> P11["Release finale suivie et vérifiée<br/>devops-release, plan-memory, session-memory"]
La Phase 0 s'exécute une fois par produit. Les phases 1 à 7 s'exécutent pour chaque modification. Les phases 8 à 10 s'exécutent lorsque l'utilisateur souhaite publier ce qui s'est accumulé dans la base de travail.
Modèle de branchement (devops.branching, devops-release) : chaque phase ci-dessous dit base de travail, branche candidate et passerelle de release ; le modèle les donne (branching show sur le moteur : "<skills_root>/dev-cycle-protocol/bin/dev-cycle" devops-release branching show) :
| Modèle | Base de travail (branche depuis, pull requests vers) | Branche candidate | Passerelle de release (l'utilisateur) |
|---|---|---|---|
integration (par défaut) | dev | dev | fusionne dev dans main |
trunk | main | main | exécute le workflow de promotion pour le candidat accepté |
release-branches | main (correctifs d'une release : release/X.Y) | release/X.Y | exécute le workflow de promotion pour le candidat accepté |
0. 🌱 Inception Produit (une fois par produit)
Suivez product-inception : entretien, document métier, architecture, spécification technique, constitution (Spec Kit), backlog produit avec epics, feuille de route, chacun approuvé par l'utilisateur. Cela se termine à la passerelle 0, l'approbation par l'utilisateur de la baseline produit :
"<skills_root>/dev-cycle-protocol/bin/dev-cycle" dev-cycle-protocol verify_gate --gate 0
Un projet sans baseline déjà en cours peut l'adopter (mode adoption) ou l'ignorer : la Phase 0 est requise pour les nouveaux produits, recommandée pour les existants.
1. 💡 Découverte
- Restez consultatif : pendant que l'utilisateur demande, débat ou propose, ne modifiez pas de fichiers et ne démarrez pas de code.
- Inspectez le projet et sa configuration :
"<skills_root>/dev-cycle-protocol/bin/dev-cycle" dev-cycle-protocol inspect_project "<skills_root>/dev-cycle-protocol/bin/dev-cycle" dev-cycle-protocol project_config --validate - Les logs d'abord : pour toute erreur signalée, lisez les vrais logs avant de former des hypothèses.
- Lisez les plans actifs (
list_planssur le moteur :"<skills_root>/dev-cycle-protocol/bin/dev-cycle" plan-memory list_plans;plan-memory check_milestone --list) ainsi que le style et la structure d'architecture (software-design). - Lisez le backlog et la feuille de route (
plan-memory backlog summary,roadmap currentsur le moteur :"<skills_root>/dev-cycle-protocol/bin/dev-cycle" plan-memory roadmap current;inspect_projectles montre tous les deux). Montrez à l'utilisateur les bugs ouverts qui précèdent tout nouveau travail, puis les éléments ouverts de la release en cours et les éléments liés à la requête ; l'utilisateur décide quoi promouvoir, reprioriser, déplacer ou abandonner (voir "Backlog et Feuille de Route"). - Pour planifier des éléments du backlog, promouvez-les (
backlog promote <ID> ...) : le plan provisoire (un plan de bug pour les bugs) est l'endroit où la découverte est écrite. - Spec Kit : extrayez la base de travail, puis exécutez
/speckit-specifyavec la description des éléments : cela crée la branche de travailfeat/NNN-slugetspecs/NNN-slug/spec.md. Exécutez/speckit-clarifyjusqu'à ce qu'aucun marqueur[NEEDS CLARIFICATION]ne reste ; l'utilisateur répond à ses questions. Le plan promu est l'enveloppe ; la découverte vit dans la spécification. - Épuisez les questions ouvertes et convergez vers une approche avec l'utilisateur.
2. 📋 Plan
Rédigez le plan complet avec ce modèle, en collectant la section de chaque rôle :
- Objectif et décisions : ce qui change et pourquoi ; les décisions avec alternatives deviennent des ADR (
architecture-docs). - Conception (
software-design) : où chaque élément vit, interfaces, flux de données, stratégie d'erreur, dépendances, ce qui n'est délibérément pas abstrait. - Surfaces et fichiers affectés : les interfaces dans
architecture.surfacesqui changent ; fichiers et modules. - Tests (
quality-assurance) : tests automatisés à ajouter (un test de régression par bug), tests manuels à ajouter, modifier ou supprimer, critères d'acceptation. - Documentation (
architecture-docs,user-docs) : pages de sous-système et ADR, sections README. - CI, release et observabilité (
devops-release) : modifications de workflow, impact sur la version, logs, diagnostics et télémétrie à ajouter et comment ils sont testés. - Sécurité, migration et retour arrière : secrets, migrations de données (rétrocompatibles), comment revenir en arrière.
- Étapes d'exécution et jalons.
Spec Kit : exécutez /speckit-plan (son plan porte les jalons d'exécution détaillés ; le plan de haut niveau reste le plan promu) : specs/NNN-slug/plan.md. Exécutez /speckit-review-plan jusqu'à ce que l'utilisateur l'accepte ; l'approbation de la passerelle 3 vient de l'utilisateur.
3. ✅ Passerelle du Plan (utilisateur)
L'utilisateur approuve, demande des changements ou abandonne. Lorsqu'aucune question n'est posée, lisez le plan à voix haute et demandez l'approbation. N'écrivez, ne modifiez et n'approchez aucun code d'implémentation (même sur une branche de travail) avant que l'utilisateur ait approuvé le plan. Une fois approuvé : créez la branche de travail à partir de la base de travail et basculez dessus, exécutez la vérification de la passerelle du plan (passerelle 3) :
"<skills_root>/dev-cycle-protocol/bin/dev-cycle" dev-cycle-protocol verify_gate --gate 3
4. 🛠️ Implémentation sur une Branche
software-design implémente chaque pièce : suivez software-design pour l'architecture modulaire et les patterns. Spec Kit : exécutez /speckit-code (specs/NNN-slug/tasks.md) et marquez les tâches terminées ; lorsque la spécification et les tâches sont terminées, exécutez /speckit-verify.
5. ⚙️ Tests Automatisés
quality-assurance : ajoutez des tests automatisés pour couvrir les nouveaux comportements (une spécification de test par cas, une classe/suite par module). Exécutez la suite de tests automatisés jusqu'à ce qu'elle soit totalement verte. Spec Kit : exécutez /speckit-check.
6. 📝 Documentation
architecture-docs, user-docs, quality-assurance : mettez à jour les documents d'architecture, la documentation technique finale (TECDOC.md, docs/architecture), le README et les docs utilisateur, et les plans de test manuels. Si le plan enregistre des décisions comme ADR, elles sont écrites ici.
7. 👀 Revue et PR dans la Base de Travail
reviewer, software-design, devops-release : créez une pull request avec le titre, la description, la section vers la base de travail, les tests (référencez tests/), les décisions majeures, les questions de revue (code-review). Exécutez quality-assurance pour une re-vérification automatisée des tests. devops-release vérifie la configuration CI, les versions et les logs. reviewer écrit des commentaires de ligne avec un niveau (nit, suggestion, correctif, blocage). L'utilisateur effectue la fusion lorsqu'il est satisfait, pas l'agent. Attendez que la CI soit verte sur la pull request. Spec Kit : exécutez /speckit-verify une dernière fois.
8. 📦 Candidat de Release
devops-release marque le candidat (étiquette ou branche candidate) et quality-assurance exécute la suite de tests manuels organisée.
9. ✅ Acceptation (utilisateur)
L'utilisateur exécute la suite de tests manuels. S'ils passent tous, la passerelle d'acceptation (passerelle 9) est exécutée :
"<skills_root>/dev-cycle-protocol/bin/dev-cycle" dev-cycle-protocol verify_gate --gate 9
10. 🚪 Passerelle de Release (utilisateur)
L'utilisateur effectue la fusion ou promeut le candidat. L'agent suit la fusion ou le workflow, vérifie que l'étiquette de version est posée, que les notes de version sont générées (devops-release release notes), et que les CI de publication finale sont vertes. Ensuite, exécutez la vérification de la passerelle finale :
"<skills_root>/dev-cycle-protocol/bin/dev-cycle" dev-cycle-protocol verify_gate --gate 10
Puis enregistrez la release dans le backlog du planificateur :
"<skills_root>/dev-cycle-protocol/bin/dev-cycle" plan-memory release_record --version <version>
📋 Backlog et Feuille de Route
Le backlog (plan-memory) suit les epics, les bugs, les tâches et les users stories. Les éléments ont un statut (backlog:new, backlog:triaged, planning, planned, implementing, testing, reviewing, done). La feuille de route organise les releases (plan-memory roadmap). Affichez toujours les bugs de sévérité critical, high et medium avant de proposer un nouveau travail.
⚙️ Passerelles Automatisées
Chaque passerelle vérifie les conditions requises avant de passer à la phase suivante. Les vérifications sont automatisées via la commande :
"<skills_root>/dev-cycle-protocol/bin/dev-cycle" dev-cycle-protocol verify_gate --gate <numéro>
Les passerelles sont les suivantes :
| Passerelle | Phase | Vérifiée par | Se produit lorsque |
|---|---|---|---|
| 0 | Inception produit | product-inception | L'utilisateur approuve la baseline produit |
| 3 | Plan | plan-memory | L'utilisateur approuve le plan |
| 9 | Acceptation | quality-assurance | Tous les tests manuels passent |
| 10 | Release | devops-release | La release est fusionnée ou promue |
🔧 Configuration (.dev-cycle.json)
La configuration partagée du projet est dans .dev-cycle.json à la racine du dépôt. Elle est gérée par l'orchestrateur via la commande :
"<skills_root>/dev-cycle-protocol/bin/dev-cycle" dev-cycle-protocol project_config --validate
Exemple de configuration :
{
"version": "1",
"project": {
"name": "mon-projet",
"language": "typescript",
"architecture_docs": {
"language": "fr"
}
},
"devops": {
"branching": "integration",
"ci_provider": "github_actions"
},
"speckit": {
"enabled": false
},
"gedo": {
"enabled": false
}
}
📚 Résumé des Commandes du Moteur
| Commande | Rôle | Usage |
|---|---|---|
diagnose | dev-cycle-protocol | Diagnostique l'état du projet |
inspect_project | dev-cycle-protocol | Inspecte le projet et sa configuration |
project_config | dev-cycle-protocol | Valide et affiche la configuration du projet |
verify_gate | dev-cycle-protocol | Vérifie une passerelle spécifique |
list_plans | plan-memory | Liste les plans actifs |
backlog | plan-memory | Gère le backlog (summary, promote, etc.) |
roadmap | plan-memory | Affiche et gère la feuille de route |
release_record | plan-memory | Enregistre une release dans le backlog |
branching | devops-release | Affiche le modèle de branchement actuel |
🔗 Intégration avec d'Autres Compétences
product-inception: Phase 0plan-memory: Backlog, plans, feuille de routesoftware-design: Conception et revue d'architecturequality-assurance: Tests automatisés et manuelsdevops-release: CI, versions, releasesarchitecture-docs: Documentation architectureuser-docs: Documentation utilisateurcode-review: Revue de codesession-memory: Contexte de sessiongedo-feedback: Feedback Gedo (optionnel)
🧪 Utilisation avec Spec Kit
Lorsque speckit.enabled est true, Spec Kit gère les spécifications détaillées, les plans et les tâches pour les fonctionnalités. Les commandes Spec Kit (/speckit-specify, /speckit-clarify, /speckit-plan, /speckit-code, /speckit-check, /speckit-verify) sont disponibles dans les phases 1, 2 et 4.
✅ Vérifications Automatisées
Avant de quitter une phase, les vérifications suivantes sont effectuées :
- Passerelle de phase : la condition de passerelle est-elle remplie ?
- Pas de saleté non engagée (sauf si autorisée)
- Pas de secrets exposés
- Tests passent (si applicable)
- Documentation à jour
📦 Installation
La première exécution d'une commande télécharge automatiquement le moteur Rust. Aucune installation manuelle n'est requise au-delà de la présence de ce dossier de compétence dans le chemin approprié de l'agent.
Documentation générée par le protocole du cycle de développement.