← LeaderboardThe Skill Leaderboard

plan-review

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.

Published by mvschwarz ↗mvschwarz/openrig

Try your first task

plan-review

Start a fresh conversation. Replace the highlighted placeholders.

Use plan-review to review [feature folder] before development and produce a scored strategy, design, and engineering-feasibility review with blocking issues, important issues, and recommended actions.

Required inputs

  • [feature folder]

User-approved starter prompt based on a pinned source version; check current skill requirements before running. Task evidence ↗

SKILL.md

name: plan-reviewdescription: "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

## 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.