qwen-superpowers 1.0.0

package/scripts/release.js

@@ -0,0 +1,97 @@
+/**
+ * Script de release.
+ * Usage: node scripts/release.js [patch|minor|major]
+ *
+ * Automatise le bump de version, le tag git et la préparation du release.
+ */
+
+const { execSync } = require('child_process');
+const fs = require('fs');
+const path = require('path');
+
+const PACKAGE_PATH = path.join(__dirname, '..', 'package.json');
+
+const bumpType = process.argv[2] || 'patch';
+const validBumps = ['patch', 'minor', 'major'];
+
+if (!validBumps.includes(bumpType)) {
+  console.error(`Usage: node scripts/release.js [${validBumps.join('|')}]`);
+  console.error(`  patch:  1.0.0 -> 1.0.1`);
+  console.error(`  minor:  1.0.0 -> 1.1.0`);
+  console.error(`  major:  1.0.0 -> 2.0.0`);
+  process.exit(1);
+}
+
+// Lire la version actuelle
+const pkg = JSON.parse(fs.readFileSync(PACKAGE_PATH, 'utf-8'));
+const currentVersion = pkg.version;
+console.log(`Version actuelle: ${currentVersion}`);
+
+// Calculer la nouvelle version
+const [major, minor, patch] = currentVersion.split('.').map(Number);
+let newVersion;
+
+switch (bumpType) {
+  case 'patch':
+    newVersion = `${major}.${minor}.${patch + 1}`;
+    break;
+  case 'minor':
+    newVersion = `${major}.${minor + 1}.0`;
+    break;
+  case 'major':
+    newVersion = `${major + 1}.0.0`;
+    break;
+}
+
+console.log(`Nouvelle version: ${newVersion} (bump: ${bumpType})`);
+
+// Vérifier que le dépôt est propre
+try {
+  const status = execSync('git status --porcelain', { encoding: 'utf-8' }).trim();
+  if (status) {
+    console.error('\n❌ Le dépôt contient des modifications non committées.');
+    console.error('Commitez ou stash vos changements avant de créer un release.');
+    process.exit(1);
+  }
+} catch {
+  console.log('⚠️  Impossible de vérifier l\'état git (pas un dépôt git ?)');
+}
+
+// Appliquer la nouvelle version
+pkg.version = newVersion;
+fs.writeFileSync(PACKAGE_PATH, JSON.stringify(pkg, null, 2) + '\n');
+console.log(`\n✓ package.json mis à jour: ${newVersion}`);
+
+// Exécuter les tests
+console.log('\nExécution des tests...');
+try {
+  execSync('npm test', { stdio: 'inherit' });
+  console.log('✓ Tests passés');
+} catch (e) {
+  console.error('\n❌ Les tests ont échoué — annulation du release.');
+  // Rollback
+  pkg.version = currentVersion;
+  fs.writeFileSync(PACKAGE_PATH, JSON.stringify(pkg, null, 2) + '\n');
+  process.exit(1);
+}
+
+// Créer le tag git
+const tagName = `v${newVersion}`;
+console.log(`\nCréation du tag ${tagName}...`);
+
+try {
+  execSync(`git add package.json CHANGELOG.md`, { stdio: 'inherit' });
+  execSync(`git commit -m "chore: release ${tagName}"`, { stdio: 'inherit' });
+  execSync(`git tag -a ${tagName} -m "Release ${tagName}"`, { stdio: 'inherit' });
+  console.log(`\n✓ Tag ${tagName} créé`);
+  console.log(`\nPoussez avec: git push && git push origin ${tagName}`);
+  console.log(`Le workflow GitHub Actions publiera automatiquement sur npm.`);
+} catch (e) {
+  console.log('⚠️  Erreur git (normal si pas de repo git)');
+}
+
+console.log(`\n============================================`);
+console.log(`  Release ${tagName} prêt !`);
+console.log(`  Pusher le tag pour déclencher la publication:`);
+console.log(`  git push && git push origin ${tagName}`);
+console.log(`============================================\n`);

package/scripts/verify-skills.js

