Comment installer le plugin Forge dans Claude Code ?

Dans une session Claude Code, sur n'importe quel projet : /plugin marketplace add gabrielmustiere/forge, puis /plugin install forge@forge, puis /reload-plugins. Les skills sont ensuite namespacées : /forge:help, /forge:feature-pitch, etc.

Quels sont les trois tracks de Forge ?

Le track feature couvre la valeur utilisateur (feature-pitch → feature-plan → feature-implem). Le track refacto restructure le code à comportement figé (refactor-plan → refactor-implem). Le track tech traite la performance, la résilience, l'observabilité et la sécurité (tech-plan → tech-implem). Le track ne change pas les phases traversées, seulement les skills appelées en phase 1 (cadrer) et en phase 2 (implémenter) : les trois partagent la même phase 3 de clôture, review → sync → commit.

Faut-il passer par tout le pipeline pour un simple bugfix ?

Non. Le track fast couvre les changements de moins de 3 fichiers, sans migration ni impact transverse : on code, on passe la QA du stack, puis /forge:commit. Pas de pitch pour un typo.

Forge est-il lié à un langage ou un framework ?

Non, le pipeline est stack-agnostique. Il détecte le stack du projet via composer.json ou package.json et charge les conventions QA, sécurité et performance correspondantes (Symfony, Sylius…).

Forge — pipeline de développement Claude Code, de l'idée à la release

Installation

Dans une session Claude Code, sur n'importe quel projet :

❯ /plugin marketplace add gabrielmustiere/forge
❯ /plugin install forge@forge
❯ /reload-plugins

Skills namespacées

/forge:help · /forge:feature-pitch …

Mettre à jour

/plugin marketplace update forge → /reload-plugins

Prérequis, concepts, référence des 25 skills, configuration des permissions et dépannage : voir la documentation complète.

Le pipeline

Quatre phases dans le temps, trois tracks symétriques selon la nature du changement. Chaque étape produit un artefact (pitch.md, plan.md, review.md…) validé par un ok explicite avant de passer à la suivante.

PHASE 0

Poser le décor — une fois, documents vivants

vision

Cap produit, personas, non-négociables

→ docs/vision.md
product-backlog

Stories priorisées, prêtes à cadrer

→ docs/product-backlog.md
stack

Choix techniques et conventions de code

→ docs/stack.md
agents-md

Commandes et conventions du dépôt, lues par tous les agents

→ AGENTS.md

PHASE 1

Cadrer — dans un seul des trois tracks

Track Feature

Valeur utilisateur (user-facing)
1. (feature-interview → brief.md)
2. feature-pitch → pitch.md
3. feature-plan → plan.md
Track Refacto

Comportement figé, code restructuré
1. refactor-plan → plan.md
Track Tech

Perf, résilience, observabilité, sécu
1. tech-plan → plan.md

PHASE 2

Implémenter — la skill du track choisi

feature-implem

Le plan devient code fonctionnel

→ code + migrations + tests
refactor-implem

Structure revue, comportement intact

→ code restructuré + tests
tech-implem

Brique posée, effet mesuré

→ code + mesures

PHASE 3

Clôturer — commune aux trois tracks

review

Sécu, régressions, conformité au plan

→ verdict
sync

Les écarts relevés, la doc rattrape le code réel

→ docs réalignées + report.md
commit

Message conventionnel, rebase strict

→ commit + push
release

Optionnel, quand on publie une version — pas à chaque story

→ tag + CHANGELOG.md + release GitHub

Tout vit dans `docs/story/`

Compteur global NNN-<f|r|t>-<slug> : le tri lexicographique donne la timeline du projet. Ex : 042-f-checkout-express/

Track fast — bugfix express

Moins de 3 fichiers, pas de migration ni d'impact transverse : on code, QA du stack, puis /forge:commit. Pas de pitch pour un typo.

Les skills

Vingt-cinq skills rangées par phase — le track choisi décide desquelles vous appelez en phases 1 et 2. Perdu en cours de route ? /forge:help est le GPS du pipeline.

