tobihagemann/review-plan

Review Plan

Review a planning artifact against type-specific criteria. Runs internal review and $peer-review in parallel by default. Returns combined structured findings.

Step 1: Determine Artifact Type and Resolve

Determine Artifact Type

1. Explicit argument — If the user specified a type (e.g., "review shells", "review spec"), use it. No argument defaults to plan.
2. Conversation context — If artifact text or a path is already in context, infer the type.
3. Auto-detect — Check .turbo/ for existing artifacts. If multiple types exist, pick the one with the most recently modified file.

Resolve the Artifact

Plan (default)

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 artifact was found to review

Shells

1. Shell text in conversation — use it
2. Explicit spec slug — Glob .turbo/shells/<slug>-*.md
3. Explicit spec path — derive slug from filename, glob as above
4. Single spec — Glob .turbo/specs/*.md. If exactly one, derive slug and glob for shells
5. Most recent spec — most recently modified spec, derive slug and glob
6. Nothing found — stop and state that no artifact was found to review

For shells, read each shell file and parse its YAML frontmatter (spec, depends_on). Read the source spec from the spec field.

Spec

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

If multiple candidates exist, pick the most recently modified.

Step 2: Run Reviews in Parallel

Read the reference file for the resolved type:

• Plan — references/plan-review.md
• Shells — references/shells-review.md
• Spec — references/spec-review.md

Skip peer review when the caller asked (e.g., "without peer review", "no peer", "internal only"). For shells, the internal review focuses on structural wiring and skips the project context read.

Run the review branches independently. Launch them with spawn_agent / wait_agent using inherited model defaults. That is two branches when peer review is active (one internal + one peer), or one branch when peer review is skipped. Every branch 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. For a check that genuinely requires mutating code (such as testing whether a finding holds), the branch works in an isolated git worktree created under $TMPDIR and discarded afterward. 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. Afterward the branch verifies that git worktree list no longer shows the worktree, that git status --short is clean, and that the shared tree's dependency directory still resolves (a destroyed install leaves git status clean, since it is gitignored). Damage the branch cannot repair is reported with the exact repair command in place of findings.

• Internal branch: Read the artifact text, the reference file content, project context (AGENTS.md and relevant codebase files), then apply criteria and return findings in the output format below.
• Peer review branch (unless skipping): Spawn a Codex sub-agent and instruct it to read and follow $peer-review from the installed skill directory, with a request describing: (a) the artifact under review; (b) the criteria live in ~/.agents/skills/review-plan/references/<type>-review.md for the resolved type from Step 1 — the reviewer should read that file directly and use its priority scale; (c) the Overall Verdict should use the Readiness: <ready | needs revision> label. The branch prompt must also state explicitly that the sub-agent's final message must contain the verbatim findings text $peer-review produced.

Aggregate findings with attribution (reviewer: "internal" or "peer"). Present them in the output format below.

Then call update_plan to mark this step completed and continue with the next step of the active workflow.

Output Format

Format each finding as:

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

**Section:** <plan section, shell number(s), or spec section>
**Reviewer:** <internal | peer>

<one paragraph explaining the issue and its impact>

After all findings, add:

## Overall 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.