autoplan

/autoplan — 自动评审流水线

一条命令。输入粗略计划，输出经过全面评审的计划。

/autoplan 会全面采用 deep（plan-deep-review）、design、eng 和 DX 评审技能的方法论，深度与手动运行各项技能时相同，严谨程度、章节和输出也完全一致。唯一的区别是：中间的 AskUserQuestion 调用会根据以下 6 项原则自动作出决定。对于品味判断（即合理的人可能意见不一的事项）和用户质疑（即两位评审者都认为用户提出的方向应该改变），会在最后的单一审批关卡中提请用户确认。

这是一个非交互式、完全自动化的工作流，恰有两个需要人工决策的关卡：第 1 阶段的前提确认，以及最后的最终审批关卡。

---

6 项决策原则

以下规则会自动回答所有中间问题：

1. 选择完整性 — 完整交付。选择覆盖更多边界情况的方案。
2. 彻底解决问题 — 解决影响范围内的所有问题（此计划修改的文件及其直接导入方）。自动批准同时处于影响范围内、且 CC 工作量 < 1 天的扩展（< 5 个文件，无需新建基础设施）。
3. 务实 — 如果两个选项能解决同一问题，就选更简洁的那个。花 5 秒做决定，而不是 5 分钟。
4. DRY — 如果会重复现有功能，就拒绝。复用已有内容。
5. 明确胜过巧妙 — 10 行一目了然的修复方案 > 200 行的抽象。选择新贡献者能在 30 秒内读懂的方案。
6. 倾向于行动 — 合并 > 多轮评审 > 无休止的讨论。指出疑虑，但不要阻拦。

冲突解决（根据上下文采用的判定原则）：

• Deep 阶段： P1（完整性）+ P2（彻底解决问题）优先。
• Eng 阶段： P5（明确）+ P3（务实）优先。
• Design 阶段： P5（明确）+ P1（完整性）优先。
• DX 阶段： P5（明确）+ P1（完整性）优先。

---

决策分类

每项自动决策都会分类：

机械决策 — 只有一个明显正确的答案。静默自动决定。示例：运行对抗性子 Agent（始终是），缩减完整计划的范围（始终否）。

品味判断 — 合理的人可能意见不一。自动采用建议方案，但会在最终关卡中提请确认。有三个常见来源：

1. 接近的方案 — 排名前两位的方案都可行，但各有利弊。
2. 范围边界不明 — 处于影响范围内但涉及 3–5 个文件，或影响范围不明确。
3. 子 Agent 意见不一 — 独立子 Agent 提出了不同建议，且理由成立。

用户质疑 — Claude 和独立子 Agent 都认为用户提出的方向应该改变。这与品味判断有本质区别。如果双方都建议合并、拆分、增加或移除用户指定的功能，这就是用户质疑，绝不会自动决定。

用户质疑会提交至最终审批关卡，并附上比品味判断更详细的背景信息：

• 用户的原话：（用户最初提出的方向）
• 双方的建议：（建议作出的改变）
• 原因：（双方的推理依据）
• 我们可能缺少的背景信息：（明确承认盲点）
• 如果我们错了，代价是：（如果用户最初的方向正确，会发生什么）

用户最初提出的方向为默认方案。双方必须说明为什么要改变，而不是让用户证明原方案正确。

**例外：**如果双方都指出该改变涉及安全漏洞或可行性阻碍（而非偏好），AskUserQuestion 的措辞会明确警示：“双方都认为这是安全/可行性风险，而不只是偏好。”最终仍由用户决定，但措辞会体现相应的紧迫性。

---

顺序执行 — 强制要求

各阶段必须严格按顺序执行：Deep → Design → Eng → DX。每个阶段必须完整结束后，才能开始下一阶段。绝不能并行运行各阶段——每个阶段都要基于前一阶段的结果。

每个阶段之间都要输出阶段转换摘要，并确认前一阶段的所有必需输出均已写入，然后再开始下一阶段。

---

“自动决策”的含义

自动决策会用 6 项原则取代用户的判断，但不会取代分析。加载的技能文件中的每个部分仍必须按照与交互版本相同的深度执行。唯一改变的是，由你而不是用户依据 6 项原则回答 AskUserQuestion。

有两个例外——绝不自动决策：

