Brian
ee47e30cf6
* refactor(bmad-ux): replace bmad-create-ux-design with lean spine-based bmad-ux
* refactor(bmad-ux): adopt DESIGN.md spec, split into two-file spine, align prd/brief
DESIGN.md (visual identity per the Google Labs spec) and EXPERIENCE.md
(behavior, flow, IA) replace the single design.md spine. EXPERIENCE.md
cross-references DESIGN.md tokens via the spec's {path.to.token} syntax.
Example suite restructure
- 3 DESIGN.md examples: editorial (Stitch source / Linen & Logic), calm
native mobile (Quill), shadcn-on-Tailwind web SaaS (Drift)
- 2 paired EXPERIENCE.md examples (Quill, Drift); Linen & Logic unpaired
to model the Stitch handoff scenario
- Replaces the prior 2-example combined spine set
Discovery additions (outcome-driven, one line each)
- Source scan: glob {planning_artifacts}/ for candidates, parent never reads
- Form-factor: resolve before IA closes; journeys often derive it
- Surface closure: every stated need has a surface, every surface a journey
- Named-protagonist journeys (Mary, not "the user")
- Design handoff working mode (extensible producer registry, default: Stitch)
PRD and brief alignment with same insights
- bmad-prd: dropped standalone Primary Persona section from template;
renamed "Personas + Journeys" entry to "Journey-led"; named-protagonist
rule on UJs; form-factor probe; validation checklist updated
- bmad-product-brief: form-factor surfaced in Discovery topics
Quality scan fixes
- Added ## Overview heading; renamed ## Activation to ## On Activation
- Replaced ../ paths in example assets with {planning_artifacts}/
- Sources section compressed (abstract delta-only rule)
- Working mode aligned to "Fast path" / "Coaching path" BMad-wide convention
New
- references/design-md-spec.md: working summary of the spec for the LLM
- customize.toml: design_md_examples, experience_md_examples,
design_handoffs registries
- .prettierignore: ignore .analysis/ quality-scan artifacts repo-wide
* refactor(bmad-ux): activation parity with prd/brief, opt-in reviewer gate, no headline grade
- Restructure On Activation as numbered six-step list mirroring bmad-prd
and bmad-product-brief, restoring the explicit key-resolution list that
earlier crammed-paragraph form had dropped (planning_artifacts and
friends were silently unresolved at Create).
- Make Reviewer Gate opt-in and lens-selectable. At Finalize, ask before
spending tokens on parallel reviewer subagents; at Validate intent,
skip that question but still confirm lens picks. Stops the auto-run
WCAG audit on hobby-stakes work.
- Drop the overall validation grade. Per-category verdicts and severity
counts already say what is true; a single headline grade conflated
design rigor with release readiness and led "POOR" pills landing on
reports whose own bodies described the work as strong. Removed from
references/validate.md (ladder rule + markdown twin), HTML template
(grade pill div + CSS vars + classes).
- Trim creative-tools.md: drop the Custom entries section. Runtime
prompt files should only carry what the LLM needs to act in this
moment; how-to-extend-via-TOML is setup-time human documentation
already covered by customize.toml comments.
* fix(bmad-ux): align validation report template with 8-category rubric
Template placeholders referenced 'Decision-readiness' and 'seven dimensions'
from the prior rubric. Replace with TEMPLATE_CATEGORY_NAME and inline the
eight canonical categories from references/validate.md so the synthesis pass
names them verbatim.
* fix(validate-skills): remove stale WF-01/WF-02 rules
WF-01/WF-02 were originally scoped to workflow.md files (now mostly gone)
but had been generalized to flag name/description in any non-SKILL.md
markdown. That over-captured legitimate spec files — e.g. DESIGN.md
examples in bmad-ux/assets/ that carry name/description per the Google
Labs DESIGN.md spec.
Step files are already covered by STEP-06. Rule count: 14 → 12.
* fix(bmad-ux): address PR review followups
- validation-report-template.html: severity badge class is badge-sev-*,
not sev-* (the comment misled the synthesis pass).
- Sweep dangling bmad-create-ux-design references: module-help.csv,
bmad-agent-ux-designer/customize.toml, bmad-prd/SKILL.md handoff list,
workflow-map.md (en + 4 translations), getting-started.md (en + 4
translations). Workflow-map output column updated to DESIGN.md +
EXPERIENCE.md.
- references/validate.md: Markdown capitalized as a proper noun.
9.0 KiB
title, description, sidebar
| title | description | sidebar | ||
|---|---|---|---|---|
| Carte des Workflows | Référence visuelle des phases et des résultats des workflows de la méthode BMad |
|
La méthode BMad (BMM) est un module de l'écosystème BMad, conçu pour suivre les meilleures pratiques de l'ingénierie du contexte et de la planification. Les agents IA fonctionnent de manière optimale avec un contexte clair et structuré. Le système BMM construit ce contexte progressivement à travers 4 phases distinctes — chaque phase, et plusieurs workflows optionnels au sein de chaque phase, produisent des documents qui alimentent la phase suivante, afin que les agents sachent toujours quoi construire et pourquoi.
La logique et les concepts proviennent des méthodologies agiles qui ont été utilisées avec succès dans l'industrie comme cadre mental de référence.
Si à tout moment vous ne savez pas quoi faire, le skill bmad-help vous aidera à rester sur la bonne voie ou à savoir
quoi faire ensuite. Vous pouvez toujours vous référer à cette page également — mais bmad-help est entièrement
interactif et beaucoup plus rapide si vous avez déjà installé la méthode BMad. De plus, si vous utilisez différents
modules qui ont étendu la méthode BMad ou ajouté d'autres modules complémentaires non extensifs — bmad-help évolue
pour connaître tout ce qui est disponible et vous donner les meilleurs conseils du moment.
Note finale importante : Chaque workflow ci-dessous peut être exécuté directement avec l'outil de votre choix via un skill ou en chargeant d'abord un agent et en utilisant l'entrée du menu des agents.
Ouvrir le diagramme dans un nouvel onglet ↗
Phase 1 : Analyse (Optionnelle)
Explorez l’espace problème et validez les idées avant de vous engager dans la planification. Découvrez ce que fait chaque outil et quand l’utiliser.
| Workflow | Objectif | Produit |
|---|---|---|
bmad-brainstorming |
Brainstormez des idées de projet avec l’accompagnement guidé d’un coach de brainstorming | brainstorming-report.md |
bmad-domain-research, bmad-market-research, bmad-technical-research |
Validez les hypothèses de marché, techniques ou de domaine | Rapport de recherches |
bmad-product-brief |
Capturez la vision stratégique — idéal lorsque votre concept est clair | product-brief.md |
bmad-prfaq |
Working Backwards — éprouvez et forgez votre concept produit | prfaq-{project}.md |
Phase 2 : Planification
Définissez ce qu'il faut construire et pour qui.
| Workflow | Objectif | Produit |
|---|---|---|
bmad-create-prd |
Définissez les exigences (FRs/NFRs)1 | PRD.md2 |
bmad-ux |
Concevez l'expérience utilisateur (lorsque l'UX compte) | DESIGN.md, EXPERIENCE.md |
Phase 3 : Solutioning
Décidez comment le construire et décomposez le travail en stories.
| Workflow | Objectif | Produit |
|---|---|---|
bmad-create-architecture |
Rendez les décisions techniques explicites | architecture.md avec ADRs3 |
bmad-create-epics-and-stories |
Décomposez les exigences en travail implémentable | Fichiers d'epic avec stories |
bmad-check-implementation-readiness |
Vérification avant implémentation | Décision Passe/Réserves/Échec |
Phase 4 : Implémentation
Construisez, une story à la fois. Bientôt disponible : automatisation complète de la phase 4 !
| Workflow | Objectif | Produit |
|---|---|---|
bmad-sprint-planning |
Initialisez le suivi (une fois par projet pour séquencer le cycle de développement) | sprint-status.yaml |
bmad-create-story |
Préparez la story suivante pour implémentation | story-[slug].md |
bmad-dev-story |
Implémentez la story | Code fonctionnel + tests |
bmad-code-review |
Validez la qualité de l'implémentation | Approuvé ou changements demandés |
bmad-correct-course |
Gérez les changements significatifs en cours de sprint | Plan mis à jour ou réorientation |
bmad-sprint-status |
Suivez la progression du sprint et le statut des stories | Mise à jour du statut du sprint |
bmad-retrospective |
Revue après complétion d'un epic | Leçons apprises |
bmad-investigate |
Enquête de cas avec conclusions à preuves graduées, calibrée selon l'entrée | {slug}-investigation.md |
Quick Dev (Parcours Parallèle)
Sautez les phases 1-3 pour les travaux de faible envergure et bien compris.
| Workflow | Objectif | Produit |
|---|---|---|
bmad-quick-dev |
Flux rapide unifié — clarifie l'intention, planifie, implémente, révise et présente | spec-*.md + code |
Gestion du Contexte
Chaque document devient le contexte de la phase suivante. Le PRD2 indique à l'architecte quelles contraintes sont importantes. L'architecture indique à l'agent de développement quels modèles suivre. Les fichiers de story fournissent un contexte focalisé et complet pour l'implémentation. Sans cette structure, les agents prennent des décisions incohérentes.
Contexte du Projet
:::tip[Recommandé]
Créez project-context.md pour vous assurer que les agents IA suivent les règles et préférences de votre projet. Ce
fichier fonctionne comme une constitution pour votre projet — il guide les décisions d'implémentation à travers tous les
workflows. Ce fichier optionnel peut être généré à la fin de la création de l'architecture, ou dans un projet existant
il peut également être généré pour capturer ce qui est important de conserver aligné avec les conventions actuelles.
:::
Comment le créer :
- Manuellement — Créez
_bmad-output/project-context.mdavec votre pile technologique et vos règles d'implémentation - Générez-le — Exécutez
bmad-generate-project-contextpour l'auto-générer à partir de votre architecture ou de votre codebase
En savoir plus sur project-context.md
Glossaire
-
FR / NFR (Functional / Non-Functional Requirement) : exigences décrivant respectivement ce que le système doit faire (fonctionnalités, comportements attendus) et comment il doit le faire (contraintes de performance, sécurité, fiabilité, ergonomie, etc.). ↩︎
-
PRD (Product Requirements Document) : document de référence qui décrit les objectifs du produit, les besoins utilisateurs, les fonctionnalités attendues, les contraintes et les critères de succès, afin d’aligner les équipes sur ce qui doit être construit et pourquoi. ↩︎
-
ADR (Architecture Decision Record) : document qui consigne une décision d’architecture, son contexte, les options envisagées, le choix retenu et ses conséquences, afin d’assurer la traçabilité et la compréhension des décisions techniques dans le temps. ↩︎