Brian
d2b87b849b
* Rename bmad-checkpoint-preview to bmad-walkthrough
"Checkpoint" said nothing about what the skill does and "preview" was wrong: it is a guided human walkthrough of a change, not a preview. Its siblings bmad-code-review and bmad-review already own "review", so the new name leans on what sets this one apart. "Walk me through this change" was already its trigger phrase.
- Skill folder, SKILL.md name/description, module-help.csv (menu code CK -> WT), marketplace.json
- Trigger words are now "walkthrough", "walk me through this change", "human review"; "checkpoint" is dropped
- English how-to page moves to docs/build/walk-through-a-change.md; build-a-change link updated
- fr, vi-vn, zh-cn pages move to docs/<lang>/build/walk-through-a-change.md to mirror the English path; explanation sidebar orders renumbered to close the gap
- Redirects for the old English and localized routes; sidebar label and translations updated
- Diagram assets renamed (image contents unchanged)
* Regenerate walkthrough diagrams with the new title
Title reads Walkthrough and the input box reads bmad-build spec file (was quick-dev, stale since the Build rename). English and French, same layout and style as before.
* Add bmad-checkpoint-preview forwarding shim
Forwards to bmad-walkthrough and offers to migrate legacy _bmad/custom/bmad-checkpoint-preview{,.user}.toml files, same as the other v6 shims.
* Point test-completed-work links at the renamed walkthrough page
2.6 KiB
title, description, sidebar
| title | description | sidebar | ||
|---|---|---|---|---|
| FAQ Projets Existants | Questions courantes sur l’utilisation de la méthode BMad sur des projets existants |
|
Réponses rapides aux questions courantes sur l’utilisation de la méthode BMad (BMM) sur des projets existants.
Questions
- Dois-je d’abord exécuter document-project ?
- Que faire si j’oublie d’exécuter document-project ?
- Comment fonctionne l’implémentation dans les projets existants ?
- Que faire si mon code existant ne suit pas les bonnes pratiques ?
Dois-je d’abord exécuter document-project ?
Hautement recommandé, surtout si :
- Aucune documentation existante
- La documentation est obsolète
- Les agents IA ont besoin de contexte sur le code existant
Vous pouvez l’ignorer si vous disposez d’une documentation complète et à jour incluant docs/index.md ou si vous utiliserez d’autres outils ou techniques pour aider à la découverte afin que l’agent puisse construire sur un système existant.
Que faire si j’oublie d’exécuter document-project ?
Ne vous inquiétez pas — vous pouvez le faire à tout moment. Vous pouvez même le faire pendant ou après un projet pour aider à maintenir la documentation à jour.
Comment fonctionne l’implémentation dans les projets existants ?
Exécutez bmad-build, comme pour un nouveau développement. Le workflow va :
- Détecter automatiquement votre pile technologique existante
- Analyser les patterns de code existants
- Détecter les conventions et demander confirmation
- Générer une spécification technique riche en contexte qui respecte le code existant
Vous pouvez entrer directement pour une modification claire ou fournir une story planifiée et ses artefacts amont pour un travail plus vaste.
Que faire si mon code existant ne suit pas les bonnes pratiques ?
Build détecte vos conventions et demande : « Dois-je suivre ces conventions existantes ? » Vous décidez :
- Oui → Maintenir la cohérence avec la base de code actuelle
- Non → Établir de nouvelles normes (documenter pourquoi dans la spécification technique)
BMM respecte votre choix — il ne forcera pas la modernisation, mais la proposera.
Une question sans réponse ici ? Veuillez ouvrir un ticket ou poser votre question sur Discord afin que nous puissions l’ajouter !