1. 前提（阶段 1）——需要人类判断要解决什么问题。
2. 用户质疑——当双方都认为用户提出的方向应该改变时（合并、拆分、添加或移除功能／工作流）。用户始终拥有双方所缺少的背景信息。

你仍必须：

• 阅读每个部分引用的实际代码、差异和文件
• 产出该部分要求的每项输出（图表、表格、注册表、评分卡）
• 找出该部分旨在发现的每个问题
• 使用 6 项原则决定如何处理每个问题（而不是询问用户）
• 在审计记录中记录每项决定
• 编写所有必需的产物（按技能规范写入计划文件或对话）

你不得：

• 将审查部分压缩成表格中的一句话
• 在没有说明检查内容的情况下写“未发现问题”
• 不说明检查了什么以及为什么不适用，就跳过某个部分
• 用摘要代替所需输出（例如，用“架构看起来不错”代替该部分要求的 ASCII 依赖关系图）

“未发现问题”可以作为某个部分的有效输出，但前提是已完成分析。请说明检查了什么，以及为什么没有标记任何问题（至少 1–2 句话）。“已跳过”对于未列入跳过清单的部分始终无效。

---

阶段 0：接收 + 还原点

步骤 1：捕获还原点

开始任何操作前，保存计划文件的当前状态。如果对话上下文中有计划文件路径，请将其复制到同级还原文件：

PLAN_FILE="<path provided by user or detected>"
[ -f "$PLAN_FILE" ] || { echo "No plan file — skipping restore point."; }
if [ -f "$PLAN_FILE" ]; then
  RESTORE_PATH="${PLAN_FILE%.md}-autoplan-restore-$(date +%Y%m%d-%H%M%S).md"
  cp "$PLAN_FILE" "$RESTORE_PATH"
  echo "Restore point: $RESTORE_PATH"
fi

如果计划文件存在，请在文件开头添加一行 HTML 注释，以便用户查看并重新运行： ``

如果不存在计划文件，请记录：“正在针对分支差异运行 /autoplan（无计划文件）。”

步骤 2：检测平台和基准分支

确定此 PR 的目标分支。在后续每条 git diff、git log 和 git fetch 命令中，都使用检测到的分支作为“基准分支”。

1. gh pr view --json baseRefName -q .baseRefName —— 如果成功，则使用其结果
2. gh repo view --json defaultBranchRef -q .defaultBranchRef.name —— 如果成功，则使用其结果
3. 如果都不成功，则使用 main。

打印检测到的基准分支名称。

步骤 3：读取上下文

• 阅读 CLAUDE.md / AGENTS.md（如果存在），以及 TODOS.md（如果存在）
• git log --oneline -30、git diff <base> --stat
• 计划文件（如果在上面已找到）；否则，将分支差异作为等效计划
• 检测 UI 范围： 在计划／差异中搜索视图／渲染相关术语（component、screen、form、button、modal、layout、dashboard、sidebar、nav、dialog）。至少匹配 2 项。排除误报（单独出现的“page”、“UI”缩写）。
• 检测 DX 范围： 在计划／差异中搜索面向开发者的术语（API、endpoint、REST、GraphQL、gRPC、webhook、CLI、command、flag、argument、terminal、shell、SDK、library、package、npm、pip、import、require、SKILL.md、MCP、agent、developer docs、getting started、onboarding、integration、error message）。至少匹配 2 项。如果产品本身是开发者工具（供开发者安装、集成或用于构建其他产品的工具），也应触发 DX 范围。

输出：“以下是我正在处理的内容：[计划摘要]。UI 范围：[是／否]。DX 范围：[是／否]。开始完整审查流程并自动决策。”

第 4 步：定位 bork plan-* 技能文件

以下每个阶段都会完整遵循一个 plan-* 技能。找到 bork 插件的 gstack 技能文件，以便在需要时阅读其方法论。常见位置：

• ~/.claude/plugins/bork/skills/gstack/<skill-name>/SKILL.md
• 检测方式：find ~/.claude -type f -path '*bork/skills/gstack/plan-eng-review/SKILL.md' 2>/dev/null | head -1

对于运行的每个阶段，如果能找到对应的 SKILL.md，就阅读该文件；否则，遵循你已从技能描述中了解的方法论，以及以下阶段覆盖规则。

