plan-review

$npx mdskill add mvschwarz/openrig/plan-review

Evaluates feature plans from strategy, design/UX, and engineering perspectives to catch gaps early

  • Identifies alignment with company goals and user needs.
  • Deploys a scoring system for IA, interaction states, user journey, consistency, accessibility, and AI integration.
  • Generates specific acceptance criteria based on feature requirements.
  • Communicates findings through reports or recommendations to stakeholders.

SKILL.md

.github/skills/plan-reviewView on GitHub ↗
---
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)
- **requirements.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**: [requirements.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.

More from mvschwarz/openrig

SkillDescription
agent-startup-and-context-ingestionUse when designing or auditing how an agent becomes useful after launch — AGENTS.md overlays, role files, skills, rig specs, workflow specs, startup checklists, refocus messages, "rig context" surface. Covers the 4 failure modes that make startup context fail (old rig spec misses current operating mode; current agents never told about new guidance; startup file as dumping ground; orchestrator transmits implementation without preserving product intent).
backlog-captureQuickly capture product ideas, feature requests, or insights from meetings and conversations. Rapid documentation with smart categorization and deduplication.
claude-compaction-restoreUse when a Claude Code session has just compacted, is about to compact, reached context limit, resumed after /compact, or needs to rebuild its working mental model from Claude JSONL transcripts and touched files.
context-builderGather and distill context from meetings, competitors, regulatory sources, and internal discussions. Produces background.md for a feature and updates shared context docs when new knowledge is discovered.
development-teamHow the development pod coordinates implementation, QA, and design without skipping gates.
forming-an-openrig-mental-model|
mission-slice-sopUse when working a mission or slice — the full SDLC flow (intent → mini-requirements + proof contract → mockups → plan-lock → build → QA visual compare → `rig proof` drops → proof-lock) plus how to track, prove, hand off, and carry state across agents and compaction via the canonical files (PROGRESS.md / PROOF.md / MISSION_NOTES.md / MISSION_BRIEF.md / README.md / IMPLEMENTATION-PRD.md). Covers the convention sections the Living Notes UI projects, the two locks, the three role contracts, per-file WHO/WHEN/HOW rules, the four-legs lifecycle, hot-potato queue handoffs, the moment-of-truth checklist, the deterministic `rig scope audit` backstop, and the ghost-text capture gotcha.
openrig-architectUse when designing multi-agent topologies that run ON OpenRig — authoring RigSpec and AgentSpec files for new rigs, creating agent startup content (guidance / skills / culture), or diagnosing why a launched rig's agents aren't behaving as intended. NOT for changing OpenRig itself (work in the openrig product repo); NOT for ordinary CLI operation of an existing rig (use openrig-user). Covers the full authoring lifecycle from user intent to validated, launchable rig.
openrig-cmux>
openrig-herdr>