forge / site

# Forge

> Forge est un plugin Claude Code stack-agnostique qui pilote tout le cycle de développement, de l'idée à la release. Il découpe le travail en étapes courtes validées une à une : chaque étape produit un artefact markdown (`pitch.md`, `plan.md`, `review.md`, `report.md`…) qui alimente la suivante. Aucune étape ne démarre sans validation explicite de l'utilisateur.

Version : 6.10.0 · Licence : Apache-2.0 · Auteur : Gabriel Mustiere · Dépôt : https://github.com/gabrielmustiere/forge

Installation dans une session Claude Code :

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

Les skills sont namespacées par le nom du plugin : `/forge:help`, `/forge:feature-pitch`, etc. Mise à jour : `/plugin marketplace update forge` puis `/reload-plugins`.

## Structure du pipeline

Le pipeline compte 26 skills et se lit sur deux axes. La **phase** dit *quand* : quatre phases, dans l'ordre. Le **track** dit *avec quelles skills* : à phase égale, une feature, un refacto et une évolution technique n'appellent pas les mêmes. Le track se choisit à l'entrée de la phase 1 et ne modifie pas les phases traversées.

- **Phase 0 — poser le décor** (une fois pour le projet, documents vivants à 4 modes : Création / Enrichir / Éditer / Pivot) : `vision` → `docs/vision.md`, `product-backlog` → `docs/product-backlog.md`, `stack` → `docs/stack.md`.
- **Phase 1 — cadrer** : selon le track, `feature-interview` (optionnel, → `brief.md`) → `feature-pitch` (→ `pitch.md`) → `feature-plan` (→ `plan.md`) ; ou `refactor-plan` (→ `plan.md`, avec tests de caractérisation) ; ou `tech-plan` (→ `plan.md`, avec métrique cible, baseline et kill switch). Les trois tracks produisent un `plan.md` ; seul le track feature intercale un `pitch.md` fonctionnel en amont.
- **Phase 2 — implémenter** : `feature-implem`, `refactor-implem` ou `tech-implem`. Étapes courtes, QA du projet après chacune.
- **Phase 3 — clôturer**, commune aux trois tracks : `review` (→ `review.md`) → `report` (→ `report.md`) → `sync` → `commit`. Le `commit` vient en dernier et embarque d'un coup le code, le `report.md` et les docs réalignées.

Les trois tracks : **feature** (valeur utilisateur observable), **refacto** (comportement externe strictement figé, verrou de tests de caractérisation avant toute modification), **tech** (perf, résilience, observabilité, sécu — métrique cible chiffrée, baseline, kill switch). Hors de ce découpage, le **track fast** couvre les bugfixes : moins de 3 fichiers, pas de migration ni d'impact transverse → on code, on passe la QA du stack, puis `/forge:commit`. Pas de pitch pour un typo.

Tous les artefacts vivent à plat dans `docs/story/` au format `NNN-<f|r|t>-<slug>` (compteur global d'abord, puis le tag de track), pour que le tri lexicographique donne la timeline du projet. Exemple : `docs/story/042-f-checkout-express/`.

## Skills

- `/forge:vision` — cadre la vision projet : problème, audience, valeur, North Star, principes, anti-objectifs.
- `/forge:product-backlog` — traduit la vision en domaines, capacités, parcours et backlog priorisé MVP/V2/V3, avec un avancement en cases à cocher dérivé des stories livrées.
- `/forge:stack` — cartographie la stack ; chaque techno prouvée par un fichier source.
- `/forge:feature-interview` — dégrossit un besoin flou par interview guidée ancrée sur le code existant.
- `/forge:feature-pitch` — cadre l'idée et challenge l'alignement vision/backlog.
- `/forge:feature-plan` — plan technique : archi, données, contrats, migration, tests.
- `/forge:feature-implem` — implémentation guidée sous-tâche par sous-tâche, QA continue.
- `/forge:refactor-plan` — cadrage refacto et tests de caractérisation posés comme verrou.
- `/forge:refactor-implem` — exécution verrou-tests-d'abord, étapes incrémentales réversibles.
- `/forge:tech-plan` — cadrage avec métrique cible chiffrée, baseline et kill switch.
- `/forge:tech-implem` — exécution mesurée après chaque étape.
- `/forge:review` — code review du diff : sécu, qualité, conformité au plan, non-régression.
- `/forge:commit` — message Conventional Commits en français, commit et push.
- `/forge:report` — compte rendu honnête : fait vs prévu, écarts, dettes.
- `/forge:sync` — réaligne les docs d'intention et les docs projet sur le code livré.
- `/forge:help` — sommaire du pipeline, tracks, skills et artefacts.
- `/forge:claude-md` — génère ou met à jour le `CLAUDE.md` du projet.
- `/forge:rules` — écrit les règles projet paths-scopées dans `.claude/rules/`.
- `/forge:status` — point de situation à la reprise : stories en cours, étape atteinte, état du dépôt, par quoi reprendre. Lecture seule.
- `/forge:test-scenario` — joue un scénario utilisateur en live via Playwright MCP.
- `/forge:adr` — rédige un Architecture Decision Record MADR léger dans `docs/adr/`.
- `/forge:estimate` — chiffre le temps « tout compris » d'une story à facturer, en heures.
- `/forge:doc-feature` — cartographie une feature existante (legacy) dans `docs/feature-map/`.
- `/forge:backfill-metadata` — reconstruit le `metadata.json` des stories antérieures depuis git.
- `/forge:release` — tag SemVer annoté, `CHANGELOG.md` Keep a Changelog et release GitHub.

## Forge Board

Projet lié, dans son propre dépôt : https://github.com/gabrielmustiere/forge-board. Application Symfony 8 développée avec ce plugin — kanban en lecture seule qui scanne les `docs/story/` de dépôts forge et projette chaque story en carte le long d'un pipeline visuel.

## Liens

- [Documentation développeur](https://forge.mustiere.fr/docs/) — prérequis, installation pas à pas, concepts, référence des 26 skills, permissions, dépannage
- [Dépôt GitHub](https://github.com/gabrielmustiere/forge)
- [Inventaire complet des skills](https://github.com/gabrielmustiere/forge/blob/main/plugins/forge/SKILLS.md)
- [Releases](https://github.com/gabrielmustiere/forge/releases)
- [Marketplace de skills framework (Symfony, Sylius, éditorial)](https://github.com/gabrielmustiere/skills)