跳过的章节列表——遵循已加载的 plan- 技能时，跳过以下内容（此处已处理）：*

• Review Context Detection（已在第 3 步完成）
• Review Pacing（autoplan 强制采用更快节奏——自动决定，不由用户决定节奏）
• PRE-REVIEW SYSTEM AUDIT（已在第 3 步完成）
• Prerequisite Skill Offer
• EXIT PLAN MODE GATE（autoplan 在第 4 阶段有自己的门槛）

只遵循与评审相关的方法论、章节和必需输出。

第 5 步：前提门槛——提供前置技能选项

如果没有发现计划文件，且变更看起来是全新开发或规模较大：

“此分支未找到计划文件。/plan-session 会生成结构化的问题陈述、前提挑战和已探索的替代方案，为 autoplan 提供更明确的输入。大约需要 10 分钟。”

选项：A) 先运行 /plan-session（完成后我们会立即继续 autoplan）。B) 跳过——autoplan 将根据此分支的差异继续。

如果选 A：运行 /plan-session，然后带着设计文档作为计划文件返回此处。如果选 B：继续。

---

第 1 阶段：深入评审（策略与范围）

完整遵循 plan-deep-review 的方法论。覆盖规则：将每个 AskUserQuestion 都依据 6 项原则自动决定。

覆盖规则

• **模式选择：**选择性扩展
• **前提：**接受合理的前提（P6），只挑战明显错误的前提
• 门槛：向用户展示前提以供确认——这是本阶段唯一一个不自动决定的 AskUserQuestion。前提需要人工判断。
• **替代方案：**选择完整度最高的方案（P1）。若并列，选择最简单的方案（P5）。若前两项差距不大 → 标记为 TASTE DECISION。
• **范围扩展：**在影响范围内且 < 1d CC → 批准（P2）。范围之外 → 延后至 TODOS.md（P3）。重复项 → 拒绝（P4）。边界情况（3-5 个文件）→ 标记为 TASTE DECISION。
• **所有 12 个评审章节（来自 plan-deep-review）：**完整执行，对每个问题自动做出决定，并记录每项决定。
• **外部视角：**运行独立的 Claude 子 Agent（前台、阻塞式——不要使用 run_in_background）。

外部视角——Claude 子 Agent

通过 Agent 工具运行独立评审员。子 Agent 提示词：

“阅读位于 <plan_path> 的计划文件（如果没有计划文件，则阅读分支差异 ...HEAD）。你是一位独立的策略评审员，正在评审此计划。你没有看过任何先前的评审。请评估：

1. 这是要解决的正确问题吗？重新界定问题能否带来 10 倍的影响？
2. 前提是明确陈述出来的，还是仅仅被默认了？哪些前提可能是错误的？
3. 6 个月后的后悔情景是什么——到时什么看起来会很愚蠢？
4. 哪些替代方案在缺乏充分分析的情况下就被否定了？
5. 竞争风险是什么——别人能否更早或更好地解决这个问题？

对每项发现，说明问题、严重程度（critical/high/medium）以及修复方法。请持对抗性立场。不要给予赞扬。”

**子 Agent 失败处理：**如果子 Agent 失败或超时，记录“外部视角不可用——仅继续主要评审”，并为此阶段添加 [single-voice] 标签。不要重试。

共识表

子 Agent 返回后，将其输出放在 OUTSIDE VOICE (deep — strategic independence): 标题下，并生成一张共识表：

DEEP REVIEW CONSENSUS TABLE:
═══════════════════════════════════════════════════════════════
  Dimension                            Primary  Subagent  Consensus
  ──────────────────────────────────── ─────── ──────── ─────────
  1. Premises valid?                   —       —        —
  2. Right problem to solve?           —       —        —
  3. Scope calibration correct?        —       —        —
  4. Alternatives sufficiently explored? —     —        —
  5. Competitive/market risks covered? —       —        —
  6. 6-month trajectory sound?         —       —        —
═══════════════════════════════════════════════════════════════
CONFIRMED = both agree. DISAGREE = voices differ (→ taste decision).
Missing voice = N/A. Single critical finding from one voice = flagged regardless.

必需执行清单（深度）

步骤 0（plan-deep-review 中的 0A-0F）——逐项执行并产出：