@@ -0,0 +1,81 @@
+/**
+ * Script de vérification de l'intégrité des skills.
+ * Utilisé dans les tests CI pour s'assurer que tous les skills sont valides.
+ */
+
+const fs = require('fs');
+const path = require('path');
+
+const SKILLS_DIR = path.join(__dirname, '..', 'skills');
+const REQUIRED_SECTIONS = ['Triggers', 'Instructions', 'Règles', 'Sortie attendue', 'Sortie Attendue'];
+
+let hasErrors = false;
+
+function verifySkills() {
+  const skills = fs.readdirSync(SKILLS_DIR).filter(d =>
+    fs.statSync(path.join(SKILLS_DIR, d)).isDirectory()
+  );
+
+  console.log(`\nVérification de ${skills.length} skills...\n`);
+
+  skills.forEach(skill => {
+    const skillFile = path.join(SKILLS_DIR, skill, 'SKILL.md');
+
+    if (!fs.existsSync(skillFile)) {
+      console.error(`  ❌ ${skill}: SKILL.md manquant`);
+      hasErrors = true;
+      return;
+    }
+
+    const content = fs.readFileSync(skillFile, 'utf-8');
+
+    // Vérifier la présence des sections requises (au moins une variante)
+    const missingSections = REQUIRED_SECTIONS.filter(section => {
+      // "Sortie attendue" et "Sortie Attendue" sont équivalents
+      if (section === 'Sortie attendue' || section === 'Sortie Attendue') {
+        return !content.includes('Sortie attendue') && !content.includes('Sortie Attendue');
+      }
+      return !content.includes(section);
+    });
+    if (missingSections.filter(s => s !== 'Sortie Attendue').length > 0) {
+      console.error(`  ⚠️  ${skill}: sections manquantes: ${missingSections.filter(s => s !== 'Sortie Attendue').join(', ')}`);
+      hasErrors = true;
+    }
+
+    // Vérifier que le fichier n'est pas vide
+    if (content.trim().length < 50) {
+      console.error(`  ❌ ${skill}: SKILL.md trop court (${content.trim().length} chars)`);
+      hasErrors = true;
+      return;
+    }
+
+    console.log(`  ✅ ${skill} (${content.trim().length} chars)`);
+  });
+
+  // Vérifier les hooks
+  console.log('\nVérification des hooks...');
+  const hooksDir = path.join(__dirname, '..', 'hooks');
+  const hooks = fs.readdirSync(hooksDir).filter(f => f.endsWith('.js'));
+
+  hooks.forEach(hook => {
+    const hookPath = path.join(hooksDir, hook);
+    try {
+      require(hookPath);
+      console.log(`  ✅ ${hook}`);
+    } catch (e) {
+      console.error(`  ❌ ${hook}: ${e.message}`);
+      hasErrors = true;
+    }
+  });
+
+  // Résumé
+  console.log('');
+  if (hasErrors) {
+    console.error('❌ Vérification échouée — corrigez les erreurs avant de continuer.');
+    process.exit(1);
+  } else {
+    console.log('✅ Tous les skills et hooks sont valides.');
+  }
+}
+
+verifySkills();

package/scripts/version.js

@@ -0,0 +1,43 @@
+/**
+ * Script de gestion de version.
+ * Met à jour le CHANGELOG.md avec la date du jour et la nouvelle version.
+ * Exécuté automatiquement via npm version.
+ */
+
+const fs = require('fs');
+const path = require('path');
+
+const CHANGELOG_PATH = path.join(__dirname, '..', 'CHANGELOG.md');
+const PACKAGE_PATH = path.join(__dirname, '..', 'package.json');
+
+function updateChangelog(version) {
+  let changelog = '';
+
+  if (fs.existsSync(CHANGELOG_PATH)) {
+    changelog = fs.readFileSync(CHANGELOG_PATH, 'utf-8');
+  }
+
+  const today = new Date().toISOString().split('T')[0];
+  const newSection = `## [${version}] - ${today}\n\n### Added\n- \n\n### Changed\n- \n\n### Fixed\n- \n\n`;
+
+  // Insérer après l'en-tête du changelog
+  const headerEnd = changelog.indexOf('\n\n## [');
+  if (headerEnd > 0) {
+    changelog = changelog.slice(0, headerEnd + 2) + newSection + changelog.slice(headerEnd + 2);
+  } else {
+    // Chercher juste après les lignes de description initiale
+    const descEnd = changelog.indexOf('\n\n## ');
+    if (descEnd > 0) {
+      changelog = changelog.slice(0, descEnd + 2) + newSection + changelog.slice(descEnd + 2);
+    } else {
+      changelog += '\n\n' + newSection;
+    }
+  }
+
+  fs.writeFileSync(CHANGELOG_PATH, changelog);
+  console.log(`CHANGELOG.md mis à jour pour la version ${version}`);
+}
+
+// Récupérer la version depuis package.json
+const pkg = JSON.parse(fs.readFileSync(PACKAGE_PATH, 'utf-8'));
+updateChangelog(pkg.version);

