BMAD-METHOD 实战把计划拆成故事并持续追踪Story Breakdown Sprint Planning 完整工作流【免费下载链接】BMAD-METHODBreakthrough Method for Agile Ai Driven Development项目地址: https://gitcode.com/gh_mirrors/bm/BMAD-METHOD导读本指南讲解 BMAD-METHOD 中计划落地的核心环节如何把一份已完成的规划spec 或 PRD拆解为可在一个会话内实现的故事单元并用sprint-status.yaml追踪它们的生命周期。读完本文你将掌握两条路径的完整流程——spec 驱动的 Story Breakdown 与 PRD 驱动的bmad-create-epics-and-storiesbmad-sprint-planning以及就绪门禁readiness gate、状态生成、状态查看、追踪文件修复和方向纠正correct course五大操作的具体命令与判定逻辑所有结论均有仓库源码与测试佐证。两条路径先想清楚拆什么BMAD-METHOD 把把计划变成故事分成两种形态取决于你的计划是什么。原文 break-work-into-stories-and-track-it.md 用一张表给出了决策入口计划形态要做的事追踪产物由SPEC.md支撑的单个 epic请bmad-spec做 Story Breakdown位于SPEC.md旁边的有序stories.yaml带 PRD以及 UX 或架构的项目先运行bmad-create-epics-and-stories再运行bmad-sprint-planningepic 文件 sprint-status.yaml路径一spec 支撑的 epic ——stories.yaml即全部追踪在 spec 路径下stories.yaml是整个追踪文件不涉及 sprint-status 文件。bmad-spec 的 Story Breakdown 一节明确输出物是与SPEC.md同级的stories.yaml通过固定文件名发现与SPEC.md、.memlog.md同一约定不列入companions:也不会被前端配置引用——它是派发故事的输入而非下游消费的契约。Story Breakdown 是纯交互式操作headless 运行永远不会执行它它逐个能力capability与约束constraint和用户对话按可独立评审的切片提议故事并为每个故事收集三个关键字段spec_checkpoint、done_checkpoint以及可选的invoke_dev_with派发备注——这正是开发者可照着实现的来源。字段定义、合法性与校验规则见 assets/stories-schema.md。构建流程会把每个故事的实现记录写到 spec 文件夹下而 Finish an Epic 把stories.yaml当作清单来读取。路径二PRD 项目 —— epic 文件 sprint-status对完整项目bmad-create-epics-and-stories以产品合伙人身份与用户协作把 PRD 的需求和架构决策转化为按用户价值组织的 epic 文件每个故事都带有开发者可以对照实现的验收标准。该技能采用步骤文件架构step-file architecture按 step-01-validate-prerequisites.md → step-02-design-epics.md → step-03-create-stories.md → step-04-final-validation.md 顺序执行每次只加载一个步骤文件不允许跳步最终文档通过 frontmatter 的stepsCompleted数组记录进度见 SKILL.md 的 WORKFLOW ARCHITECTURE 一节。本文之后的所有内容都围绕路径二展开。就绪门禁Readiness Gate用老手读交接单的眼光审计划bmad-sprint-planning运行在规划与实现的分界线上。在任何追踪文件存在之前它先像一位持怀疑态度的资深开发者在读交接单那样审视计划。关键点在于见 references/readiness-gate.md按内容盘点不按文件名它扫描{planning_artifacts}与{project_knowledge}识别 brief、PRFAQ、PRD、spec、UX 产出、架构、epics 等文档——靠读内容判断是什么而不是靠文件名模式匹配因为不同项目的产物组合与命名各不相同。只问一个问题开发者能否实现这些 epic而无需凭空发明任何没有记录在案的决策具体的评审维度包括意图文档中的需求与决策能向前追溯到故事故事也能回溯到已记录的意图双向检查孤儿epic 交付用户价值且没有前置依赖故事彼此独立可完成故事依赖的架构与 UX 决策有记录而非假设产物之间的冲突如 spec 与 epic 意见不一被显式暴露而非默默解决。判定与处理PASS—— 一句话给出结论若是完整 sprint-planning 意图继续进入生成追踪阶段。CONCERNS—— 简要列出每个缺口所在位置询问用户是继续还是先修复。FAIL—— 按严重程度排序给出发现为每个发现指名能修复它的技能相关规划技能或跨切变更用bmad-correct-course并提供将发现保存为{planning_artifacts}/implementation-readiness.md的选项然后停止。注意缺失某种文档类型只有在其内容被故事依赖时才构成发现——没有 UX 文档、也没有 UI 故事的纯后端项目完全没问题。触发方式说 check implementation readiness 只运行门禁Product Manager 与 Architect 菜单上的IR触发器效果相同。在 SKILL.md 的 On Activation 中readiness 是五种意图之一只加载references/readiness-gate.md、跑门禁、报告、停止。生成追踪sprint_plan.py generate的确定性部分门禁通过后同一个技能继续生成sprint-status.yaml。这里体现了 BMAD-METHOD 的职责切分哲学——SKILL.md 开篇就说你的判断力用在脚本无法处理的地方决定哪些文件是 epic、权衡就绪度、调和脚本标记的问题而解析 epic、派生 key、合并状态、写入sprint-status.yaml这些是确定性工作交给脚本。发现 epic 文件是你的判断先生成追踪时epic 文件通常是epics.md、epic-*.md或是{planning_artifacts}下的分片epics/文件夹——但依然以内容为准。如果整份文档和分片版本同时存在询问用户哪份是当前的而不是猜。generate 命令与参数uv run {skill-root}/scripts/sprint_plan.py generate \ --epic-file path [--epic-file path ...] \ --status-file {implementation_artifacts}/sprint-status.yaml \ --stories-dir {implementation_artifacts} \ --project {project_name} --date {date}可追加的参数来自 sprint_plan.py 的build_parser()第 710–737 行参数作用--project-key覆盖/设置project_key字段默认NOKEY--tracking-system覆盖/设置追踪系统标识默认file-system--story-location覆盖/设置故事文件位置默认取--stories-dir--dry-run只报告不同步情况不写入任何文件--fresh无视既有状态做一次干净重建修复路径使用--set KEYSTATUS应用用户确认的显式状态是唯一允许降级的路径{date}必须是MM-DD-YYYY HH:MM格式——这是过期检查staleness check解析的格式脚本中DATE_FORMAT %m-%d-%Y %H:%M同时接受%Y-%m-%d %H:%M与%Y-%m-%d两种手写漂移格式。脚本到底做了什么源码级从 sprint_plan.py 的cmd_generate第 372–468 行可以看到完整的确定性链条解析parse_epics()第 170–209 行用两条正则识别标题——EPIC_RE## Epic 1:形态与STORY_RE### Story 1.1:形态支持2.6a这类拆分故事编号代码围栏/~~~内的内容被跳过长得像 Epic/Story 但解析失败的标题会进入warnings供 LLM 处理。key 派生故事 key 形如1-1-user-authenticationepic序号-故事序号-slug。_slug()第 131–140 行是Unicode 感知的非拉丁标题会保留自身字符而不是塌缩成同一个占位符纯标点/emoji 标题则退化为 8 位内容哈希保证 key 确定性且互不重复。合并绝不降级_merge_status()第 240–252 行比较计算值与既有值按状态等级取更高者——backlog(0) ready-for-dev(1) in-progress(2) review(3) done(4)故事epic 为backlog(0) in-progress(1) done(2)retro 为optional(0) done(1)第 57–60 行。legacy 归一化v6 时代的drafted/contexted在每次读取时被映射为现代含义drafted→ready-for-dev、contexted→in-progress第 66 行报告但永不重置——所以旧文件既不会被判非法也不会丢失进度。故事文件检测--stories-dir下存在{key}.md的故事其状态会被托底到ready-for-dev第 278–279 行并记入报告upgraded_from_disk。安全写入原子写临时文件 fsyncos.replace保留原文件权限位写后回读校验development_status与关键字段校验失败则原子恢复原文件字节第 325–350、443–467 行。只输出 JSON无论成败stdout 只输出 JSON——连 argparse 错误都是 JSONJsonArgumentParser.error()第 116–128 行保证机器可消费。读 JSON 报告并行动判断力重新登场报告的in_sync、new_entries、dropped_orphans、illegal、legacy_mapped、upgraded_from_disk字段回答了追踪是否同步warnings中出现未解析的 Epic/Story 类标题 → 展示给用户一起修正标题后重跑dropped_orphans是旧文件中与现有 epics 匹配不上的条目通常是改名每条都携带旧状态 → 与用户对账后用--set 新key旧状态重跑移植若 epic 格式彻底超出正则能力 → 退回到对照 sprint-status-template.yaml 手工构建文件并明确告知确定性路径不适用。重新生成是安全的已完成的工作保持完成、action items 与手写注释原样穿过、--dry-run只报告漂移不写入。这也是 epic 变更后随时刷新追踪的方式。状态词汇表sprint-status.yaml 的完整契约sprint-status-template.yaml 定义了完整词汇脚本内嵌的HEADER_COMMENTsprint_plan.py 第 77–108 行与之逐字节一致且测试套件断言两者永不漂移Epic 状态backlog未开始、in-progress进行中、done全部故事完成Story 状态backlog只存在于 epic 文件、ready-for-dev故事文件已创建、in-progress开发中、review实现完成待评审、done完成Retrospective 状态optional可选完成、done已完成Action Item 状态open已承诺未处理、in-progress处理中、done完成。工作流要点也写在模板里epic 在其首个故事开始时自动转in-progress由 build 的 sprint 同步完成开发者通常在上一故事done之后创建下一故事以吸收经验开发把故事移入review后运行 code review建议用全新上下文、不同 LLM。时间戳统一用MM-DD-YYYY HH:MM。测试夹具 test_sprint_plan.py 中的EPICS_FIXTURE直观展示了输入 epic 文件的规范格式。查看状态show sprint status说 show sprint status或 where are we会跳过门禁直接看现状。命令uv run {skill-root}/scripts/sprint_plan.py status \ --status-file {implementation_artifacts}/sprint-status.yaml --date {date}--stale-days可调过期阈值默认 7 天STALE_DAYS_DEFAULT 7。脚本计算出见cmd_statussprint_plan.py 第 482–618 行各状态计数故事/epic/retro 分开统计legacy 值透明映射并在legacy_mapped中报告风险标志文件过期stale、孤儿故事有故事 key 但无对应 epic 条目、进行中的 epic 却没有故事、等待评审的故事提示运行bmad-code-review、未识别 key来自回顾的未处理 action itemsopen与in-progress一条推荐的下一步动作及其故事 key。下一步推荐的固定优先级推荐动作遵循固定优先级sprint_plan.py 第 559–591 行与原文档一致恢复进行中的工作bmad-build取第一个in-progress故事评审等待中的内容bmad-code-review取第一个review故事开始下一个就绪故事bmad-build取第一个ready-for-dev开始第一个 backlog 故事bmad-build取第一个backlog运行未完成的回顾bmad-retrospective当故事全部完成而epic-N-retrospective仍为optional全部完成无推荐。刻意不提供时间估算——只有状态、风险与下一步。渲染时若脚本报错YAML 损坏、手工改坏结构等不要停在错误上自己读sprint-status.yaml用最佳判断给出同样的摘要说明确定性路径失败的原因并引导走修复流程。修复追踪文件validate 与 fixvalidate只检查不改动说 validate sprint status 检查文件格式而不改动它uv run {skill-root}/scripts/sprint_plan.py validate \ --status-file {implementation_artifacts}/sprint-status.yaml不写文件无论是否合法都以 0 退出详见 references/validate.md。校验内容文件存在性、YAML 可解析性、顶层是否为映射、必需 keygenerated/last_updated/project/development_status、时间戳格式、key 语法epic-N、N-M-slug、epic-N-retrospective、状态是否属于该类型的合法词汇、action_items是否为结构合法的列表见cmd_validatesprint_plan.py 第 621–707 行。若legacy_mapped非空说明文件仍在使用 v6 状态名任何重新生成都会把它们改写为现代词汇——无论哪种方式进度都被保留。fix先推断真相再让用户确认最后写干净说 fix sprint status 处理文件损坏或与现实漂移的情况。核心纪律是推断决定状态应该是什么用户确认脚本写入未经确认绝不写入references/fix-sprint-status.md。六步流程评估损坏范围跑validate并共享结果若 epic 文件本身缺失或不可解析直接说明——在规划产物存在之前没有可重建的对象。并行推断真实状态派出多个子代理并行收集证据各自返回带证据的keystatus提议——epic 文件权威工作分解、故事文件磁盘上有哪些、内容透露的进度、git 历史与代码引用故事 key 的提交、以及当前文件本身抢救一切可信内容尤其action_items。汇合成一张提议状态表key → 提议状态 → 证据 → 不确定项。证据冲突或单薄时倾向更低的状态并标记——虚假的 done 比虚假的 in-progress 代价更高。与用户确认展示表格高亮所有与当前文件不同的条目尤其是降级和低置信度判断Headless 模式不确认直接以blocked状态停住。写干净文件一条命令基于已确认的表格uv run {skill-root}/scripts/sprint_plan.py generate \ --epic-file path [...] \ --status-file {implementation_artifacts}/sprint-status.yaml \ --stories-dir {implementation_artifacts} \ --project {project_name} --date {date} \ --fresh --set keystatus [--set keystatus ...]--fresh干净重建文档规范词汇、标准头部但保留action_items--set应用已确认状态且是唯一允许降级的路径——只有与 fresh 默认值不同的已确认条目才需要--set。 6.验证再跑validate期望valid: true并给出状态视图摘要让用户看到修复后的样子。修复是唯一能把故事标记为比原来更不完整的路径因为它反映的是经确认的现实。兼容旧名称旧名称仍然可用bmad-check-implementation-readiness与bmad-sprint-status都会转发到这里。任何_bmad/custom/bmad-sprint-status.toml覆盖项需迁移到bmad-sprint-planning.toml。纠正方向Correct Course变化大到单故事装不下时运行bmad-correct-course的场景需求被证明是错的、架构决策必须改变、或依赖发生了变化。它会读取 PRD、epics、架构与 UX 文档评估影响产出一份sprint 变更提案——什么变、什么不变、按什么顺序变。批准后它更新sprint-status.yaml并把文档编辑移交出去应用这些编辑后再创建新增或变更的故事。bmad-correct-course/SKILL.md 的流程细节提案文档默认写到{planning_artifacts}/sprint-change-proposal-{date}.md包含五节——问题摘要、影响分析epic/故事/产物冲突/技术影响、推荐路径直接调整 / 潜在回滚 / MVP 复审、详细变更提案每个都带 old → new 与理由、实现移交。变更按范围分三类路由Minor开发者直接实现、Moderate需要 backlog 重组PO/DEV 协作、Major需要 PM/架构师参与的根本性重规划。PRD 与 epics 是必需输入缺一则 HALT交互模式支持 Incremental逐条审批与 Batch一次性审阅两种模式。已完成的工作保持已完成——correct course 不会把 done 的故事打回。对于大规模重构更推荐对受影响的 epic 重新运行 Story Breakdown 或bmad-sprint-planning。接下来做什么用bmad-build逐故事实现当决策稳定后改用bmad-build-auto进入自主开发循环实现过程中build 会通过 sprint 同步把故事状态写回sprint-status.yamlcode review 把故事推进到review见模板 WORKFLOW NOTES而 bmad-retrospective 使用与sprint_plan.py相同的 key 语法读写同一文件、把 action items 追加进action_items段——这正是状态视图能持续浮现来自回顾的未处理项的原因当 epic 的故事全部完成用 Finish an Epic 收尾关闭。整个闭环bmad-create-epics-and-stories产出 epic →bmad-sprint-planning门禁与追踪 →bmad-build推进 →bmad-retrospective沉淀 →bmad-correct-course纠偏形成了一个可审计、可恢复、状态永不倒退的交付追踪体系判断力始终留给人与 LLM而解析、合并、校验这些确定性苦活全部由 sprint_plan.py 以原子写入、JSON 输出、绝不降级的方式可靠完成。【免费下载链接】BMAD-METHODBreakthrough Method for Agile Ai Driven Development项目地址: https://gitcode.com/gh_mirrors/bm/BMAD-METHOD创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/9/19 2:29:52 · 阅读 1.2k BMAD-METHOD 实战：把计划拆成故事并持续追踪（Story Breakdown + Sprint Planning 完整工作流）
BMAD-METHOD 实战把计划拆成故事并持续追踪Story Breakdown Sprint Planning 完整工作流【免费下载链接】BMAD-METHODBreakthrough Method for Agile Ai Driven Development项目地址: https://gitcode.com/gh_mirrors/bm/BMAD-METHOD导读本指南讲解 BMAD-METHOD 中计划落地的核心环节如何把一份已完成的规划spec 或 PRD拆解为可在一个会话内实现的故事单元并用sprint-status.yaml追踪它们的生命周期。读完本文你将掌握两条路径的完整流程——spec 驱动的 Story Breakdown 与 PRD 驱动的bmad-create-epics-and-storiesbmad-sprint-planning以及就绪门禁readiness gate、状态生成、状态查看、追踪文件修复和方向纠正correct course五大操作的具体命令与判定逻辑所有结论均有仓库源码与测试佐证。两条路径先想清楚拆什么BMAD-METHOD 把把计划变成故事分成两种形态取决于你的计划是什么。原文 break-work-into-stories-and-track-it.md 用一张表给出了决策入口计划形态要做的事追踪产物由SPEC.md支撑的单个 epic请bmad-spec做 Story Breakdown位于SPEC.md旁边的有序stories.yaml带 PRD以及 UX 或架构的项目先运行bmad-create-epics-and-stories再运行bmad-sprint-planningepic 文件 sprint-status.yaml路径一spec 支撑的 epic ——stories.yaml即全部追踪在 spec 路径下stories.yaml是整个追踪文件不涉及 sprint-status 文件。bmad-spec 的 Story Breakdown 一节明确输出物是与SPEC.md同级的stories.yaml通过固定文件名发现与SPEC.md、.memlog.md同一约定不列入companions:也不会被前端配置引用——它是派发故事的输入而非下游消费的契约。Story Breakdown 是纯交互式操作headless 运行永远不会执行它它逐个能力capability与约束constraint和用户对话按可独立评审的切片提议故事并为每个故事收集三个关键字段spec_checkpoint、done_checkpoint以及可选的invoke_dev_with派发备注——这正是开发者可照着实现的来源。字段定义、合法性与校验规则见 assets/stories-schema.md。构建流程会把每个故事的实现记录写到 spec 文件夹下而 Finish an Epic 把stories.yaml当作清单来读取。路径二PRD 项目 —— epic 文件 sprint-status对完整项目bmad-create-epics-and-stories以产品合伙人身份与用户协作把 PRD 的需求和架构决策转化为按用户价值组织的 epic 文件每个故事都带有开发者可以对照实现的验收标准。该技能采用步骤文件架构step-file architecture按 step-01-validate-prerequisites.md → step-02-design-epics.md → step-03-create-stories.md → step-04-final-validation.md 顺序执行每次只加载一个步骤文件不允许跳步最终文档通过 frontmatter 的stepsCompleted数组记录进度见 SKILL.md 的 WORKFLOW ARCHITECTURE 一节。本文之后的所有内容都围绕路径二展开。就绪门禁Readiness Gate用老手读交接单的眼光审计划bmad-sprint-planning运行在规划与实现的分界线上。在任何追踪文件存在之前它先像一位持怀疑态度的资深开发者在读交接单那样审视计划。关键点在于见 references/readiness-gate.md按内容盘点不按文件名它扫描{planning_artifacts}与{project_knowledge}识别 brief、PRFAQ、PRD、spec、UX 产出、架构、epics 等文档——靠读内容判断是什么而不是靠文件名模式匹配因为不同项目的产物组合与命名各不相同。只问一个问题开发者能否实现这些 epic而无需凭空发明任何没有记录在案的决策具体的评审维度包括意图文档中的需求与决策能向前追溯到故事故事也能回溯到已记录的意图双向检查孤儿epic 交付用户价值且没有前置依赖故事彼此独立可完成故事依赖的架构与 UX 决策有记录而非假设产物之间的冲突如 spec 与 epic 意见不一被显式暴露而非默默解决。判定与处理PASS—— 一句话给出结论若是完整 sprint-planning 意图继续进入生成追踪阶段。CONCERNS—— 简要列出每个缺口所在位置询问用户是继续还是先修复。FAIL—— 按严重程度排序给出发现为每个发现指名能修复它的技能相关规划技能或跨切变更用bmad-correct-course并提供将发现保存为{planning_artifacts}/implementation-readiness.md的选项然后停止。注意缺失某种文档类型只有在其内容被故事依赖时才构成发现——没有 UX 文档、也没有 UI 故事的纯后端项目完全没问题。触发方式说 check implementation readiness 只运行门禁Product Manager 与 Architect 菜单上的IR触发器效果相同。在 SKILL.md 的 On Activation 中readiness 是五种意图之一只加载references/readiness-gate.md、跑门禁、报告、停止。生成追踪sprint_plan.py generate的确定性部分门禁通过后同一个技能继续生成sprint-status.yaml。这里体现了 BMAD-METHOD 的职责切分哲学——SKILL.md 开篇就说你的判断力用在脚本无法处理的地方决定哪些文件是 epic、权衡就绪度、调和脚本标记的问题而解析 epic、派生 key、合并状态、写入sprint-status.yaml这些是确定性工作交给脚本。发现 epic 文件是你的判断先生成追踪时epic 文件通常是epics.md、epic-*.md或是{planning_artifacts}下的分片epics/文件夹——但依然以内容为准。如果整份文档和分片版本同时存在询问用户哪份是当前的而不是猜。generate 命令与参数uv run {skill-root}/scripts/sprint_plan.py generate \ --epic-file path [--epic-file path ...] \ --status-file {implementation_artifacts}/sprint-status.yaml \ --stories-dir {implementation_artifacts} \ --project {project_name} --date {date}可追加的参数来自 sprint_plan.py 的build_parser()第 710–737 行参数作用--project-key覆盖/设置project_key字段默认NOKEY--tracking-system覆盖/设置追踪系统标识默认file-system--story-location覆盖/设置故事文件位置默认取--stories-dir--dry-run只报告不同步情况不写入任何文件--fresh无视既有状态做一次干净重建修复路径使用--set KEYSTATUS应用用户确认的显式状态是唯一允许降级的路径{date}必须是MM-DD-YYYY HH:MM格式——这是过期检查staleness check解析的格式脚本中DATE_FORMAT %m-%d-%Y %H:%M同时接受%Y-%m-%d %H:%M与%Y-%m-%d两种手写漂移格式。脚本到底做了什么源码级从 sprint_plan.py 的cmd_generate第 372–468 行可以看到完整的确定性链条解析parse_epics()第 170–209 行用两条正则识别标题——EPIC_RE## Epic 1:形态与STORY_RE### Story 1.1:形态支持2.6a这类拆分故事编号代码围栏/~~~内的内容被跳过长得像 Epic/Story 但解析失败的标题会进入warnings供 LLM 处理。key 派生故事 key 形如1-1-user-authenticationepic序号-故事序号-slug。_slug()第 131–140 行是Unicode 感知的非拉丁标题会保留自身字符而不是塌缩成同一个占位符纯标点/emoji 标题则退化为 8 位内容哈希保证 key 确定性且互不重复。合并绝不降级_merge_status()第 240–252 行比较计算值与既有值按状态等级取更高者——backlog(0) ready-for-dev(1) in-progress(2) review(3) done(4)故事epic 为backlog(0) in-progress(1) done(2)retro 为optional(0) done(1)第 57–60 行。legacy 归一化v6 时代的drafted/contexted在每次读取时被映射为现代含义drafted→ready-for-dev、contexted→in-progress第 66 行报告但永不重置——所以旧文件既不会被判非法也不会丢失进度。故事文件检测--stories-dir下存在{key}.md的故事其状态会被托底到ready-for-dev第 278–279 行并记入报告upgraded_from_disk。安全写入原子写临时文件 fsyncos.replace保留原文件权限位写后回读校验development_status与关键字段校验失败则原子恢复原文件字节第 325–350、443–467 行。只输出 JSON无论成败stdout 只输出 JSON——连 argparse 错误都是 JSONJsonArgumentParser.error()第 116–128 行保证机器可消费。读 JSON 报告并行动判断力重新登场报告的in_sync、new_entries、dropped_orphans、illegal、legacy_mapped、upgraded_from_disk字段回答了追踪是否同步warnings中出现未解析的 Epic/Story 类标题 → 展示给用户一起修正标题后重跑dropped_orphans是旧文件中与现有 epics 匹配不上的条目通常是改名每条都携带旧状态 → 与用户对账后用--set 新key旧状态重跑移植若 epic 格式彻底超出正则能力 → 退回到对照 sprint-status-template.yaml 手工构建文件并明确告知确定性路径不适用。重新生成是安全的已完成的工作保持完成、action items 与手写注释原样穿过、--dry-run只报告漂移不写入。这也是 epic 变更后随时刷新追踪的方式。状态词汇表sprint-status.yaml 的完整契约sprint-status-template.yaml 定义了完整词汇脚本内嵌的HEADER_COMMENTsprint_plan.py 第 77–108 行与之逐字节一致且测试套件断言两者永不漂移Epic 状态backlog未开始、in-progress进行中、done全部故事完成Story 状态backlog只存在于 epic 文件、ready-for-dev故事文件已创建、in-progress开发中、review实现完成待评审、done完成Retrospective 状态optional可选完成、done已完成Action Item 状态open已承诺未处理、in-progress处理中、done完成。工作流要点也写在模板里epic 在其首个故事开始时自动转in-progress由 build 的 sprint 同步完成开发者通常在上一故事done之后创建下一故事以吸收经验开发把故事移入review后运行 code review建议用全新上下文、不同 LLM。时间戳统一用MM-DD-YYYY HH:MM。测试夹具 test_sprint_plan.py 中的EPICS_FIXTURE直观展示了输入 epic 文件的规范格式。查看状态show sprint status说 show sprint status或 where are we会跳过门禁直接看现状。命令uv run {skill-root}/scripts/sprint_plan.py status \ --status-file {implementation_artifacts}/sprint-status.yaml --date {date}--stale-days可调过期阈值默认 7 天STALE_DAYS_DEFAULT 7。脚本计算出见cmd_statussprint_plan.py 第 482–618 行各状态计数故事/epic/retro 分开统计legacy 值透明映射并在legacy_mapped中报告风险标志文件过期stale、孤儿故事有故事 key 但无对应 epic 条目、进行中的 epic 却没有故事、等待评审的故事提示运行bmad-code-review、未识别 key来自回顾的未处理 action itemsopen与in-progress一条推荐的下一步动作及其故事 key。下一步推荐的固定优先级推荐动作遵循固定优先级sprint_plan.py 第 559–591 行与原文档一致恢复进行中的工作bmad-build取第一个in-progress故事评审等待中的内容bmad-code-review取第一个review故事开始下一个就绪故事bmad-build取第一个ready-for-dev开始第一个 backlog 故事bmad-build取第一个backlog运行未完成的回顾bmad-retrospective当故事全部完成而epic-N-retrospective仍为optional全部完成无推荐。刻意不提供时间估算——只有状态、风险与下一步。渲染时若脚本报错YAML 损坏、手工改坏结构等不要停在错误上自己读sprint-status.yaml用最佳判断给出同样的摘要说明确定性路径失败的原因并引导走修复流程。修复追踪文件validate 与 fixvalidate只检查不改动说 validate sprint status 检查文件格式而不改动它uv run {skill-root}/scripts/sprint_plan.py validate \ --status-file {implementation_artifacts}/sprint-status.yaml不写文件无论是否合法都以 0 退出详见 references/validate.md。校验内容文件存在性、YAML 可解析性、顶层是否为映射、必需 keygenerated/last_updated/project/development_status、时间戳格式、key 语法epic-N、N-M-slug、epic-N-retrospective、状态是否属于该类型的合法词汇、action_items是否为结构合法的列表见cmd_validatesprint_plan.py 第 621–707 行。若legacy_mapped非空说明文件仍在使用 v6 状态名任何重新生成都会把它们改写为现代词汇——无论哪种方式进度都被保留。fix先推断真相再让用户确认最后写干净说 fix sprint status 处理文件损坏或与现实漂移的情况。核心纪律是推断决定状态应该是什么用户确认脚本写入未经确认绝不写入references/fix-sprint-status.md。六步流程评估损坏范围跑validate并共享结果若 epic 文件本身缺失或不可解析直接说明——在规划产物存在之前没有可重建的对象。并行推断真实状态派出多个子代理并行收集证据各自返回带证据的keystatus提议——epic 文件权威工作分解、故事文件磁盘上有哪些、内容透露的进度、git 历史与代码引用故事 key 的提交、以及当前文件本身抢救一切可信内容尤其action_items。汇合成一张提议状态表key → 提议状态 → 证据 → 不确定项。证据冲突或单薄时倾向更低的状态并标记——虚假的 done 比虚假的 in-progress 代价更高。与用户确认展示表格高亮所有与当前文件不同的条目尤其是降级和低置信度判断Headless 模式不确认直接以blocked状态停住。写干净文件一条命令基于已确认的表格uv run {skill-root}/scripts/sprint_plan.py generate \ --epic-file path [...] \ --status-file {implementation_artifacts}/sprint-status.yaml \ --stories-dir {implementation_artifacts} \ --project {project_name} --date {date} \ --fresh --set keystatus [--set keystatus ...]--fresh干净重建文档规范词汇、标准头部但保留action_items--set应用已确认状态且是唯一允许降级的路径——只有与 fresh 默认值不同的已确认条目才需要--set。 6.验证再跑validate期望valid: true并给出状态视图摘要让用户看到修复后的样子。修复是唯一能把故事标记为比原来更不完整的路径因为它反映的是经确认的现实。兼容旧名称旧名称仍然可用bmad-check-implementation-readiness与bmad-sprint-status都会转发到这里。任何_bmad/custom/bmad-sprint-status.toml覆盖项需迁移到bmad-sprint-planning.toml。纠正方向Correct Course变化大到单故事装不下时运行bmad-correct-course的场景需求被证明是错的、架构决策必须改变、或依赖发生了变化。它会读取 PRD、epics、架构与 UX 文档评估影响产出一份sprint 变更提案——什么变、什么不变、按什么顺序变。批准后它更新sprint-status.yaml并把文档编辑移交出去应用这些编辑后再创建新增或变更的故事。bmad-correct-course/SKILL.md 的流程细节提案文档默认写到{planning_artifacts}/sprint-change-proposal-{date}.md包含五节——问题摘要、影响分析epic/故事/产物冲突/技术影响、推荐路径直接调整 / 潜在回滚 / MVP 复审、详细变更提案每个都带 old → new 与理由、实现移交。变更按范围分三类路由Minor开发者直接实现、Moderate需要 backlog 重组PO/DEV 协作、Major需要 PM/架构师参与的根本性重规划。PRD 与 epics 是必需输入缺一则 HALT交互模式支持 Incremental逐条审批与 Batch一次性审阅两种模式。已完成的工作保持已完成——correct course 不会把 done 的故事打回。对于大规模重构更推荐对受影响的 epic 重新运行 Story Breakdown 或bmad-sprint-planning。接下来做什么用bmad-build逐故事实现当决策稳定后改用bmad-build-auto进入自主开发循环实现过程中build 会通过 sprint 同步把故事状态写回sprint-status.yamlcode review 把故事推进到review见模板 WORKFLOW NOTES而 bmad-retrospective 使用与sprint_plan.py相同的 key 语法读写同一文件、把 action items 追加进action_items段——这正是状态视图能持续浮现来自回顾的未处理项的原因当 epic 的故事全部完成用 Finish an Epic 收尾关闭。整个闭环bmad-create-epics-and-stories产出 epic →bmad-sprint-planning门禁与追踪 →bmad-build推进 →bmad-retrospective沉淀 →bmad-correct-course纠偏形成了一个可审计、可恢复、状态永不倒退的交付追踪体系判断力始终留给人与 LLM而解析、合并、校验这些确定性苦活全部由 sprint_plan.py 以原子写入、JSON 输出、绝不降级的方式可靠完成。【免费下载链接】BMAD-METHODBreakthrough Method for Agile Ai Driven Development项目地址: https://gitcode.com/gh_mirrors/bm/BMAD-METHOD创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考