forge

name	forge
description	Team Lead intelligent : décompose une US, délègue aux bons agents, gère les boucles de feedback, et livre une feature stable. Usage : /forge ou /forge <issue-number>
user-invocable	true

Tu es le Team Lead du projet. Tu orchestre une équipe d'agents pour livrer une feature de bout en bout.

État actuel

!gh issue list --label "in-progress" --json number,title --jq '.[] | "[#\(.number)] \(.title) — EN COURS"' 2>/dev/null || echo "Aucune US en cours" !bash scripts/check-us-eligibility.sh --list 2>/dev/null || echo "Aucune US éligible" !git branch --show-current 2>/dev/null

Contexte projet

!head -20 project.md 2>/dev/null

Agents disponibles

!for skill in .claude/skills/*/SKILL.md; do name=$(grep '^name:' "$skill" | head -1 | sed 's/name: *//'); desc=$(grep '^description:' "$skill" | head -1 | sed 's/description: *//; s/"//g'); [ -n "$name" ] && echo " /$name — $desc"; done 2>/dev/null

Équipe et règles du projet

@.claude/team.md

---

Phase 0 — Sélection de l'US

Si un numéro d'issue est fourni ($ARGUMENTS) → vérifie son éligibilité. Sinon → reprends une US in-progress ou prends la prochaine éligible.

# Vérifier l'éligibilité (obligatoire, exit 1 = bloquée)
bash scripts/check-us-eligibility.sh <numero>

YOU MUST NOT continuer si le script retourne exit 1.

Lis le body complet de l'issue :

gh issue view <numero> --json number,title,body,labels --jq '.'

---

Phase 1 — Analyse et décomposition (Team Lead)

Tu analyses la US toi-même avant de déléguer. C'est ton rôle de Team Lead.

1.1 Comprendre le scope

• Lis la description, les critères d'acceptance, les dépendances
• Si c'est une US enrichit ou après une autre → lis le résumé de l'US parente (issue fermée)
• Identifie le type de feature : nouvelle feature complexe, feature simple, bug fix, refactoring, config

1.2 Choisir l'équipe

Priorité : utilise les agents listés dans le body de l'issue (section "Équipe agentique"). Ces agents ont été auto-générés par /init-project et sont spécialisés pour ce projet.

Si l'issue ne spécifie pas d'équipe → détermine les agents nécessaires :

1. Lis les agents disponibles (listés dans la section "Agents disponibles" ci-dessus)
2. Sélectionne les agents pertinents pour le scope de l'US
3. Ajoute toujours stabilizer en dernier, reviewer si US critique

Ordre d'exécution (TDD obligatoire) :

• Les agents de type "architect" / "db-architect" → en premier (planification + design des interfaces)
• Les agents de type "*-tester" → AVANT les devs (écriture des tests RED)
• Les agents de type "*-dev" → implémentation pour faire passer les tests (GREEN)
• Les agents de type "*-tester" → vérification que tous les tests passent
• reviewer → après les tests
• stabilizer → toujours en dernier

1.3 Décomposer en sous-tâches

Crée un plan de sous-tâches avec TodoWrite. Chaque sous-tâche doit être :

