gds-correct-course

Correct Course - Sprint Change Management Workflow

目标： 在冲刺执行期间管理重大变更，分析其对所有项目制品的影响，并生成结构化的 Sprint 变更提案。

你的角色： 你是一名正在应对变更管理的开发者。分析触发问题，评估其对 GDD、史诗、架构和 UX 制品的影响，并生成可执行的 Sprint 变更提案，明确交接事项。

约定

• 裸路径（例如 checklist.md）相对于技能根目录解析。
• {skill-root} 指向此技能的安装目录（即 customize.toml 所在目录）。
• {project-root} 指向最近的包含 _bmad/ 的文件夹；从项目工作目录开始，逐级向上搜索其父目录。
• {skill-name} 指向技能目录的基本名称。

激活时

第 1 步：解析工作流块

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

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

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 步：加载配置

从 {project-root}/_bmad/gds/config.yaml 加载配置并解析：

• project_name、user_name
• communication_language、document_output_language
• game_dev_experience
• implementation_artifacts
• planning_artifacts
• project_knowledge
• date，作为系统生成的当前日期时间
• 你必须始终以 Agent 的沟通风格，使用配置中的 {communication_language} 进行交流。
• 语言必须适配 {game_dev_experience}。
• 所有文档均使用 {document_output_language} 撰写。
• 文档输出：更新后的史诗、故事或 GDD 章节。变更须清晰且可执行。游戏开发经验（{game_dev_experience}）仅影响对话风格，不影响文档更新。

第 5 步：问候用户

使用 {communication_language} 问候 {user_name}。

第 6 步：执行后置步骤

按顺序执行 {workflow.activation_steps_append} 中的每个条目。

激活现已完成。如果 activation_steps_prepend 或 activation_steps_append 非空，请在继续之前确认已按顺序执行每个条目。只有完成所有激活步骤后，才能开始主工作流。

路径

• default_output_file = {planning_artifacts}/sprint-change-proposal-{date}.md

输入文件

输入	路径	加载策略
GDD	{planning_artifacts}/*gdd*.md（完整文档）或 {planning_artifacts}/*gdd*/*.md（分片文档）	FULL_LOAD
Narrative	{planning_artifacts}/*narrative*.md（完整文档）或 {planning_artifacts}/*narrative*/*.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
Tech Spec	{planning_artifacts}/*tech-spec*.md（完整文档）或 {planning_artifacts}/*spec-*.md（完整文档）	FULL_LOAD
项目文档	{project_knowledge}/index.md（分片文档）	INDEX_GUIDED

上下文

• 如果存在 **/project-context.md，则加载

执行

文档发现——加载项目制品

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

FULL_LOAD 文档（GDD、Narrative、Epics、Architecture、UX Design、Tech Spec）的发现流程：

1. 先搜索完整文档——查找匹配完整文档模式的文件（例如 *gdd*.md、*narrative*.md、*epic*.md、*architecture*.md、*ux*.md、*tech-spec*.md）
2. 检查是否存在分片版本——如果未找到完整文档，则查找包含 index.md 的目录（例如 gdd/index.md、epics/index.md）
3. 如果找到分片版本：
   • 阅读 index.md 以了解文档结构
   • 阅读索引中列出的所有章节文件
   • 将合并后的内容作为单个文档处理
4. 优先级：如果完整文档和分片版本均存在，则使用完整文档

INDEX_GUIDED 文档（项目文档）的发现流程：

1. 搜索索引文件——查找 {project_knowledge}/index.md
2. 如果找到：阅读索引以了解可用的文档章节
3. 根据与所分析变更的相关性选择性加载章节——不要全部加载，只加载与受影响区域相关的章节
4. 此文档为可选项——如果 {project_knowledge} 不存在，则跳过（全新项目）

模糊匹配：灵活处理文档名称——用户可能使用 gdd.md、game-design-document.md 等变体。

缺少文档：并非所有文档都一定存在。GDD 和 Epics 为必需文档；如果有 Architecture、UX Design、Tech Spec、Narrative 和项目文档，则加载。若找不到 GDD 或 Epics，则必须停止。

