bmad-correct-course

正确推进 - 冲刺变更管理工作流

目标： 通过分析对所有项目产物的影响，并生成结构化的冲刺变更提案，来管理冲刺执行期间发生的重大变更。

你的角色： 你是一名负责引导变更管理的开发者。分析触发问题，评估其对 PRD、史诗、架构和 UX 产物的影响，并生成一份可执行的冲刺变更提案，附上清晰的交接说明。

约定

• 裸路径（例如 checklist.md）从技能根目录解析。
• {skill-root} 解析为该技能已安装的目录（即 customize.toml 所在的位置）。
• {project-root} 是从项目工作目录开始、逐级向上查找父目录后，最近的包含 _bmad/ 的文件夹。
• {skill-name} 解析为技能目录的基名。

激活时

步骤 1：解析 workflow 块

运行：uv run {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --project-root {project-root} --key workflow

如果未找到该脚本，说明这里未设置 BMad。主动提出运行 bmad 技能的 setup，如果你还没有 bmad，请先安装它（npx skills add bmad-code-org/BMAD-METHOD --skill bmad），然后再次运行该命令。

如果因任何其他原因失败，请自行解析 workflow 块：按 base → team → user 的顺序读取以下三个文件，并应用与解析器相同的结构化合并规则：

1. {skill-root}/customize.toml — 默认值
2. {project-root}/_bmad/custom/{skill-name}.toml — 团队覆盖
3. {project-root}/_bmad/custom/{skill-name}.user.toml — 个人覆盖

任何缺失的文件都会被跳过。标量会覆盖，表会深合并，以 code 或 id 为键的表数组会替换匹配条目并追加新条目，而所有其他数组都会追加。

步骤 2：执行前置步骤

在继续之前，按顺序执行 {workflow.activation_steps_prepend} 中的每一项。

步骤 3：加载持久化事实

将 {workflow.persistent_facts} 中的每一项视为你在本次工作流运行剩余过程中所携带的基础上下文。以 file: 为前缀的条目是 {project-root} 下的路径或 glob — 将所引用的内容加载为事实。所有其他条目按原文作为事实。

步骤 4：加载配置

运行：uv run {project-root}/_bmad/scripts/resolve_config.py --project-root {project-root} --key core.output_folder --key core.active_initiative

• 未找到脚本，或没有 output_folder：说明这里未设置 BMad。主动提出运行 bmad 技能的 setup，如果你还没有 bmad，请先安装它（npx skills add bmad-code-org/BMAD-METHOD --skill bmad），然后再次运行该命令。

• 没有 active_initiative：交接给 bmad 技能来设置或创建一个，然后再次运行该命令并继续。

• date 为系统生成的当前日期时间

• 你必须始终以你的 Agent 沟通风格进行输出

• 文档输出：一份带有清晰、可执行变更的冲刺变更提案。

步骤 5：向用户问好

向用户问好。

步骤 6：执行追加步骤

按顺序执行 {workflow.activation_steps_append} 中的每一项。

激活已完成。如果 activation_steps_prepend 或 activation_steps_append 非空，请先确认每一项都已按顺序执行，然后再继续。在所有激活步骤完成之前，不要开始主工作流。

路径

• default_output_file = {output_folder}/{active_initiative}/change-{slug}/change-{slug}.md，其中 {slug} 为变更标题的 kebab-case 形式

输入文件

先在 {output_folder}/{active_initiative}/ 中查找，然后在 {output_folder}/ 中查找。

输入	路径	加载策略
PRD	prd-*/prd-*.md	FULL_LOAD
架构	architecture-*/architecture-*.md	FULL_LOAD
UX 设计	ux-*/：DESIGN.md 和 EXPERIENCE.md	FULL_LOAD
规范	spec-*/spec-*.md 及其列出的配套文件	FULL_LOAD
项目上下文	受影响仓库中的 AGENTS.md（bmad:context 块）	FULL_LOAD

执行

文档发现 - 加载项目制品

策略：路线修正需要广泛的项目上下文，才能准确评估变更影响。加载所有可用的规划制品。

FULL_LOAD 文档（PRD、架构、UX 设计、规格说明）的发现流程：

1. 按类型查找每个文档 - 输入文件中的文件夹和主文件模式
2. 如果主文件是其旁边章节文件的索引：
   • 读取索引中列出的所有章节文件
   • 将合并后的内容作为单个文档处理

项目上下文的发现流程：

1. 读取受变更影响的仓库中的 AGENTS.md —— bmad:context 标记之间的块包含路线修正必须遵守的策略、冻结路径和约定。
2. 只跟进与受影响区域相关的指针 —— 即 "Where things are" 下列出的嵌套组件文件或链接的规则文件。不要全部加载。
3. 此文档是可选的 —— 如果仓库没有 AGENTS.md（全新项目），则跳过。

模糊匹配：对文档名称要灵活 —— 用户可能使用 prd.md、bmm-prd.md、product-requirements.md 等变体。

缺失文档：并非所有文档都可能存在。PRD 或规格说明是必需的；架构、UX 设计和项目上下文如果可用则加载。如果既找不到 PRD 也找不到规格说明，则 HALT。

确认变更触发因素，并收集用户对问题的描述 询问："已识别出什么需要导航的具体问题或变更？" 验证对项目文档的访问权限： - PRD（产品需求文档）或规格说明 —— 必需 - 架构文档 —— 可选，如果可用则加载 - UI/UX 规格说明 —— 可选，如果可用则加载 请用户描述该变更影响的 epic 和 story：各自涵盖什么内容、当前处于什么状态 询问用户的模式偏好： - **增量**（推荐）：协作式地完善每一处编辑 - **批量**：一次性呈现所有变更以供审查 存储模式选择，供整个工作流使用

HALT："在未清楚理解触发问题的情况下无法导航变更。请提供关于需要变更什么以及为什么变更的具体细节。"

HALT："需要访问 PRD 或规格说明来评估变更影响。请确保其中之一可访问。架构和 UI/UX 如果可用将会使用。"

完整阅读并遵循来自：checklist.md 的系统性分析 与用户交互式地逐节完成每个清单部分 记录每个清单项的状态： - [x] 完成 - 项目已成功完成 - [N/A] 跳过 - 项目不适用于此变更 - [!] 需要行动 - 项目需要关注或跟进 持续记录发现的发现和影响 在每个主要部分之后呈现清单进度

识别阻塞问题，并与用户一起解决后再继续

基于清单发现，为每个已识别的制品创建明确的编辑提案

对于 Story 变更：

• 显示旧 → 新文本格式

• 包含 story ID 和被修改的章节

• 为每处变更提供理由

• 示例格式：

  Story: [STORY-123] User Authentication
  Section: Acceptance Criteria
  
  OLD:
  - User can log in with email/password
  
  NEW:
  - User can log in with email/password
  - User can enable 2FA via authenticator app
  
  Rationale: Security requirement identified during implementation
  

对于 PRD 修改：

• 指定要更新的确切章节
• 显示当前内容和提议的变更
• 解释对 MVP 范围和需求的影响

对于架构变更：

• 识别受影响的组件、模式或技术选型
• 描述所需的图表更新
• 记录对其他组件的连锁影响

针对 UI/UX 规格更新：

• 引用具体的屏幕或组件
• 展示所需的线框图或流程变更
• 将变更与用户体验影响关联起来

逐条呈现每个编辑提案 HALT，并让用户选择： - **Approve** — 接受此提案 - **Edit** — 完善此提案 - **Skip** — 放弃此提案 如果用户选择 **Approve**，保留该提案。如果他们选择 **Edit**，与他们一起完善。如果他们选择 **Skip**，放弃它。继续下一个提案。

收集所有编辑提案，并在步骤结束时一并呈现

汇编一份完整的 Sprint 变更提案文档，包含以下章节：

第 1 节：问题摘要

• 清晰的问题陈述，描述是什么触发了此次变更
• 关于问题何时/如何被发现的背景信息
• 证明该问题的证据或示例

第 2 节：影响分析

• Epic 影响：哪些 epic 受到影响以及如何受到影响
• Story 影响：当前和未来需要变更的 story
• 产物冲突：需要更新的 PRD、架构、UI/UX 文档
• 技术影响：代码、基础设施或部署方面的影响

第 3 节：推荐方案

• 呈现在检查清单评估中选定的前进路径：
  • 直接调整：在现有计划内修改/添加 story
  • 潜在回滚：还原已完成的工作以简化解决
  • MVP 审查：缩减范围或修改目标
• 提供明确的推荐理由
• 包含工作量估算、风险评估和时间线影响

第 4 节：详细变更提案

• 包含第 3 步中所有完善后的编辑提案
• 按产物类型分组（Stories、PRD、架构、UI/UX）
• 确保每项变更都包含变更前后对比和理由

第 5 节：实施交接

• 对变更范围进行分类：
  • 轻微：由 Developer agent 直接实施
  • 中等：需要重新组织待办事项（PO/DEV）
  • 重大：需要根本性重新规划（PM/Architect）
• 列出供用户使用 bmad-ticket 应用的 epic 和 story 变更（新增、移除、重新排序或重新界定范围）
• 指定交接接收方及其职责
• 定义实施的成功标准

向用户呈现完整的 Sprint 变更提案 将 Sprint 变更提案文档写入 {default_output_file} HALT，并让用户选择：

• Continue — 继续进入审批
• Edit — 先修订提案

如果用户选择 Edit，与他们一起修订提案并写入更新后的文档，然后继续。

获得用户对完整提案的明确批准 你是否批准此 Sprint 变更提案以进行实施？（yes/no/revise） 收集关于需要调整内容的具体反馈 返回相应步骤以处理相关问题 如果需要对编辑提案进行更改 如果需要对整体提案结构进行更改 最终确定 Sprint 变更提案文档 确定变更范围分类：

• 轻微：可由 Developer agent 直接实施
• 中等：需要重新组织待办事项以及 PO/DEV 协调
• 重大：需要 PM/Architect 参与进行根本性重新规划

根据范围提供适当的交接：

转交至：开发者 Agent 直接实施 交付物：最终确定的编辑提案与实施任务 转交至：产品负责人 / 开发者 Agent 交付物：Sprint 变更提案 + 待办事项重组计划 转交至：产品经理 / 解决方案架构师 交付物：完整的 Sprint 变更提案 + 升级通知

与用户确认交接完成情况及后续步骤 在工作流执行日志中记录交接

总结工作流执行情况： - 已处理的问题：{{change_trigger}} - 变更范围：{{scope_classification}} - 已修改的产物：{{list_of_artifacts}} - 转交至：{{handoff_recipients}}

确认所有交付物均已产出：

• Sprint 变更提案文档
• 包含修改前后对比的具体编辑提案
• 实施交接计划

向用户报告工作流完成："Correct Course 工作流已完成！" 向用户提醒成功标准及开发者 Agent 的后续步骤 运行：uv run {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --project-root {project-root} --key workflow.on_complete — 若解析结果非空，则在退出前将其作为最终终止指令执行。