• 0A：质疑前提，明确列出并评估具体前提
• 0B：现有代码复用映射（子问题 → 现有代码）
• 0C：理想状态图（当前状态 → 本计划 → 12 个月后的理想状态）
• 0C-bis：实施方案对比表（2-3 种方案，包含工作量／风险／优点／缺点）
• 0D：针对模式的分析，并记录范围决策
• 0E：时间维度审查（第 1 小时 → 第 6 小时及以后）
• 0F：模式选择（按覆盖规则选择 SELECTIVE EXPANSION）

plan-deep-review 的第 1-12 节——每节均执行评估标准：

• 有发现的章节：进行完整分析，自动决定每个问题，并记录到审计追踪
• 无发现的章节：用 1-2 句话说明检查了什么，以及为何未标记任何问题。绝不可压缩成一句话。
• 第 12 节（设计）：仅当 Phase 0 检测到 UI 范围时才执行

Phase 1 必需产出

• “不在范围内”章节，列出延期事项及其理由
• “现有内容”章节，将子问题映射到现有代码
• 理想状态差距（本计划结束时的状态与 12 个月后的理想状态之间的差距）
• 错误与恢复登记表
• 失效模式登记表
• 完成情况摘要表（来自 plan-deep-review）

Phase 1 阶段转换

PHASE 1 COMPLETE。 输出：

Phase 1 已完成。外部评审：［N 条关注事项］。共识：［已确认 X/6 项，Y 项存在分歧 → 在关卡处提出］。进入 Phase 2。

在所有 Phase 1 产出完成且前提关卡通过之前，勿开始 Phase 2。

Phase 2 前检查清单（开始前确认）：

• 已产出深度审查完成情况摘要
• 已进行深度审查外部评审（或注明无法进行）
• 已产出深度审查共识表
• 前提关卡已通过（用户确认）
• 已输出阶段转换摘要

---

Phase 2：设计审查（有条件——无 UI 范围时跳过）

如果 Phase 0 未检测到 UI 范围，则完全跳过本阶段。记录：“Phase 2 已跳过——未检测到 UI 范围。”

完整遵循 plan-design-review 的方法论。覆盖规则：对每个 AskUserQuestion，依据 6 项原则自动决定。

覆盖规则

• **关注领域：**全部 10 个维度（P1）
• 结构性问题（缺少状态、层级混乱）：自动修复（P5）
• **美学／品味问题：**标记为 TASTE DECISION
• **设计系统一致性：**如果存在 DESIGN.md，且修复方案显而易见，则自动修复
• **外部评审：**运行独立 Claude 子 Agent（前台运行，阻塞式）

外部评审——Claude 子 Agent

子 Agent 提示词：

“阅读 <plan_path> 处的计划文件。你是一名独立的资深产品设计师，正在审查此计划。你没有看过任何先前的审查。请评估：

1. 信息层级：用户首先、其次、第三会看到什么？这样的顺序是否合理？
2. 缺失状态：加载、空、错误、成功、部分完成——哪些状态没有说明？
3. 用户旅程：情绪变化过程是什么？在哪些地方会中断？
4. 具体程度：计划描述的是具体 UI，还是泛化模式？
5. 如果设计决策含糊不清，会给实施者留下哪些后患？

对每项发现，说明问题所在、严重程度（critical／high／medium）以及修复方案。”

不得提供任何前置阶段的上下文——子 Agent 必须真正独立。

必需执行清单（设计）

1. plan-design-review 的步骤 0：评定完整度（0-10），检查 DESIGN.md，梳理现有模式
2. 进行外部评审；在 OUTSIDE VOICE (design — independent review): 标题下呈现；产出设计共识表（格式与 Deep 相同）
3. 执行 plan-design-review 的第 1-10 轮：逐轮评分（0-10），自动决定每个问题。共识表中的 DISAGREE 项目 → 在相关轮次中提出双方观点。

Phase 2 必需产出

• 全部 10 轮的初始评分 → 修复后评分
• 编辑计划文件，解决所有设计决策
• 完成情况摘要表
• 设计就绪度结论（必须与评分一致）

阶段 2 转换

阶段 2 已完成。 输出：

阶段 2 已完成。外部评审：[N 项关注点]。共识：[X/Y 项已确认，Z 项存在分歧 → 已提交至关卡审议]。进入阶段 3。

阶段 3 前检查清单（开始前确认）：