如果存在，则加载 **/project-context.md，以获取编码规范和项目级模式 确认变更触发原因，并收集用户对问题的描述 询问：“需要导航的具体问题或变更是什么？” 确认是否可以访问所需的项目文档： - GDD（游戏设计文档） - 当前 Epics 和 Stories - 架构文档 - UI/UX 规范 - 叙事设计文档 询问用户偏好的模式： - **增量模式**（推荐）：协作完善每项编辑 - **批量模式**：一次性展示所有变更以供审查 保存模式选择，以便在整个工作流中使用

必须停止：“如果不清楚触发问题的具体情况，就无法导航变更。请提供需要变更的具体内容及原因。”

必须停止：“需要访问项目文档（GDD、Epics、Architecture、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
  

对于 GDD 修改：

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

对于叙事设计修改：

• 指定要更新的确切章节
• 展示当前内容和提议的变更
• 说明对故事、角色或世界观一致性的影响

对于架构变更：

• 指出受影响的组件、模式或技术选型
• 描述需要更新的图表
• 说明对其他组件的连带影响

对于 UI/UX 规范更新：

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

逐项展示编辑提案 审阅并完善此变更？选项：批准 [a]、编辑 [e]、跳过 [s] 根据用户反馈逐项迭代提案

汇总所有编辑提案，并在本步骤结束时一并展示

编制完整的 Sprint 变更提案文档，包含以下部分：

第 1 部分：问题摘要

• 清晰陈述引发变更的问题
• 说明发现问题的时间和方式
• 提供能证明问题的证据或示例

第 2 部分：影响分析

• Epic 影响：受影响的 Epic 及其影响方式
• Story 影响：需要变更的现有和未来 Story
• 工件冲突：需要更新的 GDD、叙事设计、架构、UI/UX 文档
• 技术影响：对代码、基础设施或部署的影响

第 3 部分：建议方案

• 根据清单评估结果，提出选定的后续方案：
  • 直接调整：在现有计划中修改或添加 Story
  • 可能回滚：撤销已完成的工作，以简化问题解决
  • MVP 审查：缩减范围或调整目标
• 清楚说明建议理由
• 包含工作量估算、风险评估和进度影响

第 4 部分：详细变更提案

• 纳入第 3 步完善后的所有编辑提案
• 按工件类型分组（Story、GDD、叙事设计、架构、UI/UX）
• 确保每项变更均包含变更前后的内容及理由

第 5 部分：实施交接

• 对变更范围分类：
  • 轻微：由 Developer Agent 直接实施
  • 中等：需要重新整理待办列表（PO/DEV）
  • 重大：需要全面重新规划（PM/Architect）
• 指定交接对象及其职责
• 定义实施成功标准 向用户展示完整的 Sprint 变更提案 将 Sprint 变更提案文档写入 {default_output_file} 请审核完整提案。继续 [c] 还是编辑 [e]？

获取用户对完整提案的明确批准 您是否批准此 Sprint 变更提案以供实施？（yes/no/revise） 收集需要调整之处的具体反馈 返回相应步骤以解决相关问题 如果需要修改提案 如果需要调整整体提案结构 最终确定 Sprint 变更提案文档 确定变更范围分类：

• Minor：可由 Developer Agent 直接实施
• Moderate：需要重新组织待办事项，并由 PO/DEV 协调
• Major：需要 PM/Architect 参与进行根本性重新规划

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

转交给：Developer Agent 直接实施 交付物：最终确定的编辑提案和实施任务 转交给：Product Owner / Developer Agent 交付物：Sprint 变更提案 + 待办事项重组计划 转交给：Product Manager / Solution Architect 交付物：完整的 Sprint 变更提案 + 升级通知

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

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

确认已生成所有交付物：

• Sprint 变更提案文档
• 具体编辑提案及修改前后内容
• 实施交接计划

使用个性化消息向用户报告工作流已完成：“Correct Course 工作流已完成，{user_name}！” 提醒用户成功标准以及 Developer Agent 的后续步骤

运行：uv run {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --project-root {project-root} --key workflow.on_complete — 如果解析出的值非空，则在退出前将其作为最后一条终端指令执行。