plan-review

Name: plan-review
Author: mvschwarz

56stars9forks

How to install plan-review?

mvschwarz/openrig/plan-review

$npx -y skills add mvschwarz/openrig --skill plan-review

Installs into the current project.

Summary

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.

Files · 1

View on GitHub

SKILL.md

1	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.
2
3	## Three Review Lenses
4
5	### 1. Strategy Review (CEO/Product Leader Lens)
6
7	- Does this align with company growth objectives?
8	- Which personas does this serve? Are they buyers, users, or influencers?
9	- How does this compare to what competitors offer?
10	- Is the scope right? Too ambitious or too focused?
11	- What's the opportunity cost — what are we NOT building by doing this?
12
13	### 2. Design Review (UX/Interaction Lens)
14
15	Rate these dimensions (0-10):
16	1. Information architecture — discoverable and logically organized?
17	2. Interaction states — empty, loading, error, success, edge cases covered?
18	3. User journey — matches how the persona actually works?
19	4. Consistency — follows existing UI patterns?
20	5. Accessibility — keyboard nav, screen readers, color contrast?
21	6. AI integration — if AI-powered, is it natural and trustworthy?
22
23	### 3. Engineering Feasibility (Technical Lens)
24
25	- Are acceptance criteria specific enough that a dev won't need to guess?
26	- Are there data model implications needing early discussion?
27	- Are there dependencies on other features or systems?
28	- Are there performance/scale considerations?
29	- Is the scope realistic for the implied timeline?
30
31	## Process
32
33	### Step 1: Read the Material
34	Read all available docs in the feature folder:
35	- validation.md — office hours verdict, demand evidence, wedge scope (if exists)
36	- background.md — customer drivers, competitive context (if exists)
37	- requirements.md — the main document to review
38	- supporting/ — mockups, data files, visual references
39
40	### Step 2: Run All Three Reviews
41
42	### Step 3: Synthesis
43
44	```markdown
45	## Plan Review: [Feature Name]
46
47	Date: [date]
48	Reviewed: [requirements.md path]
49
50	### Strategy Assessment
51	Score: [1-10]
52	- [Key findings]
53
54	### Design Assessment
55	Score: [1-10]
56	\| Dimension \| Score \| Notes \|
57	\|-----------\|-------\|-------\|
58	\| Information Architecture \| X/10 \| [notes] \|
59	\| Interaction States \| X/10 \| [notes] \|
60	\| User Journey \| X/10 \| [notes] \|
61	\| Consistency \| X/10 \| [notes] \|
62	\| Accessibility \| X/10 \| [notes] \|
63	\| AI Integration \| X/10 \| [notes] \|
64
65	### Engineering Feasibility
66	Score: [1-10]
67	- [Key findings]
68
69	### Issues Found
70
71	#### Blocking (must fix before dev)
72	1. [Issue with specific reference to requirement]
73
74	#### Important (should fix, but not blocking)
75	1. [Issue]
76
77	#### Suggestions (nice to have)
78	1. [Suggestion]
79
80	### Recommended Actions
81	- [Specific actions before proceeding to development]
82	```
83
84	### Step 4: Generate Executive Summary
85
86	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`.
87
88	## Guidelines
89
90	- Be specific. Cite exact requirements that have issues.
91	- Reference real context. Check personas, competitors, and existing features.
92	- Don't do the dev's job. The engineering lens is about PM-side clarity, not architecture.
93	- Praise what's good. Helps the PM know what to keep doing.

People who liked this also viewed

6 picks

Type

plan-review

56stars9forks

View on GitHub

How to install plan-review?

mvschwarz/openrig/plan-review

$npx -y skills add mvschwarz/openrig --skill plan-review

Installs into the current project.

Summary

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.

Files · 1

View on GitHub

SKILL.md

1	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.
2
3	## Three Review Lenses
4
5	### 1. Strategy Review (CEO/Product Leader Lens)
6
7	- Does this align with company growth objectives?
8	- Which personas does this serve? Are they buyers, users, or influencers?
9	- How does this compare to what competitors offer?
10	- Is the scope right? Too ambitious or too focused?
11	- What's the opportunity cost — what are we NOT building by doing this?
12
13	### 2. Design Review (UX/Interaction Lens)
14
15	Rate these dimensions (0-10):
16	1. Information architecture — discoverable and logically organized?
17	2. Interaction states — empty, loading, error, success, edge cases covered?
18	3. User journey — matches how the persona actually works?
19	4. Consistency — follows existing UI patterns?
20	5. Accessibility — keyboard nav, screen readers, color contrast?
21	6. AI integration — if AI-powered, is it natural and trustworthy?
22
23	### 3. Engineering Feasibility (Technical Lens)
24
25	- Are acceptance criteria specific enough that a dev won't need to guess?
26	- Are there data model implications needing early discussion?
27	- Are there dependencies on other features or systems?
28	- Are there performance/scale considerations?
29	- Is the scope realistic for the implied timeline?
30
31	## Process
32
33	### Step 1: Read the Material
34	Read all available docs in the feature folder:
35	- validation.md — office hours verdict, demand evidence, wedge scope (if exists)
36	- background.md — customer drivers, competitive context (if exists)
37	- requirements.md — the main document to review
38	- supporting/ — mockups, data files, visual references
39
40	### Step 2: Run All Three Reviews
41
42	### Step 3: Synthesis
43
44	```markdown
45	## Plan Review: [Feature Name]
46
47	Date: [date]
48	Reviewed: [requirements.md path]
49
50	### Strategy Assessment
51	Score: [1-10]
52	- [Key findings]
53
54	### Design Assessment
55	Score: [1-10]
56	\| Dimension \| Score \| Notes \|
57	\|-----------\|-------\|-------\|
58	\| Information Architecture \| X/10 \| [notes] \|
59	\| Interaction States \| X/10 \| [notes] \|
60	\| User Journey \| X/10 \| [notes] \|
61	\| Consistency \| X/10 \| [notes] \|
62	\| Accessibility \| X/10 \| [notes] \|
63	\| AI Integration \| X/10 \| [notes] \|
64
65	### Engineering Feasibility
66	Score: [1-10]
67	- [Key findings]
68
69	### Issues Found
70
71	#### Blocking (must fix before dev)
72	1. [Issue with specific reference to requirement]
73
74	#### Important (should fix, but not blocking)
75	1. [Issue]
76
77	#### Suggestions (nice to have)
78	1. [Suggestion]
79
80	### Recommended Actions
81	- [Specific actions before proceeding to development]
82	```
83
84	### Step 4: Generate Executive Summary
85
86	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`.
87
88	## Guidelines
89
90	- Be specific. Cite exact requirements that have issues.
91	- Reference real context. Check personas, competitors, and existing features.
92	- Don't do the dev's job. The engineering lens is about PM-side clarity, not architecture.
93	- Praise what's good. Helps the PM know what to keep doing.

People who liked this also viewed

6 picks

Type