Skip to main content
skill CX Codex

plan-review — Claude Code skill: what it does, how to install

Reviews feature plans and requirements documents across strategy, design, and engineering feasibility before development begins.

Install into Claude Code · Skills CLI (Vercel) All methods and platforms ↓
npx skills add mvschwarz/openrig --skill plan-review -a claude-code
Open on GitHub

What plan-review does

The skill inspects documents inside a feature directory, centering on SPEC.md while taking context from validation.md, background.md, and mockups in supporting/. It audits the plan through three distinct viewpoints: executive strategy, UX and interaction design, and technical engineering feasibility.

The design audit scores six specific criteria from 0 to 10, covering states like empty or error views alongside accessibility and information architecture. For engineering, it avoids drafting architecture code; instead, it checks if acceptance criteria leave room for developer guesswork or carry unaddressed data model dependencies.

Review findings compile into a Markdown report with numerical scores, categorized issues (blocking, important, suggestions), and next actions. Running this skill requires an actual SPEC.md to evaluate, and generating the final executive summary relies on the separate exec-summary skill.

What it helps with

  • catch missing acceptance criteria before development starts
  • evaluate UX interaction states and accessibility on a 0-10 scale
  • identify business scope drift and opportunity costs in feature specs
  • flag unaddressed data model and system dependencies in requirements

Example prompts for the agent

  • Run a plan-review on the feature specification in features/billing/SPEC.md
  • Evaluate SPEC.md across strategy, UX, and technical feasibility
  • Review our feature folder and flag any blocking issues before sprint planning

How to install plan-review

1Skills CLI (Vercel)

npx skills add mvschwarz/openrig --skill plan-review -a claude-code

2Manually: put the files in place

~/.claude/skills/plan-review/SKILL.md

Copy the whole skill folder; for one project use .claude/skills/plan-review/

Step by step, with commands for each platform: How to install skills in Claude Code: five ways

Questions about plan-review

How to install plan-review in Claude Code?

Run npx skills add mvschwarz/openrig --skill plan-review -a claude-code in your terminal.

What files does plan-review evaluate?

The primary document is SPEC.md inside your feature folder. It also reads validation.md, background.md, and references inside supporting/ when available.

Does plan-review design technical architecture?

No. The technical lens focuses strictly on product clarity, spotting vague acceptance criteria, data model shifts, and system dependencies rather than writing implementation architecture.

Source text

SKILL.md · Apache-2.0
---
name: plan-review
description: "Multi-perspective review of a feature plan or requirements doc before development begins. Evaluates from strategy, design/UX, and engineering angles to catch gaps early."
---

You are a multi-perspective plan reviewer. Before a feature moves from requirements to development, you evaluate it from three angles to catch gaps, scope drift, and missed opportunities.

## Three Review Lenses

### 1. Strategy Review (CEO/Product Leader Lens)

- Does this align with company growth objectives?
- Which personas does this serve? Are they buyers, users, or influencers?
- How does this compare to what competitors offer?
- Is the scope right? Too ambitious or too focused?
- What's the opportunity cost — what are we NOT building by doing this?

### 2. Design Review (UX/Interaction Lens)

Rate these dimensions (0-10):
1. **Information architecture** — discoverable and logically organized?
2. **Interaction states** — empty, loading, error, success, edge cases covered?
3. **User journey** — matches how the persona actually works?
4. **Consistency** — follows existing UI patterns?
5. **Accessibility** — keyboard nav, screen readers, color contrast?
6. **AI integration** — if AI-powered, is it natural and trustworthy?

### 3. Engineering Feasibility (Technical Lens)

- Are acceptance criteria specific enough that a dev won't need to guess?
- Are there data model implications needing early discussion?
- Are there dependencies on other features or systems?
- Are there performance/scale considerations?
- Is the scope realistic for the implied timeline?

## Process

### Step 1: Read the Material
Read all available docs in the feature folder:
- **validation.md** — office hours verdict, demand evidence, wedge scope (if exists)
- **background.md** — customer drivers, competitive context (if exists)
- **SPEC.md** — the main document to review
- **supporting/** — mockups, data files, visual references

### Step 2: Run All Three Reviews

### Step 3: Synthesis

```markdown
## Plan Review: [Feature Name]

**Date**: [date]
**Reviewed**: [SPEC.md path]

### Strategy Assessment
**Score: [1-10]**
- [Key findings]

### Design Assessment
**Score: [1-10]**
| Dimension | Score | Notes |
|-----------|-------|-------|
| Information Architecture | X/10 | [notes] |
| Interaction States | X/10 | [notes] |
| User Journey | X/10 | [notes] |
| Consistency | X/10 | [notes] |
| Accessibility | X/10 | [notes] |
| AI Integration | X/10 | [notes] |

### Engineering Feasibility
**Score: [1-10]**
- [Key findings]

### Issues Found

#### Blocking (must fix before dev)
1. [Issue with specific reference to requirement]

#### Important (should fix, but not blocking)
1. [Issue]

#### Suggestions (nice to have)
1. [Suggestion]

### Recommended Actions
- [Specific actions before proceeding to development]
```

### Step 4: Generate Executive Summary

After the review is complete and issues are resolved, generate an executive summary using the exec-summary skill. Save it to the feature folder as `executive-summary.md`.

## Guidelines

- **Be specific.** Cite exact requirements that have issues.
- **Reference real context.** Check personas, competitors, and existing features.
- **Don't do the dev's job.** The engineering lens is about PM-side clarity, not architecture.
- **Praise what's good.** Helps the PM know what to keep doing.

© mvschwarz · Apache-2.0 · mvschwarz/openrig

Similar skills

All skills for Writing and docs →

From the same set49

orchestration-team An orchestration skill: it splits work into assignments, dispatches them, and watches for idle or blocked agents instead of doing the implementation itself. CX Codex +1 ★ 8,227repo stars development-team Coordinates building and QA inside a development pod. It guides agents to deliver working code verified against public contracts. CX Codex +1 ★ 8,227repo stars ui-mockup Create ASCII wireframes, standalone HTML screens, or live prototypes from product requirements. Use the skill to review a proposed interface before building it. CX Codex +1 ★ 8,227repo stars requirements-writer Talks a product manager through rough feature notes and turns them into a single SPEC.md with observable acceptance criteria and explicit scope. CX Codex +1 ★ 8,227repo stars office-hours This skill challenges a feature idea with six product questions about demand, current workarounds, and scope. It ends with a documented verdict. CX Codex +1 ★ 8,227repo stars exec-summary Turns a feature folder into one 600–800 word document: a sales pitch, a leadership brief and a behavioral overview for engineering. CX Codex +1 ★ 8,227repo stars context-builder Gathers feature background from meetings, competitor research, and regulations. Generates a concise background.md and updates shared team context. CX Codex +1 ★ 8,227repo stars backlog-capture Turns rough product ideas, requests, and meeting notes into backlog entries while checking for duplicates. Useful when capturing input from customers, sales, or research. CX Codex +1 ★ 8,227repo stars

Project sponsors

Companies that keep this analytics open
Gold sponsor

Impressions, clicks and code copies — open statistics. We keep the numbers public for the same reason NeBlask itself is public. Become a sponsor