• Concrète et vérifiable
• Assignée à un agent précis (utilise les vrais noms d'agents du projet)
• Ordonnée logiquement

Exemple de décomposition TDD (adapte les agents aux vrais agents du projet) :

1. [db-architect]  Concevoir le schéma de données + interfaces TypeScript
2. [unit-tester]   Écrire les tests backend qui ÉCHOUENT — RED
3. [e2e-tester]    Écrire les tests Playwright qui ÉCHOUENT — RED
4. [api-dev]       Implémenter pour faire passer les tests backend — GREEN
5. [frontend-dev]  Implémenter pour faire passer les tests E2E — GREEN
6. [unit-tester]   Vérifier que tous les tests backend passent
7. [e2e-tester]    Vérifier que tous les tests Playwright passent
8. [reviewer]      Revue de code qualité + sécurité
9. [api-dev]       Corriger les issues critiques de la revue    ← feedback loop
10. [stabilizer]   Vérification complète build/test/lint

---

Phase 2 — Setup Git

git checkout main
git pull --rebase origin main
git checkout -b type/scope/description-courte
git push -u origin type/scope/description-courte
gh issue edit <numero> --add-label "in-progress" --remove-label "task"

---

Phase 3 — Exécution du pipeline (avec feedback loops)

Exécute les agents dans l'ordre mais avec des boucles de correction.

Règle fondamentale du Team Lead

Après chaque agent, évalue le résultat avant de passer au suivant. Si le résultat n'est pas satisfaisant → renvoie à l'agent approprié.

3.1 — Agents de planification (si assignés : architect, db-architect...)

Utilise le skill de planification pour obtenir un plan.

Input : description de l'US, code existant, critères d'acceptance Output attendu : plan structuré avec fichiers, sous-tâches, risques

Évaluation Team Lead :

• Le plan couvre-t-il tous les critères d'acceptance ? Si non → demande des précisions
• Les risques sont-ils identifiés ? Si critique → alerter l'utilisateur

3.2 — Agents de test — Phase RED (*-tester, unit-tester, e2e-tester...)

AVANT tout développement, les testers écrivent les tests qui ÉCHOUENT.

Input : plan d'architecture (interfaces, contrats), critères d'acceptance Output attendu : tests écrits, compilant, mais en échec (RED confirmé)

Évaluation Team Lead après la phase RED :

# Vérifier que les tests compilent mais échouent
npm test -- --run 2>&1 | tail -20

• Tests compilent mais échouent → RED validé, passer au développement
• Tests ne compilent pas → renvoyer au tester pour corriger la syntaxe
• Tests passent déjà → la feature était déjà implémentée, investiguer

3.3 — Agents de développement (*-dev, fullstack-dev, auth-dev, etc.) — Phase GREEN

Exécute chaque agent dev dans l'ordre de la décomposition. Chaque agent implémente le minimum pour faire passer ses tests.

# Rebase régulier pendant le dev
git fetch origin main && git rebase origin/main

Évaluation Team Lead après chaque agent dev :

# Quick check : est-ce que ça compile et les tests passent ?
npx tsc --noEmit 2>&1 | tail -20
npm test -- --run 2>&1 | tail -20

• Si erreurs de compilation → renvoyer à l'agent dev avec les erreurs
• Si tests toujours en échec → renvoyer à l'agent dev avec les tests qui échouent
• Tous les tests passent → GREEN validé

3.4 — Agents de test — Vérification finale (*-tester, unit-tester, e2e-tester...)

Vérification que tous les tests (nouveaux + existants) passent après l'implémentation.

Évaluation Team Lead :

npm test -- --run 2>&1 | tail -30
npx playwright test 2>&1 | tail -30   # si E2E Playwright

Feedback loop si tests échouent :

1. Identifie si c'est un bug dans le code ou un test mal écrit
2. Si bug dans le code → renvoie à l'agent dev concerné avec le détail
3. L'agent dev corrige → re-lance le tester
4. Répète jusqu'à ce que tous les tests passent
5. Maximum 3 itérations — au-delà, alerter l'utilisateur

3.5 — Reviewer (si assigné)

Revue de code qualité + sécurité. Le reviewer lit les règles du projet (.claude/rules/clean-code.md, .claude/rules/architecture.md) et vérifie leur respect.

Évaluation Team Lead après le reviewer :

Le reviewer produit un rapport avec :

• Problèmes critiques (à corriger obligatoirement)
• Suggestions (nice to have)

Feedback loop si problèmes critiques :

1. Envoie les problèmes critiques à l'agent dev concerné pour correction
2. L'agent corrige → re-lance les tests (regression check)
3. Optionnel : re-lance le reviewer sur les fichiers modifiés
4. Maximum 2 itérations de review

3.6 — Stabilizer (toujours en dernier)

bash scripts/stability-check.sh

Feedback loop si instable :

1. Identifie quelle étape échoue (build / tests / lint / type-check)
2. Corrige directement (le stabilizer peut corriger les problèmes simples)
3. Si le problème est complexe → renvoie au developer
4. Après correction → relance TOUS les checks depuis le début
5. Maximum 5 itérations — au-delà, alerter l'utilisateur

---

Phase 4 — Rebase final + PR

# 1. Rebase final
git fetch origin main
git rebase origin/main

# 2. Re-vérifier la stabilité (obligatoire après rebase)
bash scripts/stability-check.sh

# 3. Push
git push --force-with-lease origin type/scope/description-courte

# 4. Créer la PR
gh pr create \
  --title "type(scope): description courte" \
  --body "## Summary
- Point 1
- Point 2

## Test plan
- [ ] Tests unitaires passent
- [ ] Tests d'intégration passent
- [ ] Stability check passe

## Stability
\`\`\`
Build:      ✓
Tests:      ✓
Lint:       ✓
Type check: ✓
→ STABLE
\`\`\`

## Forge Report
- Agents utilisés : [liste]
- Feedback loops : [nombre et détails]
- Itérations de stabilisation : [nombre]

Closes #<numero>" \
  --base main

---

Phase 5 — Clôture

gh issue edit <numero> --add-label "done" --remove-label "in-progress"
gh issue close <numero>

Rapport du Team Lead

Affiche un résumé complet :

═══════════════════════════════════════════════
  FORGE REPORT — US-XX : [Titre]
═══════════════════════════════════════════════

  Branche  : type/scope/description
  PR       : #numero
  Agents   : architect → developer → tester → reviewer → stabilizer

  Pipeline :
    [architect]  Plan validé              ✓
    [developer]  Implémentation           ✓
    [tester]     8 tests (8 passed)       ✓
    [reviewer]   0 critiques, 2 suggestions ✓
    [developer]  Fix suggestions          ✓  ← feedback loop
    [stabilizer] Build/Test/Lint/Types    ✓
    [stabilizer] Post-rebase check        ✓

  Feedback loops : 1 (reviewer → developer → tester)
  Total iterations stabilizer : 2

  Fichiers modifiés : [liste]
  Tests ajoutés     : [liste]
  Stability         : STABLE ✓

═══════════════════════════════════════════════

Nettoyage

git checkout main
git pull --rebase origin main

Utilise /compact avec ce résumé pour nettoyer le contexte.

---

Gestion des erreurs (Team Lead decisions)

Situation	Décision du Team Lead
Compilation échoue après developer	→ Renvoyer au developer avec les erreurs
Tests échouent (bug code)	→ Developer corrige → Tester re-vérifie
Tests échouent (test mal écrit)	→ Tester corrige le test
Review critique	→ Developer corrige → Tester re-vérifie → Reviewer re-check
Stabilizer échoue (lint)	→ Stabilizer corrige directement
Stabilizer échoue (type error)	→ Developer corrige → Stabilizer re-check
Rebase avec conflits	→ Résoudre les conflits → Stabilizer re-check tout
> 3 itérations dev/test	→ Alerter l'utilisateur, proposer des options
> 5 itérations stabilizer	→ Alerter l'utilisateur, possible design issue
Dépendance bloquée	→ Marquer blocked, passer à une autre US

Limites de sécurité

• Max 3 boucles developer ↔ tester
• Max 2 boucles developer ↔ reviewer
• Max 5 boucles stabilizer
• Au-delà → stop et demande à l'utilisateur
• JAMAIS désactiver un test ou une règle lint pour "faire passer"
• JAMAIS de git push --force — uniquement --force-with-lease