Phase 0 — Poser le décor

Documents vivants · 4 modes : Création / Enrichir / Éditer / Pivot

/forge:vision: Cadre la vision : problème, audience, valeur, North Star, principes, anti-objectifs → docs/vision.md
/forge:product-backlog: Traduit la vision en domaines, capacités, parcours et backlog priorisé MVP/V2/V3, avec avancement coché → docs/product-backlog.md
/forge:stack: Cartographie la stack technique — chaque techno prouvée par un fichier source → docs/stack.md
/forge:agents-md: Génère ou migre l'AGENTS.md, lu par tous les agents : analyse du codebase + principes comportementaux

Phase 1 — Cadrer

Formaliser l'intention · une seule ligne selon le track choisi

/forge:feature-interview: Feature (optionnel) — découvre un besoin flou par interview guidée, ancrée sur le code existant → brief.md
/forge:feature-pitch: Feature — cadre l'idée et challenge l'alignement vision/backlog → pitch.md
/forge:feature-plan: Feature — plan technique : archi, données, contrats, migration, tests → plan.md
/forge:refactor-plan: Refacto — cadrage + tests de caractérisation à poser comme verrou → plan.md
/forge:tech-plan: Tech — cadrage avec métrique cible chiffrée + baseline + kill switch → plan.md

Phase 2 — Implémenter

Étapes courtes, QA du projet après chacune

/forge:feature-implem: Feature — implémentation guidée sous-tâche par sous-tâche, QA continue
/forge:refactor-implem: Refacto — exécution verrou-tests-d'abord, étapes incrémentales réversibles
/forge:tech-implem: Tech — exécution : baseline, kill switch, mesure après chaque étape

Phase 3 — Clôturer

Commune aux trois tracks

/forge:review: Code review du diff : sécu, qualité, conformité au plan, non-régression → verdict (review.md si un point reste ouvert)
/forge:sync: Relève les écarts entre l'intention et le livré, réaligne pitch/plan et les docs projet (vision, stack, product-backlog), coche les critères → écarts, dette et leçons dans report.md
/forge:commit: Message Conventional Commits en français (l'intention), commit + push — vient en dernier
/forge:release: Optionnel, quand on publie une version : tag SemVer annoté + CHANGELOG.md Keep a Changelog + release GitHub

Utilitaires

Hors pipeline

/forge:help: Sommaire du pipeline, tracks, skills et artefacts — le GPS
/forge:rules: Écrit les règles projet paths-scopées dans .claude/rules/ — chargées seulement sur la zone concernée
/forge:adr: Rédige un Architecture Decision Record MADR léger → docs/adr/NNNN-slug.md
/forge:status: Point de situation à la reprise : ce qui est en cours, où ça s'est arrêté, par quoi reprendre
/forge:grill: Passe une idée, une décision ou un plan au gril, une réponse recommandée par question — n'écrit rien
/forge:estimate: Chiffre le temps « tout compris » d'une story à facturer, en heures → estimate.md
/forge:test-scenario: Joue un scénario utilisateur en live via Playwright MCP
/forge:doc-feature: Cartographie une feature existante (legacy) → docs/feature-map/NNN-slug/overview.md
/forge:backfill-metadata: Reconstruit le metadata.json des stories antérieures depuis l'historique git — jamais de date inventée

Inventaire complet : plugins/forge/SKILLS.md · Le workflow détecte le stack (Symfony, Sylius…) via composer.json / package.json et charge les bonnes conventions QA, sécu et perf.

Forge Board — le projet lié

Un tableau kanban lecture seule qui scanne les documents produits par le workflow (docs/story/) et projette chaque story en carte le long d'un pipeline visuel — pour répondre en quelques secondes à « où en est le projet X ? ». Application Symfony 8 développée avec ce plugin, hébergée dans son propre dépôt.

Code, stack et installation : gabrielmustiere/forge-board