review-plan

Files (1)

• SKILL.md

SKILL.md (first lines)

# Review Plan

Review the provided implementation plan impartially before execution.

Your job is not to approve the plan.
Your job is not to find issues for the sake of finding issues.
Your job is to determine whether the plan is accurate, appropriately scoped, consistent with the codebase when available, and safe to execute.

Be pragmatic, evidence-based, and honest.

## Core Behavior

When this skill is used:

1. Read the full plan before commenting.
2. Identify the stated goal of the plan.
3. Inspect only relevant codebase files before making claims about files, symbols, APIs, tests, commands, architecture, or conventions.
4. Compare the plan against the actual codebase when the codebase is available.
5. Report confirmed problems, uncertainties, design concerns, and things that appear sound.
6. Do not implement the plan.
7. Do not edit files.
8. Do not rewrite the plan unless the user explicitly asks for a revised version.
9. Produce a concise copy/paste summary that the user can paste back into the original planning conversation.

Default mode is review-only.

## If Codebase Is Unavailable

If the codebase is unavailable, do not make codebase-specific claims.

Review only:

- goal clarity
- internal consistency
- scope fit
- sequencing
- risk
- validation

Label the result as a plan-only review.

Do not claim that files, symbols, commands, tests, routes, components, database fields, or codebase patterns exist or do not exist.

## Goal Clarity

Before reviewing details, check whether the plan has a clear goal.

The goal is clear only if the plan explains:

- what user-visible or externally verifiable behavior should change
- what counts as done
- the intended scope of the change

If the goal is unclear enough that correctness cannot be judged, stop and ask for clarification.

If some parts can still be reviewed safely, provide only those observations and clearly label the result as a limited review.

Do not review a plan against an inferred goal unless the user explicitly asks you to make assumptions.

## Review Depth

Scale the review to the size and risk of the plan.

For small plans, keep the review short and focus only on:

- goal clarity
- codebase accuracy, if codebase is available
- consistency with existing patterns, if codebase is available
- scope fit
- validation

For medium or large plans, use the full review structure.

For risky plans, pay extra attention to sequencing, reversibility, data safety, authorization, migrations, production behavior, and validation.

## Relevance Rule

Only inspect files and behavior directly related to the plan.

Do not perform a broad architecture review.
Do not search for unrelated improvements.
Do not review code style unless the plan depends on it.
Do not recommend refactors unless they are necessary for the stated goal.
Do not expand the plan beyond what is needed to achieve the goal safely.

## Review Focus

Check the plan for the following.

### 1. Goal Clarity

Determine whether the goal is specific enough to review.

Flag vague goals such as:

- "improve the flow"
- "clean this up"
- "make it better"
- "fix the feature"

Recommend a clearer goal when possible.

### 2. Codebase Accuracy

When the codebase is available, verify that the plan references real codebase elements.

Check:

- file names
- file paths
- components
- functions
- classes
- routes
- schemas
- commands
- tests
- configuration files
- package scripts

From bogdanbujdea/ai-coding-playbook, MIT.

More from bogdanbujdea/ai-coding-playbook