Reviewing plans
Skill ogu8/reviewing-plans
A Claude Code skill that reviews AI-generated implementation plans before execution, catching scope creep, vague steps, missing verification, and hidden risks before they become problems.
npx -y skills add ogu8/reviewing-plansAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Use when reviewing an AI-generated implementation plan before execution, when handed a plan to approve, or when checking if a plan is ready to act on
SKILL.md
2.7 KB, as published. Nobody here has run it
Reviewing Plans
Core mindset: You're not checking whether the plan sounds smart. You're checking whether a diligent but literal executor can follow it step by step and arrive at exactly what you wanted — nothing more, nothing less.
Announce at start: "I'm using the reviewing-plans skill to review this plan."
1. Problem & Scope
- Does it restate and solve the actual problem, not a nearby easier one?
- Is this the simplest approach that solves it, or is there an obvious simpler alternative?
- No extra features or refactors you didn't ask for. No vague hand-waving ("handle edge cases") on the hard parts.
- If you can't tie a step to your original request in one sentence, cut it.
2. Step Quality
Each step must be specific (exact files/functions), atomic (one thing), ordered (no forward dependencies), and verifiable (clear "done" condition).
Red flags: vague steps ("clean up the code"), bundled mega-steps, assumed knowledge not in the plan.
3. Dependencies & Risk
- Steps in the right order? Hidden dependencies called out?
- What's the blast radius? Destructive actions (deletions, migrations) isolated and done last?
- If step N fails, are steps 1–(N-1) still usable?
4. Verification
- Does it start from a known state and end with a verified one?
- Every meaningful step has a concrete check ("run suite X, expect green" not just "run tests").
- Final end-to-end verification exists, not just step-by-step.
- Existing behavior is confirmed preserved.
5. What's Missing
- Failure handling (network errors, invalid input, partial state)
- Existing tests — will they still pass?
- Boundaries (empty states, first run, large datasets)
- Cleanup (dead code, imports, deprecations)
6. Exit Criteria
"Done" is clearly defined, independently verifiable, and ends with a concrete deliverable — not "continue improving."
7. Red Flags Cheat Sheet
| You see | It means |
|---|---|
| "Refactor/update as needed" | No plan, will improvise |
| "For completeness" / "While we're here" | Scope creep |
| Steps with no verification | Will claim success unchecked |
| New abstractions for one use case | Over-engineering |
| Touching unrelated files | Scope creep or misunderstanding |
| "Should be straightforward" | Hasn't thought it through |
| No mention of existing tests | Will break things silently |
| "We'll handle that later" | Deferring the hard part |
| "Similar to how we did X" | Assuming without verifying |
| Plan starts with code changes, not verification | Guessing, not diagnosing |