• 已确认所有阶段 1 项目
• 已撰写设计完成摘要（或“已跳过——不涉及 UI”）
• 已进行设计外部评审（如运行了阶段 2）
• 已生成设计共识表（如运行了阶段 2）
• 已输出阶段转换摘要

---

阶段 3：工程评审

严格按照 plan-eng-review 的方法执行。覆盖规则：将每个 AskUserQuestion 自动处理，并依据 6 项原则作出决定。

覆盖规则

• **范围质疑：**绝不缩减（P2）
• **架构选择：**明确优先于巧妙（P5）。如果子 Agent 给出有依据的不同意见 → 品味决策。两个评审方都同意的范围变更 → 用户质疑。
• **测试缺口：**始终为新代码路径添加测试（P1）。测试计划必须写入计划文件或对话中，不得悄然省略。
• **TODOS.md：**收集阶段 1 中所有推迟的范围扩展，并自动写入
• **外部评审：**运行独立的 Claude 子 Agent（前台运行，阻塞式）

外部评审 — Claude 子 Agent

子 Agent 提示词：

“阅读 <plan_path> 中的计划文件（或分支差异）。你是一名独立的资深工程师，正在评审这份计划。你没有看过此前的任何评审。请评估：

1. 架构：组件结构是否合理？是否存在耦合问题？
2. 边缘情况：负载增至 10 倍时会出现什么问题？nil/空值/错误路径如何处理？
3. 测试：测试计划还缺少什么？周五凌晨 2 点会发生什么故障？
4. 安全：是否扩大了攻击面？授权边界如何？输入验证如何？
5. 隐藏复杂性：哪些看似简单的部分其实并不简单？

对每项发现，说明问题所在、严重程度和修复方案。”

不得提供前序阶段的上下文——子 Agent 必须真正独立评审。

必需的执行检查清单（工程）

1. **步骤 0（范围质疑）：**阅读计划中引用的实际代码。将每个子问题对应到现有代码。运行复杂度检查。给出具体发现。
2. **进行外部评审；**在 OUTSIDE VOICE (eng — independent review): 标题下展示；生成工程共识表：

ENG CONSENSUS TABLE:
═══════════════════════════════════════════════════════════════
  Dimension                            Primary  Subagent  Consensus
  ──────────────────────────────────── ─────── ──────── ─────────
  1. Architecture sound?               —       —        —
  2. Test coverage sufficient?         —       —        —
  3. Performance risks addressed?      —       —        —
  4. Security threats covered?         —       —        —
  5. Error paths handled?              —       —        —
  6. Deployment risk manageable?       —       —        —
═══════════════════════════════════════════════════════════════

3. **第 1 节（架构）：**生成 ASCII 依赖关系图，展示新组件及其与现有组件的关系。评估耦合、扩展能力和安全性。
4. **第 2 节（安全）：**对每个新增攻击面进行威胁建模。自动处理每个问题。
5. **第 3 节（代码质量）：**指出 DRY 违规、命名问题和复杂度问题。引用具体文件和模式。
6. **第 4 节（测试评审）——绝不可跳过或压缩。**本节必须阅读实际代码，不得凭记忆概述。
   • 阅读差异或计划中涉及的文件
   • 绘制测试图：列出每个新增的 UX 流程、数据流、代码路径和分支
   • 对图中的每一项：需要哪类测试覆盖？是否已有测试？存在哪些缺口？
   • 自动处理测试缺口的含义是：识别缺口 → 决定添加测试或推迟（说明理由和所依据的原则）→ 记录决定。这不意味着可以跳过分析。
7. **第 5–8 节（性能、可观测性、部署、并发）：**逐项评估并自动处理每项发现。

阶段 3 的必需输出

• “不在范围内”部分
• “现有内容”部分
• 架构 ASCII 图（第 1 节）
• 将代码路径映射到覆盖范围的测试图（第 4 节）
• 错误与救援映射
• 带有关键缺口标记的故障模式登记表
• 完成摘要
• 就绪情况结论（可开始实现 / 满足条件后可开始 / 需要返工）

阶段 3 转换

阶段 3 已完成。 输出：

阶段 3 已完成。外部评审：[N 项关注点]。共识：[X/6 项已确认，Y 项存在分歧 → 已提交至关卡审议]。进入阶段 3.5（DX）或阶段 4（最终关卡）。

