bmad-code-org__bmad-method/docs/zh-cn/reference/workflow-map.md at main

mirror of https://github.com/bmad-code-org/BMAD-METHOD.git synced 2026-09-19 08:11:52 +08:00

Files

T

Brian cf54f4d76d refactor(bmm): consolidate sprint skills — one owner for the sprint-status artifact (#2659 )

* refactor(bmm): move sprint-planning and sprint-status to plan/

They sit at the plan/ship boundary and their outputs are planning
artifacts of the dev cycle; next commit makes sprint-planning the
readiness gate, which is plan-side work.

* refactor(bmm): fold readiness gate into sprint-planning, retire check-implementation-readiness

The old skill was 1,154 lines of legacy numbered-step ceremony whose
document discovery hardcoded filename globs (*prd*, *ux*, *epic*) that
miss what current skills produce (SPEC.md, DESIGN.md) and still treated
retired sharded docs as first-class. Sprint-planning now opens with a
lean readiness gate: generic artifact discovery by content, forward/back
traceability, PASS/CONCERNS/FAIL, stop on FAIL with findings. The IR
trigger on John's and Winston's menus dispatches sprint-planning, so
'check implementation readiness' still works everywhere it used to.

* refactor(bmm): modernize sprint-planning with deterministic script core

SKILL.md drops the legacy XML step dialect for the product-brief style
(~100 lines, uv run, headless contract). New scripts/sprint_plan.py owns
the mechanical work — epic parsing, key derivation, ordering, preserve-
never-downgrade merge, story-file detection, action_items carry-over,
atomic writes, drift checks — with 11 tests wired in as
test:sprint-planning. Judgment stays with the LLM: epic discovery, the
readiness gate, and reconciling script-reported orphans and unparsed
headings. checklist.md retired (the script performs that checklist);
sprint-status-template.yaml is the single source for the status
vocabulary. Output stays byte-compatible with build's sprint sync and
retrospective's tooling.

* refactor(bmm): fold sprint-status into sprint-planning's status view

sprint_plan.py gains a status subcommand: counts (legacy values mapped),
risk flags, open action items, and a priority-ordered next-action
recommendation — the old skill's inference-driven summary, computed
deterministically and covered by 9 new tests. bmad-sprint-status becomes
a v6-shims husk that forwards with status-view intent and a deprecation
notice; its dead data/validate modes had zero callers and are gone. If
a hand-edited status file defeats the script, the skill falls back to
reading it directly and summarizing by best judgment. New explanation
page docs/explanation/sprint-planning.md covers the consolidated skill;
workflow maps and references updated across all languages.

* docs: changelog entries for skill reorg and sprint consolidation

* fix(bmm): harden sprint_plan.py per review; add validate/fix intents with full progressive disclosure

Review fixes (PR #2659 findings, bot + internal review):
- Normalize legacy v6 statuses (drafted/contexted) on every read — merged by
  meaning and reported, never treated as illegal or reset
- dropped_orphans carry their old status; transplant renames via --set
- project_key/tracking_system/story_location preserved from the existing file
  unless overridden; refresh round-trips custom keys and user comments
- Hardened write path: dump-to-bytes, fsync, permission-preserving atomic
  write inside the guarded block, explicit checks (no asserts), atomic restore
- JSON-only argparse (errors and -h emit JSON); unicode-aware slugs with hash
  fallback; fenced code blocks ignored when parsing epics
- Odd retro keys, date-typed stamps, and non-mapping YAML report cleanly
  instead of crashing; unparseable timestamps warn instead of silently
  disabling the staleness check; malformed action items flagged, not dropped
- Dead check subcommand removed; generate --dry-run reports drift/in_sync
- test:sprint-planning wired into quality and CI (was test-only)
- Retro tests use a vendored template fixture (PATH-05); repo-level
  test-template-sync.js keeps it byte-identical to the source; template
  example timestamps and story_location fixed; header block pinned to the
  template by test

New capability:
- validate subcommand + reference: structural validation, never writes
- fix flow: evidence-gathering subagents -> user-confirmed state table ->
  generate --fresh --set writes a pristine file (the one path allowed to
  downgrade); universal script-failure fallback to inference for every intent
- SKILL.md is now a lean router: gate, tracking, status, fix, and validate
  each load as progressive-disclosure references

Docs: explanation page gains Repair section; workflow-map and getting-started
across all five languages mention the status view; headless payload nests
under 'report' to avoid the status key collision; changelog updated.

Test suite grows 20 -> 37; retro suite 91/91; docs build and validators green.

* docs: mention repair in sprint-planning explanation description

2026-08-01 16:21:38 -05:00

4.2 KiB

Raw Permalink Blame History

title, description, sidebar

title

description

sidebar

工作流地图

BMad Method 各阶段 workflow 与产出速查

order
1

BMad Method（BMM）通过分阶段 workflow 逐步构建上下文，让智能体始终知道“做什么、为什么做、如何做”。这张地图用于快速查阅阶段目标、关键 workflow 和对应产出。

如果你不确定下一步，优先运行 bmad-help。它会基于你当前项目状态和已安装模块给出实时建议。

在新标签页打开图表 ↗

阶段 1：分析（可选）

在正式规划前，先验证问题空间与关键假设。

Workflow	目的	产出
`bmad-brainstorming`	通过引导式创意方法扩展方案空间	`brainstorming-report.md`
`bmad-deep-recon`	验证假设或在候选方案间做选择——可为你的深度研究工具起草提示词、加工其报告，或直接在此研究；覆盖市场、领域、技术、竞争、用户之声与学术研究；经核实、有引用、可刷新	研究报告或摘要 + 可选 HTML 简报
`bmad-create-product-brief`	沉淀产品方向与战略愿景	`product-brief.md`

阶段 2：规划

定义“为谁做、做什么”。

Workflow	目的	产出
`bmad-prd`	明确 FR/NFR 与范围边界	`PRD.md`
`bmad-ux`	在 UX 复杂场景下补齐交互与体验方案	`DESIGN.md`, `EXPERIENCE.md`
`bmad-spec`	将任意意图输入（brief、PRD、转录、想法笔记）提炼为精炼的 `SPEC.md` 契约及配套文件 —— 先锁定“做什么”，再谈“怎么做”	`SPEC.md` 及配套文件，位于 `{output_folder}/specs/spec-{slug}/`

阶段 3：解决方案设计（Solutioning）

定义“如何实现”并拆分可交付工作单元。

Workflow	目的	产出
`bmad-architecture`	显式记录技术决策与架构边界	`architecture.md`（含 ADR）
`bmad-create-epics-and-stories`	将需求拆分为可实施的 epics/stories	epics 文件与 story 条目
`bmad-sprint-planning`	实施前就绪 gate 检查，随后生成 story 追踪与冲刺状态摘要	PASS / CONCERNS / FAIL + `sprint-status.yaml`

阶段 4：实施

所有实施入口都汇入 bmad-build。它可以接收直接意图、issue、规格或已规划 story，并自行选择所需的澄清、规划、实现和审查深度。

Workflow	目的	产出
`bmad-build`	将直接意图或已规划 story 转化为完成实现并经过审查的代码	`spec-*.md` + 代码变更
`bmad-code-review`	验证实现质量	通过或变更请求
`bmad-correct-course`	处理中途重大方向调整	更新后的计划或重路由
`bmad-retrospective`	epic 完成后复盘	经验与改进项

直接入口与规划入口

目标清晰的工作可以直接进入 bmad-build。更大的项目可以先准备 PRD、UX、架构、epics、stories、就绪检查和 sprint 计划。上游产物只会增加实施上下文，不会选择另一条实施工作流。

上下文管理

每个阶段产出都会成为下一阶段输入：PRD 约束架构，架构约束开发，story 约束实现。没有这条链路，智能体更容易在跨 story 时出现不一致决策。

:::tip[Project Context 建议] 创建 project-context.md，把项目特有约定（技术栈、命名、组织、测试策略）写成共享规则，能显著降低实现偏差。 :::

创建方式：

手动创建：在 _bmad-output/project-context.md 记录项目规则
自动生成：运行 bmad-generate-project-context 从架构或代码库提取

4.2 KiB Raw Permalink Blame History Unescape Escape