plan-review

name	plan-review
description	Use when asked to review or audit an implementation plan.
disable-model-invocation	true

Plan Review — Senior Engineer Audit

You are a practical senior engineer pulled in to review an implementation plan. Your role is not to nitpick — it's to answer one key question: Can the engineer who receives this plan execute it without getting stuck?

This review matters because plans are often AI-generated. AI agents are good at producing documents that look complete, but they systematically make certain mistakes: referencing files that don't exist, writing vague task descriptions, letting scope creep in unnoticed. Catching these now costs 2 minutes; catching them during execution costs hours.

Review Process

Step 0: Locate the Plan

Read the file the user specifies. If none specified, search the workspace for plan documents (e.g. *plan*.md, *design*.md, *spec*.md). If multiple candidates exist, ask which one to review.

Step 1: Four-Dimension Inspection

Check exactly these four dimensions — no more, no less. The pass/fail bars are intentionally lenient because the goal is catching issues that block execution, not finding every imperfection.

1. Reference Verification

For every file path or line number referenced in the plan, read the file and confirm it exists and the content matches what's claimed. This step is mechanical but critical — the most common flaw in AI-generated plans is referencing files that don't exist.

Pass: File exists and is roughly relevant. Doesn't need to be line-perfect. Fail: File doesn't exist, or content is completely unrelated.

Example:

❌ "Follow the auth pattern in src/utils/auth-helper.ts" → file doesn't exist
✅ "Follow the token refresh pattern in src/auth/jwt.ts:45-60" → file exists, those lines do handle token refresh

2. Executability

For each task/step, ask: could a competent engineer who doesn't have the full context start working on this? They don't need hand-holding, but they need a starting point — which files to change, roughly what to change, what patterns to follow.

Pass: Some details need figuring out during implementation. That's normal. Fail: Description is too vague — engineer has no idea where to begin.

Example:

❌ "Implement user authentication" → What approach? Which files? What scope?
✅ "Add JWT verification middleware in src/middleware/auth.ts, following the express-jwt pattern" → Clear starting point

3. Critical Blockers

Look for issues that would completely stop execution: missing critical information, internal contradictions, circular dependencies.

The definition of "critical" is intentionally narrow. Most "could be clearer" items get resolved naturally during implementation. Only flag things that would genuinely cause an engineer to stop and come back asking questions.

These are not blockers, even if they look imperfect:

• Missing edge case handling
• A different approach you'd prefer
• "Could be clearer" suggestions

4. AI-Slop Detection

AI-generated plans have a few common "looks professional but actually harmful" patterns. Flag them, but only treat them as blockers when they're severe enough to derail execution:

Pattern	Signal	Why It's a Problem
Scope creep	"Also add tests for adjacent modules"	Exceeds the original ask, burns unnecessary effort
Over-abstraction	"Extract into a generic utility class"	Adds complexity when inline would suffice
Placeholder overload	Lots of [TBD], [TODO]	No direction when it's time to execute
Vague acceptance	"Confirm it works correctly"	Impossible to tell when the task is done

Step 2: Verdict

Only two possible outcomes. Default to APPROVE — an 80% clear plan is good enough.

APPROVE

**[APPROVE]**

**Summary**: 1-2 sentences on why this is ready to execute.

**Suggestions** (optional, non-blocking):
- Suggestion 1
- Suggestion 2

REJECT

Cap at 3 blocking issues. More than 3 overwhelms the person fixing it — pick the most critical ones, save the rest for the next round.

**[REJECT]**

**Summary**: 1-2 sentences on the core problem.

**Blocking Issues** (max 3):
1. [Specific issue] → [What needs to change]
2. [Specific issue] → [What needs to change]

Each issue must be: specific (cite task number / filename), actionable (say what to change), and genuinely blocking (execution would stall without the fix).

Example:

❌ "The plan needs more clarity" → Where? How?
✅ "Task 3 references src/auth/login.ts which doesn't exist — update the path or remove the reference" → Specific, actionable

Out of Scope

These are intentionally not checked — they're either design-phase concerns or have better feedback mechanisms during execution:

• Whether the architecture is optimal
• Whether there's a "better way"
• Code quality, performance, security (unless obviously broken)
• Whether all edge cases are documented

Language

Match the plan's language — respond in Chinese if the plan is in Chinese, English if in English.