correct-course

修正方向

当情况发生变化时（出现新信息、某个假设不成立、范围有所调整），如果当前流水线产物已不再可信，就运行此技能。/correct-course 会诊断影响范围，指出需要重新运行的最早技能，并引导你清理过时产物，然后再继续推进。

这是 references/SYSTEM-OVERVIEW.md（与此技能一同打包）中流水线恢复规则的命名、可调用形式。这些规则仍然适用——此技能只是为它们提供了一个入口。

每轮只问一个问题。 在此技能的整个过程中，每次只问一个问题，并等待用户回答后再问下一个。回溯是一次对话，不是一张表单。

优先使用单选。 当用户要选择一个方向、一项优先事项或一个下一步时，使用单选多项选择。

尽量少用多选。 仅在选项彼此兼容、可以同时成立时使用，例如目标、约束、非目标和成功标准。如果优先级很重要，请接着询问所选项目中哪一项最重要。

有可用的平台提问工具时，使用该工具。 在 Claude Code 中，使用 AskUserQuestion；在 Codex 中，使用 request_user_input；在 Gemini 中，使用 ask_user。否则，在聊天中列出带编号的选项，并等待用户回复后再继续。

调用位置

这是一项侧向流程技能，会根据诊断结果，在主流水线中较早的相应技能处重新衔接。

符合以下任一条件时，使用 /correct-course：

• /research 发现版本变化或约束条件，使 /shape 的总结失效
• /write-a-prd 发现问题在塑形阶段就被错误界定
• /prd-to-issues 发现总工作量明显超出预期投入
• /execute 遇到错误，且根本原因是归档的研究资料或 PRD 有误
• /pre-merge 的 Boundary Map Contracts 维度发现规范与现实不符——代码反映了外部现实，但声明的规范已经过时（软件包不存在、公共 API 已重命名，或版本偏差超出研究快照所锁定的范围）
• /pre-merge 发现需要返工而非仅提供建议的架构问题
• GitHub issue 所描述的工作已被重新塑形或取代，导致该 issue 过时

以下情况不要使用：

• 仍在按计划推进（使用常规流水线）
• 只需分诊的缺陷（使用 /qa）
• 与过时产物无关的重构机会（使用 /request-refactor-plan）
• 尚无任何先前产物，需要从头开始塑形（使用 /shape）

流程

1. 记录触发原因

只问一个问题：“发生了什么变化，以至于当前产物不再可信？”

让用户用自己的话描述。此时不要追问。你要了解的是失效类型，而非完整经过：

• 新信息——版本检查、基准测试、利益相关方的意见、演示失败
• 假设不成立——/shape 总结中标为 Likely 或 Uncertain 的内容后来被证实有误
• 范围调整——预期投入、禁止事项或必备项需要更改
• 问题界定错误——用户意识到自己解决的是表面症状，而非根本问题
• 外部因素——某个依赖已弃用、定价层级发生变化，或合作伙伴 API 已被移除

用一句话记下你认为的问题类型。第二步会用到这句话。

2. 诊断影响范围

根据触发因素，确定最早一个输出已不再可信的技能。经验法则：

触发因素	最早受影响的技能
/shape 的假设有误	/shape
版本或 API 的实际情况与归档研究不符	/research
问题界定有误——解决的是症状，而非原因	/shape
需要更改投入预算或禁区	/write-a-prd
解决方案方向有误，但问题和投入预算仍然成立	/write-a-prd
切片拆分发现工作量超出投入预算	/write-a-prd（重新塑造），而非 /prd-to-issues（重新拆分）
边界图中的契约有误，但切片仍然有效	/prd-to-issues
切片正确，但执行方法遇到阻碍	/execute（无需回退——尝试其他方法）
/pre-merge 提出的架构问题需要返工	/execute，也可以先运行 /request-refactor-plan

通过调查确认。阅读 PRD 议题、任何切片议题、该功能的研究归档条目，以及相关的 solutions 条目。研究条目位于 PRD 引用的绝对路径（/research Phase 5c 会说明写入位置）；如果还没有 PRD，就没有可供引用的路径，因此请遵循 /write-a-prd § 4 中“Research document”的查找说明，该说明会告诉你如何匹配并引用该条目。通过捆绑的解析器 references/sidecar.sh 查找经验教训：将命令开头设为 SC="<this skill's directory>/references/sidecar.sh"，并读取 bash "$SC" solutions-dirs 输出的每个目录；该解析器负责此策略（其标头中有说明）。使用 sidecar.sh require <path> --from "PRD #<n>" 检查 PRD 引用的路径；MISSING: 行本身就是过时产物，需在第 3 步中列出。目标是具体说明，而不是说“塑形已过时”，而是说“研究中的 Ably 与 Pusher 选择有误，因为 Ably 提高了免费套餐限额，而 Pusher 降低了限额。”

