跳到主要内容
知仓学习社ZHICANG

review-plan

Review a plan by running internal reviews and a peer review in parallel and returning combined findings. Use when the user asks to \"review my plan\…

不碰外部(只输出文字)无严重或高危命中tobihagemann/turbo

它会碰到什么

扫了多少3 个文本文件,14 KB
它会碰到什么不碰外部(只输出文字)
命中总数0 处
命中统计严重 0 · 高 0 · 中 0 · 低 0

这一栏是扫描器报的事实,不是结论。命中多不等于有毒(安全工具、规则库、示例脚本本来就会包含危险写法),命中少也不等于干净。它和你手上的凭据、文件、网络有什么关系,需要你自己看。

技能内容

Review Plan

Review a plan against structure and scope criteria. Runs internal reviews and /peer-review in parallel by default. Returns combined structured findings.

Step 1: Resolve the Plan

  1. Plan text in conversation — use it
  2. Explicit path — read it
  3. Explicit slug — resolve to .turbo/plans/<slug>.md
  4. Single file — Glob .turbo/plans/*.md. If exactly one file exists, use it
  5. Most recent — most recently modified file
  6. Legacy fallback.turbo/plan.md if .turbo/plans/ does not exist
  7. Nothing found — stop and state that no plan was found to review

When the plan came from a file, state the resolved path before continuing.

Unless the plan came from conversation text, or an explicit path or slug was passed, check whether the resolved plan still describes work that remains to be done. Report a frontmatter status: of done alongside the path.

Step 2: Run Reviews in Parallel

Two reference files carry the criteria, one per internal review:

  • [references/plan-structure-review.md](references/plan-structure-review.md)
  • [references/plan-scope-review.md](references/plan-scope-review.md)

Skip peer review when instructed (e.g., "without peer review", "no peer", "internal only").

When a list of already-adjudicated findings was supplied (one line each: the finding, its verdict, and the recorded reason), include it in every agent's prompt, internal and peer, labeled as decisions already reached on proposed revisions rather than as established properties of the plan. Direct each agent to treat a finding as listed when it matches one on both location and substance, to raise such a finding again only on evidence its recorded reason does not already account for, and to judge any other finding at the same location on its own merits.

Emit all Agent tool calls below in one assistant message. Each Agent call uses model: "opus" and no name. Wait for every agent to report before continuing. Do not begin the next step on a partial set, and do not relaunch an agent that has not yet reported. That is three Agent tool calls when peer review is active (two internal + one peer), or two Agent tool calls when peer review is skipped. Every agent's prompt must direct it to treat the shared working tree and its git index as read-only and to assess findings by reading and reasoning. HEAD stays where it is: read other refs with git show <ref>:<path> rather than git checkout or git switch. For a check that requires mutating code, the agent works in an isolated git worktree created under $TMPDIR and discarded afterward. Refer to that worktree by absolute path in every command and join chained steps with &&, so a failed step cannot leave the rest running in the shared checkout. Run teardown and verification as their own commands. Give that worktree its own dependency install rather than reaching the shared tree's install by any route: removing a worktree deletes through symlinks, and a redirected suite writes into the shared install. When its own install is not possible, the check is left unrun and reported as such. A check that runs in the shared checkout invokes an already-installed runner directly wherever a package-manager wrapper would front it, since such a wrapper reads as read-only while reconciling the shared install before it runs. Confine dependency installs and reconciliation to an isolated worktree. Afterward the agent verifies that git worktree list no longer shows the worktree, that git status --short is clean, and that HEAD is still on the branch it started on. It also confirms that no process whose command line names the worktree path is still running, since stopping a runner can leave the processes it spawned alive. When it cannot list processes, it reports that check as unrun and names the worktree path. After any check, in a worktree or in the shared checkout, it verifies that the shared tree's dependency directory still resolves (a destroyed install leaves git status clean, since it is gitignored). Damage the agent cannot repair is reported with the exact repair command in place of findings.

  • Structure Agent: The subagent's prompt must include the plan text, the path to the structure reference file (~/.claude/skills/review-plan/references/plan-structure-review.md), the output format below, and this directive: read that reference file directly, apply its determination criteria as the bar for a real finding, then report every finding that clears that bar tagged with its priority and with internal (structure). Coverage is the goal at this stage, so surface everything that qualifies and let the priority tags convey severity. The subagent must also return the Overall Verdict block for its dimension.
  • Scope Agent: Same, with the scope reference file (~/.claude/skills/review-plan/references/plan-scope-review.md) and findings tagged internal (scope).
  • Peer review Agent (unless skipping): Launch an Agent tool call whose prompt instructs the subagent to invoke /peer-review via the Skill tool with a request describing: (a) the plan under review; (b) the criteria live in ~/.claude/skills/review-plan/references/plan-structure-review.md and ~/.claude/skills/review-plan/references/plan-scope-review.md — the reviewer should read both files directly and cover every criterion in one single-pass review, applying each file's determination criteria and priority scale to the findings in that file's domain; (c) the Overall Verdict should use the Readiness: <ready | needs revision> label; (d) the already-adjudicated findings list when one was supplied, framed as described above. The prompt must also state explicitly that the subagent's final assistant message must contain the verbatim findings text /peer-review produced.

Aggregate findings with attribution (reviewer: "internal" or "peer", each with its "structure" or "scope" dimension). Present them in the output format below.

Then use the TaskList tool and proceed to any remaining task.

Output Format

Format each finding as:

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

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

<one paragraph explaining the issue and its impact>

After all findings, place the Overall Verdict block each internal subagent returned for its dimension, then a single combined block for the peer review:

## Overall Verdict: <Structure | Scope>

**Readiness:** <ready | needs revision>

<1-3 sentence assessment>
## Peer Review Verdict

**Readiness:** <ready | needs revision>

<1-3 sentence assessment>

If there are no qualifying findings, state so and explain briefly.

Rules

  • Present findings grouped by priority.

想直接用这个技能?

本站把开放许可(MIT / Apache 等)的技能按仓库打包整理到网盘,点一下转存到你自己的网盘,不用一个个从 GitHub 拉。许可未声明的技能只给原始仓库链接,不打包。

它属于哪个仓库

星标★ 403
本站分层T2
该仓技能数153
原文件路径claude/skills/review-plan/SKILL.md

同一个仓库里的其他技能

看这个仓库的全部 153 个技能

同名技能的其他版本

有 2 个不同仓库或目录里都有叫 review-plan 的技能。它们内容并不相同,别混用:

  • tobihagemann/turbo — Review a plan by running internal reviews and a peer review in parallel and returning comb