---

阶段 3.5：DX 评审（有条件——如果没有面向开发者的范围，则跳过）

如果在阶段 0 中未检测到 DX 范围，则完全跳过此阶段。记录：“已跳过阶段 3.5——未检测到面向开发者的范围。”

严格遵循 plan-devex-review 的方法论。覆盖规则：对每个 AskUserQuestion，根据 6 项原则自动决策。

覆盖规则

• 模式选择： DX POLISH
• 角色画像： 根据 README/docs 推断，选择最常见的开发者类型（P6）
• 竞品基准： 如果 WebSearch 可用，则执行搜索；否则使用参考基准（P1）
• 惊艳时刻： 选择能达到竞品级别且所需工作量最低的交付方式（P5）
• 入门摩擦： 始终以减少步骤为优化方向（P5）
• 错误消息质量： 始终要求包含问题 + 原因 + 修复方法 + 文档链接（P1）
• API/CLI 命名： 一致性优先于巧思（P5）
• DX 品味决策（例如，固执己见的默认值与灵活性）：标记为 TASTE DECISION
• 外部意见： 运行独立的 Claude 子代理（前台运行，阻塞）

外部意见 — Claude 子代理

子代理提示词：

“阅读 <plan_path> 中的计划文件。你是一名独立的 DX 工程师，负责评审此计划。你此前没有看过任何评审。请评估：

1. 入门体验：从零开始到 hello world 需要几步？TTHW 是多少？
2. API/CLI 易用性：命名是否一致、默认值是否合理、信息是否渐进呈现？
3. 错误处理：每种错误路径是否都说明了问题 + 原因 + 修复方法 + 文档链接？
4. 文档：是否提供可直接复制粘贴的示例？信息架构如何？是否包含交互元素？
5. 退路：开发者能否覆盖所有固执己见的默认值？

对于每项发现，请说明：问题所在、严重程度（严重/高/中）以及修复方法。”

不提供此前阶段的上下文。

必需的执行清单（DX）

1. 自动检测产品类型。绘制开发者旅程。将初始 DX 完整度评为 0-10 分。评估 TTHW。
2. 运行外部意见；在 OUTSIDE VOICE (DX — developer experience challenge): 标题下呈现；生成 DX 共识表：

DX CONSENSUS TABLE:
═══════════════════════════════════════════════════════════════
  Dimension                            Primary  Subagent  Consensus
  ──────────────────────────────────── ─────── ──────── ─────────
  1. Getting started < 5 min?          —       —        —
  2. API/CLI naming guessable?         —       —        —
  3. Error messages actionable?        —       —        —
  4. Docs findable & complete?         —       —        —
  5. Upgrade path safe?                —       —        —
  6. Dev environment friction-free?    —       —        —
═══════════════════════════════════════════════════════════════

3. 执行 plan-devex-review 的第 1-8 轮：逐轮运行，评为 0-10 分，并对每个问题自动决策。共识中的 DISAGREE 项目 → 在相关轮次中提出并列出双方观点。

阶段 3.5 的必需输出

• 开发者角色画像卡（来自步骤 0A）
• 开发者共情叙述（来自步骤 0B）
• 开发者旅程图（来自步骤 0F）
• DX 评分卡，包含全部 8 个维度的评分
• DX 实施清单
• TTHW 评估及目标
• DX 就绪判定

阶段 3.5 转换

阶段 3.5 已完成。 输出：

阶段 3.5 已完成。DX 总体评分：[N]/10。TTHW：[N] 分钟 → [目标] 分钟。外部意见：[N] 项关注。共识：[X/6 项已确认，Y 项存在分歧 → 在评审关卡中提出]。进入阶段 4（最终关卡）。

---

决策审计记录

每次自动决策后，在审计记录中追加一行。运行期间在对话输出中保留该记录，随后在最终关卡输出中回显完整表格：

## Decision Audit Trail

| # | Phase | Decision | Classification | Principle | Rationale | Rejected option |
|---|-------|----------|----------------|-----------|-----------|-----------------|

如果计划文件存在，也使用 Edit 将审计记录写入其中的 ## Decision Audit Trail 标题下（每次增量写入一行——切勿在对话上下文中累积整张表）。

---

预先门禁核验

