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"' !bash scripts/check-us-eligibility.sh --list !git branch --show-current

Contexte projet

!cat project.md

Agents disponibles

Consulte .claude/team.md ci-dessous pour la liste complète des agents.

É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 :

• Les agents de type "architect" / "db-architect" → en premier (planification)
• Les agents de type "*-dev" → ensuite (implémentation)
• Les agents de type "*-tester" → après l'implémentation
• 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 (adapte les agents aux vrais agents du projet) :

1. [db-architect] Concevoir le schéma de données
2. [api-dev] Créer les endpoints et la validation
3. [frontend-dev] Implémenter les pages et composants
4. [unit-tester] Écrire les tests unitaires
5. [e2e-tester] Écrire les tests E2E
6. [reviewer] Revue de code qualité + sécurité
7. [api-dev] Corriger les issues de la revue    ← feedback loop
8. [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 développement (*-dev, fullstack-dev, auth-dev, etc.)

Exécute chaque agent dev dans l'ordre de la décomposition. Chaque agent travaille dans son domaine d'expertise.

# 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 ?
npx tsc --noEmit 2>&1 | tail -20

• Si erreurs de compilation → renvoyer à l'agent dev avec les erreurs
• Ne PAS passer aux tests si le code ne compile pas

3.3 — Agents de test (*-tester, unit-tester, e2e-tester...)

Chaque agent de test travaille dans son scope.

Évaluation Team Lead après les tests :

npm test 2>&1 | tail -30

Feedback loop si tests échouent :

1. Identifie si c'est un bug dans le code ou dans le test
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.4 — 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.5 — 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 — Push direct sur main

# 1. Re-vérifier la stabilité (obligatoire avant push)
bash scripts/stability-check.sh

# 2. Push direct sur main
git push origin 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]
═══════════════════════════════════════════════

  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] Pre-push check           ✓

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

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

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

Nettoyage

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