package/skills/brainstorming/SKILL.md

@@ -0,0 +1,94 @@
+# Brainstorming
+
+> Questionnement socratique pour affiner les idées avant de coder. Produire un document de design validé.
+
+## Triggers
+- L'utilisateur exprime une idée vague ("je voudrais faire...", "ce serait bien si...")
+- L'utilisateur demande une nouvelle fonctionnalité sans spécifications détaillées
+- Le projet nécessite une décision architecturale
+- L'agent détecte une ambiguïté dans la demande
+
+## Instructions
+
+### 1. Phase d'Exploration
+Poser des questions ouvertes pour comprendre l'intention :
+- **Quel est le problème** que tu cherches à résoudre ?
+- **Qui** utilisera cette fonctionnalité ?
+- **Quel est le cas d'usage principal** ? Et les cas limites ?
+- **Y a-t-il des contraintes** techniques ou business ?
+
+### 2. Phase de Clarification
+Approfondir avec des questions ciblées :
+- "Que se passe-t-il si... ?" (cas limites)
+- "Comment l'utilisateur interagit avec... ?" (UX)
+- "Quelles sont les dépendances existantes ?" (architecture)
+- "Est-ce que ça existe déjà sous une autre forme ?" (réutilisation)
+
+### 3. Phase de Convergence
+Proposer une synthèse et valider :
+- Résumer l'idée en 2-3 phrases
+- Lister les composants/entités principaux
+- Identifier les risques et complexités
+- Proposer 2-3 approches avec trade-offs
+
+### 4. Production du Design Doc
+Générer un document structuré sauvegardé dans `.qwen-designs/` :
+
+```markdown
+# Design: [Nom de la feature]
+
+## Problème
+[Description du problème résolu]
+
+## Solution Proposée
+[Architecture et approche choisie]
+
+## Composants
+- [Composant A]: [Rôle]
+- [Composant B]: [Rôle]
+
+## API / Interface
+[Signature des fonctions ou endpoints]
+
+## Cas Limites
+- [Cas 1]: [Comportement]
+- [Cas 2]: [Comportement]
+
+## Trade-offs
+- [Choix X]: avantage/inconvénient
+- [Choix Y]: avantage/inconvénient
+
+## Décisions
+1. [Décision 1] car [raison]
+2. [Décision 2] car [raison]
+```
+
+## Règles
+
+1. **Ne JAMAIS sauter directement au code** — le design d'abord
+2. **Poser au moins 3 questions** avant de proposer une solution
+3. **Toujours sauvegarder** le design doc dans `.qwen-designs/`
+4. **Proposer des alternatives** quand le choix n'est pas évident
+5. **Valider avec l'utilisateur** avant de passer à l'étape suivante
+
+## Sortie Attendue
+
+- [ ] Au moins 3 questions posées à l'utilisateur
+- [ ] Compréhension validée par l'utilisateur
+- [ ] Design doc produit et sauvegardé
+- [ ] Prochaine étape identifiée (writing-plans)
+
+## Exemple d'Utilisation
+
+```
+Utilisateur: "Je voudrais un système de cache pour les requêtes API"
+
+Agent (Brainstorming):
+1. "Quel type de requêtes API ? (GET uniquement ? avec paramètres ?)"
+2. "Combien de temps les données doivent-elles rester en cache ?"
+3. "Le cache doit-il être persistant (fichier/DB) ou en mémoire ?"
+4. "Y a-t-il des contraintes de mémoire à considérer ?"
+5. "Est-ce que invalidation manuelle est nécessaire ?"
+
+→ Après réponses → Production du Design Doc → Writing Plans
+```

package/skills/code-review/SKILL.md