呈现最终审批门禁前，请核实所需输出是否确实已生成。逐项检查计划文件和对话。

阶段 1（深度审查）输出：

• 挑战前提，并具体列出前提（不能只写“接受前提”）
• 所有适用的审查部分都包含发现，或明确写出“已检查 X，未发现问题”
• 已生成错误与救援登记表（或注明不适用及原因）
• 已生成故障模式登记表（或注明不适用及原因）
• 已撰写“非本次范围”部分
• 已撰写“现有内容”部分
• 已撰写理想状态差异
• 已生成完成摘要
• 已征询外部意见（或注明无法征询）
• 已生成深度审查共识表

阶段 2（设计）输出 — 仅在检测到 UI 范围时：

• 已评估全部 10 项，并给出分数
• 已识别问题并自动作出决定
• 已征询外部意见（或注明无法征询／已跳过）
• 已生成设计共识表
• 已编辑计划文件，落实设计决定

阶段 3（工程）输出：

• 已通过实际代码分析挑战范围（不能只写“范围没问题”）
• 已生成架构 ASCII 图
• 已生成将代码路径映射到测试覆盖范围的测试图
• 已撰写“非本次范围”部分
• 已撰写“现有内容”部分
• 已生成故障模式登记表，并评估关键缺口
• 已生成完成摘要
• 已征询外部意见（或注明无法征询）
• 已生成工程共识表

阶段 3.5（开发者体验）输出 — 仅在检测到开发者体验范围时：

• 已评估全部 8 个开发者体验维度，并给出分数
• 已生成开发者旅程图
• 已撰写开发者共情叙述
• 已评估 TTHW 并设定目标
• 已生成开发者体验实施清单
• 已征询外部意见（或注明无法征询／已跳过）
• 已生成开发者体验共识表

跨阶段：

• 已起草跨阶段主题部分（或注明“没有跨阶段主题”）

审计轨迹：

• 决策审计轨迹至少包含一行自动决策记录（不能为空）

如果上方任意复选框未勾选，请返回并补齐缺失输出。最多重试 2 次 — 如果重试两次后仍有缺失，请带警告继续进入门禁，并注明哪些项目尚未完成。不要无限循环。

---

阶段 4：最终审批门禁

在此停止，并向用户呈现最终状态。

以消息形式呈现，然后使用 AskUserQuestion：

## /autoplan Review Complete

### Plan Summary
[1-3 sentence summary]

### Decisions Made: [N] total ([M] auto-decided, [K] taste choices, [J] user challenges)

### User Challenges (both voices disagree with your stated direction)
[For each user challenge:]
**Challenge [N]: [title]** (from [phase])
You said: [user's original direction]
Both voices recommend: [the change]
Why: [reasoning]
What we might be missing: [blind spots]
If we're wrong, the cost is: [downside of changing]
[If security/feasibility: "⚠️ Both voices flag this as a security/feasibility risk, not just a preference."]

Your call — your original direction stands unless you explicitly change it.

### Your Choices (taste decisions)
[For each taste decision:]
**Choice [N]: [title]** (from [phase])
I recommend [X] — [principle]. But [Y] is also viable:
  [1-sentence downstream impact if you pick Y]

### Auto-Decided: [M] decisions [see Decision Audit Trail above or in plan file]

### Review Scores
- Deep: [summary] | Outside voice: [summary] | Consensus: [X/6 confirmed]
- Design: [summary or "skipped, no UI scope"] | Outside voice: [summary] | Consensus: [X/Y confirmed]
- Eng: [summary] | Outside voice: [summary] | Consensus: [X/6 confirmed]
- DX: [summary or "skipped, no developer-facing scope"] | Outside voice: [summary] | Consensus: [X/6 confirmed]

### Cross-Phase Themes
[For any concern that appeared in 2+ phases' outside voices independently:]
**Theme: [topic]** — flagged in [Phase 1, Phase 3]. High-confidence signal.
[If no themes span phases:] "No cross-phase themes — each phase's concerns were distinct."

### Deferred to TODOS.md
[Items auto-deferred with reasons]

### Implementation Tasks
[Flat list of build-actionable tasks synthesized from this review's findings.
Each task derives from a specific finding. Priority: P1 blocks ship, P2 should
land same branch, P3 is a follow-up TODO. Format:
- [ ] **T1 (P1)** — <component> — <imperative title>
  - Surfaced by: <phase> — <specific finding>
  - Files: <paths>
If zero tasks from a phase, note "_No new tasks from <phase>._"]

认知负荷管理：

• 0 项用户质疑：跳过“用户质疑”部分
• 0 项偏好决策：跳过“你的选择”部分
• 1–7 项偏好决策：使用平铺列表
• 8 项及以上：按阶段分组。添加警告：“此计划存在异常高的模糊性（[N] 项偏好决策）。请仔细审阅。”

AskUserQuestion 选项：

• A) 按原样批准（接受所有建议）
• B) 批准并覆盖部分决定（指定要更改的偏好决策）
• B2) 批准并回应用户质疑（逐项接受或拒绝质疑）
• C) 询问（询问任何具体决定）
• D) 修改（需要修改计划本身）
• E) 拒绝（重新开始）

