/review-plan

name: review-plan
description: Review implementation plans for parallelization, TDD, types, libraries, and security before execution
disable-model-invocation: true

Review Plan

Review implementation plans (such as those produced by a plan-writing skill) before execution.

Arguments

• Path: Plan file to review (e.g., `docs/plans/2025-01-15-auth-feature.md`)

Anti-confabulation (gate 0 — runs before every other gate)

Before issuing **any** verdict — flag a gap, raise an issue, or assign a verdict — you MUST echo the exact artifact you are judging, quoted from a source you read in **this** turn:

• For a plan finding: the **plan step or section text** under review, quoted from the plan file read freshly now (not recalled from earlier in the session) — cite the heading or step number it came from.
• For a claim about the codebase the plan touches (a type, API, or file the plan references): the **file:line** plus cited code, read freshly now.

> The artifact is the only source of truth. **Never** infer what the plan says from the branch name, the working directory, surrounding files, or recollection. If your mental model differs from the freshly read source, **the source wins.** A verdict issued without a same-turn echo of its target is invalid — emit the echo first, or do not emit the verdict.

This gate exists because an LLM under contextual priming will confidently flag content that is not in the plan. It runs **before** the hard gates below.

Hard gates (sequence)

Do not skip ahead; each step **passes** only when the condition is objectively satisfied (artifact path, tool success, or labeled capture—not “I read it mentally”).

1. **Plan file reachable** — **Pass:** reading `Path` succeeds; if not, stop and report the missing path. **Pass:** You can quote or point to where `**Goal:**`, `**Architecture:**`, and `**Tech Stack:**` appear, *or* you record “header field X absent” as a finding before Step 2. 2. **Skills loaded before reviews** — **Pass:** For each row you will rely on in Step 2’s table, the corresponding skill is loaded (or you record explicit `N/A` with reason, e.g. stack not present). Do **not** start the Step 3 reviews until this gate passes. 3. **Five reviews captured** — **Pass:** You have five labeled artifacts (one per review lens): pasted outputs, subagent transcripts, or saved snippet files. **Pass:** Each of the five INVESTIGATE/CHECK/VERIFY prompts has a corresponding response block before Step 4. 4. **Review file on disk before user prompt** — **Pass:** The file at `[plan-dir]/[plan-basename]-review.md` exists; **Pass:** reading that path succeeds. Only then run the “Next Steps” / options prompt in Step 5.

Step 1: Read and Parse Plan

Read the plan file and extract:

1. **Header fields:**

• `**Goal:**` - Feature description
• `**Architecture:**` - Approach summary
• `**Tech Stack:**` - Technologies used

2. **Verify via file patterns:**

• `.py` files → Python
• `.ts`, `.tsx` files → TypeScript
• `.go` files → Go
• `pytest` commands → pytest
• `vitest`, `jest` commands → JavaScript/TypeScript testing
• `go test` commands → Go testing

Step 2: Load Skills

Load each applicable skill (e.g. the **python-code-review** skill).

Based on detected tech stack, load relevant skills:

| Detected | Skill | |----------|-------| | Python | [python-code-review](../../../beagle-python/skills/python-code-review/SKILL.md) | | FastAPI | [fastapi-code-review](../../../beagle-python/skills/fastapi-code-review/SKILL.md) | | SQLAlchemy | [sqlalchemy-code-review](../../../beagle-python/skills/sqlalchemy-code-review/SKILL.md) | | PostgreSQL | [postgres-code-review](../../../beagle-python/skills/postgres-code-review/SKILL.md) | | pytest | [pytest-code-review](../../../beagle-python/skills/pytest-code-review/SKILL.md) | | React Router | [react-router-code-review](../../../beagle-react/skills/react-router-code-review/SKILL.md) | | React Flow | [react-flow-code-review](../../../beagle-react/skills/react-flow-code-review/SKILL.md) | | shadcn/ui | [shadcn-code-review](../../../beagle-react/skills/shadcn-code-review/SKILL.md) | | vitest | [vitest-testing](../../../beagle-react/skills/vitest-testing/SKILL.md) | | Go | [go-code-review](../../../beagle-go/skills/go-code-review/SKILL.md) | | BubbleTea | [bubbletea-code-review](../../../beagle-go/skills/bubbletea-code-review/SKILL.md) |

Step 3: Run the Five Review Lenses

Run all five review lenses below. **If the agent supports subagents**, dispatch the five in parallel as separate subagents; **otherwise** work through them sequentially yourself, producing the same five labeled outputs. Each review receives:

• Full plan content
• Detected tech stack
• Relevant skill content from Step 2

Lens 1: Parallelization Analysis

Analyze whether this implementation plan can be executed by parallel subagents.

INVESTIGATE:
1. Which tasks can run in parallel (no dependencies between them)?
2. Which tasks must be sequential (Task B depends on Task A output)?
3. Are there any circular dependencies or blocking issues?
4. What is the critical path?

Return:
- Recommended batch structure for parallel execution
- Maximum concurrent agents
- Any blocking issues that prevent parallelization

Lens 2: TDD & Over-Engineering Check

Verify TDD discipline in this implementation plan.

CHECK each task for:
1. Tests written BEFORE implementation (RED phase)
2. Step to run test and verify it fails
3. Minimal implementation to make test pass (GREEN phase)
4. Tests focus on behavior, not implementation details

LOOK FOR over-engineering:
- Excessive mocking (testing implementation vs behavior)
- Too many abstraction layers
- Defensive code for impossible scenarios
- Premature optimization

Return: TDD adherence assessment and over-engineering concerns.

Lens 3: Type & API Verification

Verify types and APIs in the plan match the actual codebase.

SEARCH the codebase for:
1. All types refere