@@ -0,0 +1,101 @@
+# Code Review
+
+> Comparer le code produit au plan initial et identifier les problèmes avant de merger.
+
+## Triggers
+- Du code a été produit après exécution d'un plan
+- L'utilisateur demande une revue de code
+- Avant de merger une branche
+- Après un refactoring significatif
+
+## Instructions
+
+### 1. Vérifier la Conformité au Plan
+1. Relire le plan d'exécution initial
+2. Comparer chaque tâche avec le code produit
+3. Vérifier que toutes les tâches sont implémentées
+4. Identifier les écarts (code manquant, code ajouté non planifié)
+
+### 2. Analyse Statique
+Examiner le code pour :
+- **Lisibilité** : noms de variables, structure, commentaires
+- **Complexité** : fonctions trop longues, nesting excessif
+- **Duplication** : code copié-collé, logique répétée
+- **Architecture** : respect des responsabilités, couplage
+- **Sécurité** : injections, données sensibles, validation
+
+### 3. Vérification des Tests
+1. Tous les tests passent-ils ?
+2. Les cas limites sont-ils couverts ?
+3. Les tests sont-ils lisibles et maintenables ?
+4. Y a-t-il des chemins non testés ?
+
+### 4. Rapport par Sévérité
+
+```markdown
+# Rapport de Revue de Code
+
+## 🔴 Critical (Bloquant — empêche le merge)
+- [ ] Problème 1: description + localisation + suggestion
+- [ ] Problème 2: ...
+
+## 🟡 Warning (Devrait être corrigé)
+- [ ] Problème 1: description + suggestion
+- [ ] Problème 2: ...
+
+## 🟢 Suggestion (Optionnel)
+- [ ] Problème 1: description + suggestion
+
+## ✅ Points Positifs
+- Point fort 1
+- Point fort 2
+
+## Résumé
+- Critical: X | Warning: Y | Suggestions: Z
+- Statut: 🔴 BLOQUÉ / 🟡 CONDITIONNEL / ✅ APPROUVÉ
+```
+
+## Règles
+
+1. **Critical = veto** — aucun merge si un problème critical existe
+2. **Être constructif** — toujours proposer une solution, pas juste critiquer
+3. **Vérifier contre le plan** — pas juste contre des standards généraux
+4. **Revue en 2 passes** : (1) conformité plan, (2) qualité code
+5. **Documenter les décisions** — pourquoi quelque chose est un problème
+
+## Sortie Attendue
+
+- [ ] Rapport de revue complet avec sévérités
+- [ ] Problèmes critical bloquent la progression
+- [ ] Suggestions documentées
+- [ ] Statut clair : BLOQUÉ / CONDITIONNEL / APPROUVÉ
+- [ ] Si CONDITIONNEL : re-revue après corrections
+
+## Exemple d'Utilisation
+
+```markdown
+# Rapport de Revue de Code
+
+## 🔴 Critical
+- [ ] `cache.ts:15` — La méthode `get` ne vérifie pas l'expiration.
+      Un item expiré est retourné comme valide.
+      **Fix:** Vérifier `Date.now() < item.expiry` avant de retourner.
+
+## 🟡 Warning
+- [ ] `cache.test.ts:22` — Pas de test pour l'éviction LRU.
+      **Fix:** Ajouter un test avec capacity=2 et 3 insertions.
+- [ ] `cache.ts:8` — Le Map n'a pas de taille maximale.
+      **Fix:** Ajouter une option `maxSize` au constructeur.
+
+## 🟢 Suggestions
+- [ ] Utiliser `Record` au lieu de `Map` si les clés sont toujours strings.
+
+## ✅ Points Positifs
+- Architecture claire et bien séparée
+- Tests complets pour les cas nominaux
+- Bons noms de variables et fonctions
+
+## Résumé
+- Critical: 1 | Warning: 2 | Suggestions: 1
+- Statut: 🔴 BLOQUÉ — corriger l'expiration avant merge
+```

package/skills/executing-plans/SKILL.md