选项处理：

• A： 标记为已批准。准备创建 PR 时，建议使用 /ship。
• B： 询问要覆盖哪些决定，应用修改，然后重新呈现门禁。
• B2： 逐项处理用户质疑，接受或拒绝，并应用修改，然后重新呈现门禁。
• C： 自由作答，然后重新呈现门禁。
• D： 进行修改。重新运行受影响的阶段（范围 → 阶段 1；设计 → 阶段 2；测试计划或架构 → 阶段 3；开发者体验 → 阶段 3.5）。最多 3 轮。
• E： 重新开始 — 调用 /plan-session 重新制定计划。

---

重要规则

• 绝不中止。 用户选择了 /autoplan。请尊重这一选择。在最终关卡中呈现所有品味判断和用户质疑——绝不要在流程中途转向交互式审查。
• 两个关卡。 不由自动化决策的 AskUserQuestions 有：(1) 第 1 阶段的前提确认，以及 (2) 最终关卡中的用户质疑。其他所有事项都根据 6 项原则自动决策。
• 记录每项决策。 不得静默地自动决策。每项选择都要在审计跟踪中占一行。
• 完整深度意味着全面深入。 不要压缩或跳过已加载技能文件中的章节（第 0 阶段的跳过清单除外）。“完整深度”意味着：阅读章节要求阅读的代码，产出章节要求的内容，找出每个问题，并逐一作出决定。用一句话概述某个章节不算“完整深度”——这属于跳过。如果你发现自己对任何审查章节写不到 3 句话，很可能是在压缩内容。
• 交付物必须提供。 测试图、故障模式登记表、错误/补救表、ASCII 图、DX 评分卡——审查完成时，这些都必须存在于计划文件或对话中。若缺少任何一项，审查就尚未完成。
• 按顺序执行。 Deep → Design → Eng → DX。每个阶段都以前一阶段为基础。绝不能并行运行各阶段。
• 子 Agent 失败不构成阻碍。 如果任一阶段的外部观点收集失败或超时，记录 [single-voice]，并仅依靠主要审查继续执行。

EXIT PLAN MODE 关卡（阻断性）

调用 ExitPlanMode 前，先执行此自检。如果任何一项未通过，就完成缺失的工作——不要调用 ExitPlanMode：

1. 确认已输出所有阶段转换摘要（第 1 → 2 → 3 → 3.5 → 4 阶段）。
2. 确认已运行关卡前验证清单，并已产出任何缺失内容，或注明其未完成及原因。
3. 确认已通过 AskUserQuestion 向用户呈现最终批准关卡，其中至少包含：计划摘要、已作决策的统计、审查评分，以及 AskUserQuestion 选项 A-E。
4. 确认用户已选择一个选项（A/B/B2/C/D/E）。如果用户选择了选项 B/B2/C/D，则确认已完成后续处理（应用覆盖项、回答质疑、回答追问，或重新运行受影响的阶段）。
5. 确认决策审计跟踪非空，且反映了本次运行中实际作出的决策。

未通过此关卡却仍调用 ExitPlanMode，属于违反约定——用户看到的是跳过最终关卡或底层分析的自动计划，并会（理所当然地）拒绝它。需要警惕的自欺模式：写完关卡文本并放进对话后，就觉得“完成了”。用户实际回复 AskUserQuestion（以及对选项 B/B2/C/D 的后续处理）才算完成工作；关卡文本只是提示，并不代表流程已完成。