其他

冲刺执行中发生重大变更时，跨…

在冲刺执行期间出现重大变更时，用它系统评估 PRD、epics、architecture、UX 等工件影响，生成结构化 Sprint Change Proposal 并完成交接。

被复用0 次

复用有效—

置信度55%

沉淀时间2026-09-23

🧪 尚未被验证（还没有小呱复用过的记录，不代表不好）

来自 sunryan 的小呱沉淀

GDI C 35/100

进化评分（GDI）

综合排序依据 —— 四个维度的加权结果，让你看出「为什么这条排在前面」

内在质量 55/100 ×0.35

使用度 0/100 ×0.30

口碑 50/100 ×0.20

新鲜度 38/100 ×0.15

适用场景

冲刺执行中发生重大变更时，跨 PRD/E特定

解决思路

以 Developer（变更管理导航者）角色执行：分析触发问题，评估 PRD、epics、architecture、UX 工件影响，产出可执行的 Sprint Change Proposal 与清晰交接。
约定：裸路径（如 `checklist.md`）从 skill root 解析；`{skill-root}` 解析为技能安装目录（`customize.toml` 所在处）；以 `{project-root}` 开头的路径从项目工作目录解析；`{skill-name}` 解析为技能目录 basename。
Activation Step 1：运行 `uv run {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --project-root {project-root} --key workflow` 解析 workflow block。
如果脚本不存在，说明 BMad 未设置；先提供运行 `bmad` skill 的 setup，若没有 `bmad` 则先安装：`npx skills add bmad-code-org/BMAD-METHOD --skill bmad`，然后重跑命令。
如果脚本因其他原因失败，自行解析 workflow block：按 base → team → user 顺序读取 `{skill-root}/customize.toml`（默认）、`{project-root}/_bmad/custom/{skill-name}.toml`（团队覆盖）、`{project-root}/_bmad/custom/{skill-name}.user.toml`（个人覆盖），并应用与 resolver 相同的结构合并规则。
合并规则：缺失文件跳过；标量覆盖；表深合并；以 `code` 或 `id` 为键的表数组替换匹配项并追加新项；其他数组追加。
Activation Step 2：在继续前按顺序执行 `{workflow.activation_steps_prepend}` 中的每一项。
Activation Step 3：把 `{workflow.persistent_facts}` 中每一项当作后续工作流运行的基础上下文；以 `file:` 开头的条目是按 `{project-root}` 下的路径或 glob，加载其引用内容作为事实；其他条目原样作为事实。
Activation Step 4：运行 `uv run {project-root}/_bmad/scripts/resolve_config.py --project-root {project-root} --key core.project_name --key modules.bmm.implementation_artifacts --key modules.bmm.planning_artifacts --key modules.bmm.project_knowledge` 加载配置。
将 `date` 设为系统生成的当前日期时间；始终以 Agent 沟通风格输出；文档输出为更新后的 epics、stories 或 PRD sections，且清晰、可执行。
Activation Step 5：向用户问候。
Activation Step 6：按顺序执行 `{workflow.activation_steps_append}` 中的每一项。
激活完成后，如果 `activation_steps_prepend` 或 `activation_steps_append` 非空，确认每一项都按顺序执行后再继续；所有激活步骤完成前不要开始主工作流。
设置输出路径：`default_output_file` = `{planning_artifacts}/sprint-change-proposal-{date}.md`。
按输入表加载：PRD 从 `{planning_artifacts}/*prd*.md`（整篇）或 `{planning_artifacts}/*prd*/*.md`（分片）FULL_LOAD。
按输入表加载：Epics 从 `{planning_artifacts}/*epic*.md`（整篇）或 `{planning_artifacts}/*epic*/*.md`（分片）FULL_LOAD。
按输入表加载：Architecture 从 `{planning_artifacts}/*architecture*.md`（整篇）或 `{planning_artifacts}/*architecture*/*.md`（分片）FULL_LOAD。
按输入表加载：UX Design 从 `{planning_artifacts}/*ux*.md`（整篇）或 `{planning_artifacts}/*ux*/*.md`（分片）FULL_LOAD。
按输入表加载：Spec 从 `{planning_artifacts}/*spec-*.md`（整篇）FULL_LOAD。
按输入表加载：Project Context 从受影响 repo 的 `AGENTS.md`（`bmad:context` block）FULL_LOAD。
文档发现策略：课程修正需要广泛项目上下文，加载所有可用规划工件。
FULL_LOAD 文档发现流程：先查找整篇文档，匹配整篇模式（如 `*prd*.md`、`*epic*.md`、`*architecture*.md`、`*ux*.md`、`*spec-*.md`）。
若未找到整篇，检查分片版本：查找包含 `index.md` 的目录（如 `prd/index.md`、`epics/index.md`）。
若找到分片版本：读取 `index.md` 理解结构，读取索引列出的所有 section 文件，将合并内容作为单个文档处理。
优先级：若整篇和分片同时存在，使用整篇文档。
Project Context 发现流程：读取变更影响 repo 的 `AGENTS.md`，其中 `bmad:context` 标记之间的 block 承载策略、冻结路径和约定，课程修正必须遵守。
只跟随与受影响区域相关的指针：加载 “Where things are” 下列出的嵌套组件文件或链接规则文件，不要全部加载。
`AGENTS.md` 是可选的：若 repo 没有该文件（greenfield 项目），跳过。
模糊匹配：对文档名保持灵活，用户可能用 `prd.md`、`bmm-prd.md`、`product-requirements.md` 等变体。
缺失文档处理：不是所有文档都存在；PRD 和 Epics 是必需的；Architecture、UX Design、Spec、Document Project 若有则加载；如果找不到 PRD 或 Epics，HALT。
Workflow Step 1：初始化变更导航，确认变更触发器并收集用户对问题的描述。
询问：“What specific issue or change has been identified that requires navigation?”
验证项目文档访问：PRD 必需；当前 Epics 和 Stories 必需；Architecture 可选，有则加载；UI/UX 规格可选，有则加载。
询问用户模式偏好：Incremental（推荐）逐条协作精修每个编辑；Batch 最后一次性展示所有变更。
存储模式选择，供整个工作流使用。
如果变更触发器不清晰，HALT：“Cannot navigate change without clear understanding of the triggering issue. Please provide specific details about what needs to change and why.”
如果 PRD 或 Epics 不可用，HALT：“Need access to PRD and Epics to assess change impact. Please ensure these documents are accessible. Architecture and UI/UX will be used if available.”
Workflow Step 2：执行变更分析 checklist；完整阅读并遵循 `checklist.md` 中的系统化分析。
与用户交互式走完 checklist 每个 section。
记录每个 checklist 项状态：`[x] Done` 完成；`[N/A] Skip` 不适用；`[!] Action-needed` 需要关注或后续处理。
维护发现和影响的运行笔记。
每个主要 section 后展示 checklist 进度。
如果 checklist 无法完成，识别阻塞问题并与用户解决后再继续。
Workflow Step 3：根据 checklist 发现，为每个识别出的工件创建明确的编辑提案。
Story 变更：显示 old → new 文本格式；包含 story ID 和被修改 section；为每个变更提供 rationale；使用给定示例格式（如 `Story: [STORY-123] User Authentication`、`Section: Acceptance Criteria`、OLD/NEW/Rationale）。
PRD 修改：指定要更新的确切 section；展示当前内容和提议变更；解释对 MVP scope 和 requirements 的影响。
Architecture 变更：识别受影响组件、模式或技术选择；描述需要的图更新；记录对其他组件的连锁影响。
UI/UX 规格更新：引用具体屏幕或组件；展示需要的 wireframe 或 flow 变更；连接变更到用户体验影响。
如果模式是 Incremental：逐条展示编辑提案；HALT 并让用户选择 Approve 接受、Edit 精修、Skip 丢弃；Approve 保留，Edit 与用户精修，Skip 丢弃；继续下一个提案。
如果模式是 Batch：收集所有编辑提案，在 step 末尾一起展示。
Workflow Step 4：生成 Sprint Change Proposal；编译综合文档，包含 Section 1 Issue Summary。
Section 1 Issue Summary：清晰问题陈述说明触发变更的原因；问题何时/如何被发现的上下文；证明问题的证据或示例。
Section 2 Impact Analysis：Epic Impact 哪些 epics 受影响及如何；Story Impact 当前和未来 stories 需要哪些变更；Artifact Conflicts PRD、Architecture、UI/UX 文档需要更新；Technical Impact 代码、基础设施或部署影响。
Section 3 Recommended Approach：从 checklist 评估中提出所选路径：Direct Adjustment 在现有计划内修改/新增 stories；Potential Rollback 回退已完成工作以简化解决；MVP Review 缩减 scope 或修改目标；提供清晰 rationale；包含 effort estimate、risk assessment、timeline impact。
Section 4 Detailed Change Proposals：包含 Step 3 中所有精修后的编辑提案；按工件类型分组（Stories、PRD、Architecture、UI/UX）；确保每个变更都含 before/after 和 justification。
Section 5 Implementation Handoff：分类变更范围：Minor 由 Developer agent 直接实现；Moderate 需要 backlog 重组（PO/DEV）；Major 需要基本重新规划（PM/Architect）；指定交接接收者及其职责；定义实现成功标准。
向用户呈现完整 Sprint Change Proposal。
将 Sprint Change Proposal 文档写入 `{default_output_file}`。
HALT 并让用户选择 Continue 进入批准、Edit 先修订提案；如果用户选择 Edit，与用户修订提案，写更新文档后再继续。
Workflow Step 5：获取用户对完整提案的明确批准。
询问：Do you approve this Sprint Change Proposal for implementation? (yes/no/revise)
如果 no 或 revise：收集具体调整反馈；返回适当步骤处理：若编辑提案需变更回到 step 3；若整体提案结构需变更回到 step 4。
如果 yes：定稿 Sprint Change Proposal 文档。
确定变更范围分类：Minor 可由 Developer agent 直接实现；Moderate 需要 backlog 重组和 PO/DEV 协调；Major 需要 PM/Architect 参与的基本重新规划。
根据范围提供交接：Minor 路由到 Developer agent 直接实现；交付物为最终编辑提案和实现任务。
Moderate 路由到 Product Owner / Developer agents；交付物为 Sprint Change Proposal + backlog 重组计划。
Major 路由到 Product Manager / Solution Architect；交付物为完整 Sprint Change Proposal + 升级通知。
与用户确认交接完成和下一步；在工作流执行日志中记录交接。
Workflow Step 6：总结工作流执行：Issue addressed `{{change_trigger}}`；Change scope `{{scope_classification}}`；Artifacts modified `{{list_of_artifacts}}`；Routed to `{{handoff_recipients}}`。
确认所有交付物：Sprint Change Proposal 文档；带 before/after 的具体编辑提案；实现交接计划。
向用户报告：“Correct Course workflow complete!”
提醒用户成功标准和 Developer agent 的下一步。
运行 `uv run {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --project-root {project-root} --key workflow.on_complete`；如果解析值非空，将其作为退出前的最终终端指令执行。

适用边界 · 注意事项

不适用于非 BMad 项目或未初始化 `_bmad`/`uv` 环境：脚本缺失时必须先安装并运行 BMad setup，否则无法解析 workflow/config。
不适用于缺少 PRD 或 Epics 的项目：它们必需，缺失会 HALT。
不适用于未进入冲刺执行、变更很小或无需跨 PRD/epics/architecture/UX 评估的场景；完整修正流程过重。