@@ -0,0 +1,71 @@
+# Executing Plans
+
+> Exécuter un plan d'exécution étape par étape en suivant le workflow TDD.
+
+## Triggers
+- Un plan a été écrit et validé par l'utilisateur
+- L'utilisateur donne le feu vert pour l'exécution
+- L'agent est en mode développement actif
+
+## Instructions
+
+### 1. Préparer l'Environnement
+1. Vérifier que tous les tests existants passent
+2. Créer une branche de travail (ou worktree) si pas déjà fait
+3. Identifier le premier test en échec attendu (RED)
+
+### 2. Exécuter Chaque Tâche
+Pour chaque tâche du plan :
+
+1. **Lire la description** de la tâche
+2. **Créer/modifier les fichiers** spécifiés
+3. **Si c'est un test** : s'assurer qu'il échoue initialement (RED)
+4. **Si c'est de l'implémentation** : écrire le minimum pour passer le test (GREEN)
+5. **Exécuter la vérification** spécifiée
+6. **Refactorer** si nécessaire (tests doivent rester verts)
+7. **Cocher la tâche** comme terminée
+
+### 3. Progression et Communication
+- Annoncer le début de chaque tâche
+- Montrer le résultat de la vérification
+- Signaler immédiatement si une tâche bloque
+- Mettre à jour la progression (X/Y tâches)
+
+### 4. Gestion des Blocages
+Si une tâche est plus complexe que prévu :
+1. **NE PAS** improviser — revenir au plan
+2. Identifier pourquoi la tâche est sous-estimée
+3. Proposer un re-découpage si nécessaire
+4. Valider avec l'utilisateur avant de continuer
+
+## Règles
+
+1. **Suivre le plan à la lettre** — pas de déviation sans validation
+2. **TDD à chaque étape** — test d'abord, code ensuite
+3. **Vérifier après chaque tâche** — les tests doivent passer
+4. **Un commit par tâche** ou groupe logique de tâches
+5. **Signaler les blocages** immédiatement
+
+## Sortie Attendue
+
+- [ ] Toutes les tâches du plan exécutées
+- [ ] Tous les tests passent
+- [ ] Code commité incrémentalement
+- [ ] Prêt pour la code review
+
+## Exemple de Progression
+
+```
+📋 Exécution du Plan: Système de Cache API
+Progression: 2/6 tâches
+
+✅ Tâche 1: Test - Cache create/empty
+   → Test écrit, échoue initialement (RED) ✅
+
+✅ Tâche 2: Implémenter Cache class
+   → Classe Cache créée, test passe (GREEN) ✅
+   → Commit: "feat: implement Cache class with size()"
+
+🔄 Tâche 3: Test - Cache set/get
+   → En cours...
+```

package/skills/git-worktrees/SKILL.md

@@ -0,0 +1,105 @@
+# Git Worktrees
+
+> Créer un environnement de travail isolé pour développer une feature sans perturber la branche principale.
+
+## Triggers
+- L'utilisateur demande de commencer à travailler sur une feature
+- Le début d'un cycle de développement (après brainstorming)
+- Quand plusieurs features doivent être développées en parallèle
+
+## Instructions
+
+### 1. Vérifier l'État du Dépôt
+1. Vérifier que le dépôt est propre (`git status`)
+2. S'assurer que la branche principale est à jour
+3. Vérifier qu'aucun worktree n'existe déjà pour cette feature
+
+### 2. Créer le Worktree
+```bash
+# Créer une nouvelle branche et un worktree associé
+git worktree add ../<projet>-<feature-name> -b feature/<feature-name>
+
+# Se déplacer dans le worktree
+cd ../<projet>-<feature-name>
+```
+
+### 3. Setup Initial
+1. Installer les dépendances (`npm install` ou équivalent)
+2. Vérifier que les tests passent sur la branche fraîche
+3. Configurer les hooks Git si nécessaires
+
+### 4. Travailler dans le Worktree
+- Tout le développement de la feature se fait dans ce worktree
+- La branche principale reste inchangée
+- On peut ouvrir un éditeur séparé pour ce worktree
+
+### 5. Nettoyage (Finalization)
+Après merge de la feature :
+```bash
+# Supprimer le worktree
+git worktree remove ../<projet>-<feature-name>
+
+# Supprimer la branche si mergée
+git branch -d feature/<feature-name>
+```
+
+## Règles
+
+1. **Un worktree par feature** — isolation stricte
+2. **Jamais de travail direct sur main/master** — toujours une branche
+3. **Vérifier les tests avant de commencer** — baseline propre requise
+4. **Nettoyer après merge** — supprimer worktrees et branches inutiles
+5. **Nommage cohérent** — `feature/nom-court-descriptif`
+
+## Commandes Utiles
+
+```bash
+# Lister les worktrees
+git worktree list
+
+# Ajouter un worktree
+git worktree add <path> -b <branch-name>
+
+# Supprimer un worktree
+git worktree remove <path>
+
+# Forcer la suppression (si probleme)
+git worktree remove <path> --force
+
+# Nettoyer les worktrees manquants
+git worktree prune
+```
+
+## Sortie Attendue
+
+- [ ] Branche créée et checkout
+- [ ] Worktree configuré
+- [ ] Dépendances installées
+- [ ] Tests de base passent (baseline propre)
+- [ ] Prêt à écrire le plan
+
+## Exemple d'Utilisation
+
+```
+🌳 Git Worktree Setup
+
+Feature: systeme-cache-api
+
+1. Vérification de l'état du dépôt...
+   ✓ Dépôt propre
+   ✓ Branche main à jour
+
+2. Création du worktree...
+   $ git worktree add ../monprojet-cache -b feature/systeme-cache
+   ✓ Worktree créé
+
+3. Setup...
+   $ npm install
+   ✓ Dépendances installées
+
+4. Vérification des tests...
+   $ npm test
+   ✓ 42 tests passent (baseline propre)
+
+✅ Prêt pour le plan d'exécution
+```