用一到两句话向用户说明诊断结果，并提出一个问题：“这符合发生的变化吗？” 如果不符合，继续完善。如果符合，就继续。

3. 列出过时产物

现在列出恢复推进前需要处理的每一项持久产物。具体说明——写出准确的议题编号和文件路径。常见的过时产物：

• 研究归档条目（PRD 引用的绝对路径；/research Phase 5c 会说明写入位置）——如果最早受影响的技能是 /shape，保留归档条目；它是特定时间点的历史记录，不会误导不再引用它的下游技能。如果最早受影响的技能是 /research，则重新运行 /research，生成新的、注明日期的条目，以取代旧条目；先前的快照仍保留在归档中，作为上下文。回退时不删除归档条目——它们位于仓库之外，保留成本为零。
• PRD GitHub 议题——如果问题和投入预算仍然成立，则原地更新；如果整个 PRD 都要重新塑造，则发表评论并关闭
• 切片 GitHub 议题——如果要重新塑造 PRD，则逐一发表评论并关闭，标记为已被取代；如果某个切片仍然有效，则发表评论并保持开启
• 规划或容器里程碑——通常保持开启；里程碑中的功能议题或切片议题才是真正的产物
• Solutions 条目（仓库内或 sidecar 中）——如果这种情况表明记录的经验教训有误，则标记为过时，但未经用户确认不要删除
• 未关闭的 PR——如果 PR 基于过时产物，则发表评论说明回退原因后关闭；如果代码仍然正确，只是问题界定有误，则保持开启
• 活跃的功能分支——通常保留；分支只是代码历史记录，不是持久规划产物

对每项产物，说明其名称、应采取的处理方式（删除、原地更新、发表评论后关闭），并用一句话说明原因。以编号计划的形式向用户呈现完整清单。

4. 逐项清理

每次只处理一个产物，逐项完成清理。对每个产物：

1. 说明你准备做什么，以及原因。
2. 请用户确认（只问一个问题：“要继续处理这一项吗？”）。
3. 执行操作。酌情使用 gh issue close、gh issue comment 或直接删除文件。
4. 继续处理下一项。

不要用一次确认打包整个清理流程。每个产物都是一个影响较小、可撤销的决定，打包确认会增加遗漏细微错误的风险。逐项确认的成本很小；错误关闭 issue 的代价却很大。

如果用户对任何一项有所犹豫，就跳过，并在最终摘要中将其标记为“需要审核”。不要施压。

5. 交接

清理完成后，明确说明：

• 用户下一步应运行哪个 skill（即步骤 2 中受影响的最早 skill）
• 在该 skill 中需要带上哪些上下文（触发因素、诊断结果，以及保留供参考的产物）
• 重新运行是否应限定在特定内容上（大多数回溯都应限定范围——例如“重新研究实时服务提供商的决策”，而不是完整重跑）

如果对话已经很长，建议在新会话中启动下一个 skill。结束摘要应是精简的交接说明。

此 Skill 不是什么

• 不是 Bug 分诊工具。 如果触发因素是测试失败或运行时错误，请先使用 /qa，诊断这是 Bug 还是过时产物问题（/qa 的逐项深度检查会在需要确定根因时委派给 /triage-issue）。
• 不是重构规划器。 如果触发因素是架构方面的问题，且没有过时的上游产物，请使用 /improve-codebase-architecture 或 /request-refactor-plan。
• 不是完整重跑。 好的修正会将重跑范围限定在发生变化的部分，而不是所有内容。目标是：“我们制定了 X，但 Y 有误，因此要重新研究 Z。”
• 不能替代 Pipeline Recovery 参考文档。 references/SYSTEM-OVERVIEW.md 中的 Pipeline Recovery 部分仍是 Skill Kit 中关于回溯含义的权威说明；此 skill 让该参考文档可以直接调用。若要深入阅读，仓库中的原文位于 https://github.com/chrislacey89/skills/blob/main/SYSTEM-OVERVIEW.md。

交接

• 预期输入： 使上游产物失效的触发因素，以及足以诊断影响范围的上下文
• 产出： 清理后的仓库状态，其中过时产物已删除、更新或关闭，并明确指出主流程中的重新进入节点
• 重新进入主流程的节点： 根据诊断结果，选择 /shape、/research、/write-a-prd、/prd-to-issues 或 /execute
• 后续步骤： 用户运行建议的较早阶段 skill，并将范围限定在变更内容内；如果修正较大，则在新会话中进行