v1-strategy-review

name	v1-strategy-review
description	Use when reviewing a plan, PRD, product direction, or proposal for strategy and assumptions. Triggers on "strategy review", "CEO review", or "is this ambitious enough".
allowed-tools	["Bash","Read","Grep","Glob","Edit","AskUserQuestion"]

Strategy Review

Review a plan like a founder who cares whether the work creates real user value, not just whether it is internally consistent.

Use after v1-interview-me when the idea is still fluid. Use before implementation when the plan already exists but scope, ambition, or user value are questionable.

Workflow

1. Load the Plan and Context

Read the plan, PRD, ticket, or proposal. Then inspect nearby context:

• Related docs in docs/, README.md, CLAUDE.md, or AGENTS.md
• Related code, if the plan proposes implementation work
• Related issues or tickets, if the user provided them

Do not review from the title alone.

2. Choose Scope Posture

Choose one posture and state it clearly:

Posture	Use When
Expand	The idea is directionally right but undershoots the user value
Selective expansion	The baseline is good, but a few adjacent improvements may be worth adding
Hold scope	The scope is right, and the goal is rigor
Reduce	The plan is overbuilt, vague, or solving a proxy problem

If the user gave explicit posture language, follow it. Otherwise default to selective expansion for product features, hold scope for bug fixes and refactors, and reduce for plans that touch many files without clear user impact.

Do not add scope silently. Propose scope changes and get approval before editing a plan to include them.

3. Premise Challenge

Answer these before detailed review:

• Is this the right problem to solve?
• Who is the user, and what painful status quo are they living with now?
• What would happen if we did nothing?
• Is the plan solving the user outcome directly, or solving an internal proxy?
• What existing code, workflow, or artifact already solves part of this?

If the plan lacks demand evidence, say so. Interest, taste, or internal excitement is not demand.

4. Generate Alternatives

Produce at least two implementation or product approaches:

• Minimal viable: fewest moving parts that proves value
• Planned approach: what the doc currently proposes
• Ideal version: the 12-month direction or best product shape, if meaningfully different

For each approach, include effort, risk, reuse of existing code, what it validates, and what it defers.

Recommend one approach. Tie the recommendation to user value, speed to learning, and reversibility.

5. Review Dimensions

Evaluate the plan across these dimensions:

• Demand: evidence that someone needs this now
• Status quo: current workaround and cost
• Wedge: smallest useful version
• Differentiation: why this is not just another version of the obvious thing
• Scope: work that must ship together vs. follow-up
• Complexity: unnecessary files, abstractions, dependencies, or coordination
• Implementation ambiguity: decisions the builder will hit in the first hours of work
• Risk: security, data, reliability, support, rollout, and rollback concerns
• Validation: how success will be observed quickly
• Future fit: whether this gets more valuable as the world changes

For each material issue, include what would change your mind.

6. Expansion Scan

Only for expand or selective expansion posture, look for:

• A 10x version that delivers much more value for modest extra effort
• Small delight or trust improvements that take little engineering time
• Platform moves that make future features easier
• Distribution or adoption hooks that help real users find or use the work

Separate expansion candidates into:

• Recommend adding now
• Defer with notes
• Skip

Ask before adding any recommended expansion to the plan.

7. Edit the Plan When Asked

If the user asks you to update the plan, edit the existing artifact rather than creating a parallel strategy doc.

Preserve the original structure unless it is actively confusing. Add a Strategy Review section only when the plan has no obvious place for the findings.

Record decisions explicitly:

• Accepted scope
• Deferred scope
• Rejected scope
• Open questions
• Recommended next action

8. Output Format

Use this structure:

## Strategy Review

Verdict: [one sentence]
Posture: [Expand / Selective expansion / Hold scope / Reduce]

### Must Fix
- [Issue, why it matters, recommended change]

### Scope Recommendations
- Add now: [...]
- Defer: [...]
- Skip: [...]

### Alternatives
1. [Minimal viable approach]
2. [Current/planned approach]
3. [Ideal approach]

### Open Questions
- [Question, owner if known, why it blocks progress]

### Next Action
[One concrete assignment]

If there are no serious issues, say that clearly, then list residual risks.