package/skills/subagent-driven-development/SKILL.md

@@ -0,0 +1,109 @@
+# Subagent-Driven Development
+
+> Dispatch les tâches du plan à des sous-agents frais avec revue en deux étapes pour un développement autonome et fiable.
+
+## Triggers
+- Un plan avec des tâches parallélisables a été validé
+- L'utilisateur accepte le développement par sous-agents
+- Plus de 3 tâches dans le plan et certaines sont indépendantes
+
+## Instructions
+
+### 1. Préparer le Dispatch
+1. Identifier les tâches indépendantes (peuvent être faites en parallle)
+2. Grouper les tâches dépendantes en séquences
+3. Pour chaque groupe, préparer un **contexte d'agent** :
+   - Le design doc
+   - Le plan complet
+   - La/les tâches spécifiques à exécuter
+   - Les conventions du projet
+
+### 2. Dispatcher un Sous-Agent
+Pour chaque tâche ou groupe :
+
+```
+PROMPT TYPE pour sous-agent :
+
+---
+CONTEXTE:
+- Design Doc: [contenu ou référence]
+- Plan: [contenu ou référence]
+
+TÂCHE ASSIGNÉE:
+[Tâche N: description, fichiers, snippets attendus]
+
+RÈGLES:
+1. TDD strict — test d'abord
+2. Suivre le plan exactement
+3. Vérifier avec la commande spécifiée
+4. Retourner le code produit + résultat des tests
+
+SORTIE ATTENDUE:
+- Code complet des fichiers modifiés/créés
+- Résultat de la vérification
+- Notes ou problèmes rencontrés
+---
+```
+
+### 3. Revue en Deux Étapes
+
+#### Étape 1: Revue de Conformité
+- Le code suit-il le plan exactement ?
+- Toutes les tâches assignées sont-elles faites ?
+- Les tests spécifi passent-ils ?
+- **Si NON** → Renvoyer au sous-agent avec feedback
+
+#### Étape 2: Revue de Qualité
+- Appliquer le skill `code-review`
+- Vérifier lisibilité, complexité, duplication
+- **Si problèmes** → Demander corrections
+
+### 4. Continuer ou Corriger
+- Si les 2 revues passent → merger le code
+- Si échec → corriger ou réassigner
+- Progression mise à jour après chaque tâche
+
+## Règles
+
+1. **Contexte frais** — chaque sous-agent reçoit un contexte propre
+2. **Toujours 2 revues** — conformité + qualité
+3. **Plan = contrat** — le sous-agent ne dévie pas du plan
+4. **Feedback constructif** — expliquer pourquoi ça ne va pas
+5. **Progression visible** — toujours montrer X/Y tâches faites
+
+## Sortie Attendue
+
+- [ ] Sous-agents dispatchés avec contexte complet
+- [ ] Chaque sortie revue (conformité + qualité)
+- [ ] Tâches mergées ou retournées pour correction
+- [ ] Progression mise à jour
+- [ ] Prêt pour l'étape suivante du workflow
+
+## Exemple d'Utilisation
+
+```
+🤖 Subagent-Driven Development
+
+Plan: Système de Cache API (6 tâches)
+
+📦 Dispatch:
+  Groupe A (parallèle): Tâches 1, 2, 3 → Agent Alpha
+  Groupe B (parallèle): Tâches 4, 5 → Agent Beta
+  Séquentiel: Tâche 6 → Principal (dépend de A et B)
+
+🔄 Agent Alpha — Tâches 1-3:
+  Revue Conformité: ✅ OK
+  Revue Qualité: 🟡 1 warning (test LRU manquant)
+  → Correction demandée → ✅ OK après
+
+🔄 Agent Beta — Tâches 4-5:
+  Revue Conformité: ✅ OK
+  Revue Qualité: ✅ OK
+
+🔄 Principal — Tâche 6:
+  (après merging A et B)
+  ✅ Terminé
+
+Progression: 6/6 tâches ✅
+→ Prêt pour Code Review globale
+```