review-plan

用途

review-plan 用于审查一份计划，依据结构与范围两类标准进行评估。它默认并行运行内部审查与 /peer-review 同行审查，并返回合并后的结构化发现。当用户要求“review my plan”“check my plan”等时使用。

主要能力

解析计划来源：对话中的计划文本、显式路径、显式 slug（解析为 .turbo/plans/<slug>.md）、单一文件（Glob .turbo/plans/*.md，若恰好一个文件则使用）、最近修改的文件，以及旧版回退路径 .turbo/plan.md（当 .turbo/plans/ 不存在时）。若未找到任何计划，则停止并说明没有可审查的计划。
当计划来自文件时，在继续前说明解析出的路径。
除非计划来自对话文本，或传入了显式路径或 slug，否则检查解析出的计划是否仍描述待完成的工作，并报告 frontmatter 的 status: done 及路径。
并行运行审查：两个内部审查各由一个参考文件承载标准（references/plan-structure-review.md 与 references/plan-scope-review.md）。
在收到指示时跳过同行审查（例如“without peer review”“no peer”“internal only”）。
当提供了已裁定发现列表（每行一条：发现、裁定、记录的原因）时，将其纳入每个代理的提示中，内部与同行审查均包含，并标注为对拟议修订已作出的决定，而非计划的既定属性。指示每个代理：当某发现与列表中的一条在位置与实质上均匹配时，视为已列出；仅在有证据表明其记录的原因未涵盖该情况时再次提出；对同一位置的其他发现则按自身情况判断。
以相同方式将计划传递给每个代理：对于磁盘上的计划，给出其绝对路径并指示代理完整读取该文件；对于仅存在于对话文本中的计划，则包含该文本。
在一条助手消息中发出所有 Agent 工具调用。每个 Agent 调用使用 model: "opus" 且不指定 name。等待每个代理报告后再继续。不得在部分集合上开始下一步，也不得重新启动尚未报告的代理。同行审查启用时为三次 Agent 工具调用（两次内部 + 一次同行），跳过同行审查时为两次。
每个代理的提示必须指示其将共享工作树及其 git 索引视为只读，并通过阅读与推理来评估发现。HEAD 保持不变：使用 git show <ref>:<path> 读取其他引用，而非 git checkout 或 git switch。对于需要变更代码的检查，代理在 $TMPDIR 下创建的隔离 git worktree 中工作，之后丢弃。每条命令中都以绝对路径引用该 worktree，并用 && 连接链式步骤，以免失败步骤导致其余步骤在共享检出中继续运行。将拆除与验证作为独立命令运行。为该 worktree 提供自己的依赖安装，而非通过任何途径使用共享树的安装：移除 worktree 会通过符号链接删除，重定向的测试套件会写入共享安装。当其自身安装不可行时，该检查留作未运行并如实报告。在共享检出中运行的检查，在包管理器包装器会前置的情况下直接调用已安装的运行器，因为此类包装器在运行前会协调共享安装，看似只读。将依赖安装与协调限制在隔离 worktree 中。代理启动的每个测试运行器，无论在 worktree 还是共享检出中，都在其自己的进程组中运行，并由运行器外部强制超时。拆除前，代理停止其启动的每个运行器的进程组，因为停止运行器可能使其派生的进程仍存活。之后代理验证 git worktree list 不再显示该 worktree、git status --short 干净、HEAD 仍在起始分支上。它还确认这些进程组中没有进程仍在运行，以及命令行中命名该 worktree 路径（若有）的进程均未运行，并按 PID 报告无法停止的进程。当无法列出进程时，报告该检查未运行，并列出这些进程组及 worktree 路径（若有）。在任何检查之后，无论在 worktree 还是共享检出中，它验证共享树的依赖目录仍可解析（被破坏的安装会因被 gitignore 而保持 git status 干净）。代理无法修复的损坏，以确切的修复命令代替发现进行报告。

使用方式

Structure Agent：子代理的提示必须包含按上述方式传递的计划、结构参考文件的路径（~/.claude/skills/review-plan/references/plan-structure-review.md）、下方输出格式，以及此指令：直接读取该参考文件，将其判定标准作为真实发现的门槛，然后报告每个达到该门槛的发现，并标注其优先级与 internal (structure)。此阶段以覆盖为目标，因此呈现所有符合条件的发现，让优先级标签传达严重程度。子代理还必须返回其维度的 Overall Verdict 块。
Scope Agent：同上，使用范围参考文件（~/.claude/skills/review-plan/references/plan-scope-review.md），发现标注为 internal (scope)。
Peer review Agent（除非跳过）：启动一个 Agent 工具调用，其提示指示子代理通过 Skill 工具调用 /peer-review，请求描述包括：(a) 被审查的计划，按上述方式传递；(b) 标准位于 ~/.claude/skills/review-plan/references/plan-structure-review.md 与 ~/.claude/skills/review-plan/references/plan-scope-review.md——审查者应直接读取这两个文件，并在一次单遍审查中覆盖每条标准，对各自领域内的发现应用该文件的判定标准与优先级量表；(c) Overall Verdict 应使用 Readiness: <ready | needs revision> 标签；(d) 当提供了已裁定发现列表时，按上述方式框定。提示还必须明确说明，子代理的最终助手消息必须包含 /peer-review 产生的逐字发现文本。
汇总发现并附归属（reviewer: "internal" 或 "peer"，各带其 "structure" 或 "scope" 维度）。按下方输出格式呈现。
然后使用 TaskList 工具并继续任何剩余任务。

输出格式

每条发现格式为：

[P<N>] <title (imperative, ≤80 chars)>

Section: <plan section> Reviewer: <internal | peer> (<structure | scope>)

在所有发现之后，放置每个内部子代理为其维度返回的 Overall Verdict 块，然后为同行审查放置一个合并块：

Overall Verdict: <Structure | Scope>

Readiness: <ready | needs revision>

<1-3 sentence assessment>

Peer Review Verdict

Readiness: <ready | needs revision>

<1-3 sentence assessment>

如果没有符合条件的发现，则说明并简要解释。

规则

按优先级分组呈现发现。

适用场景

适用于用户要求审查计划、检查计划等场景，尤其是需要从结构与范围两个维度评估计划，并可能结合同行审查的情况。

限制

若未找到任何计划，则停止并说明没有可审查的计划。
同行审查可在收到指示时跳过。
代理必须将共享工作树及其 git 索引视为只读；需要变更代码的检查在隔离 worktree 中进行。
当 worktree 自身依赖安装不可行时，该检查留作未运行并如实报告。
当无法列出进程时，相关检查报告为未运行。
代理无法修复的损坏，以确切的修复命令代替发现进行报告。