plugins/v1tamins/skills/v1-strategy-review/SKILL.md
Use when reviewing a plan, PRD, product direction, or implementation proposal for strategy, scope, user value, ambition, and hidden assumptions. Triggers on "strategy review", "CEO review", "founder review", "think bigger", "rethink this", "is this ambitious enough".
npx skillsauth add v1-io/v1tamins v1-strategy-reviewInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
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.
Read the plan, PRD, ticket, or proposal. Then inspect nearby context:
docs/, README.md, CLAUDE.md, or AGENTS.mdDo not review from the title alone.
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.
Answer these before detailed review:
If the plan lacks demand evidence, say so. Interest, taste, or internal excitement is not demand.
Produce at least two implementation or product approaches:
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.
Evaluate the plan across these dimensions:
For each material issue, include what would change your mind.
Only for expand or selective expansion posture, look for:
Separate expansion candidates into:
Ask before adding any recommended expansion to the plan.
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:
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.
tools
Use when planning or synthesizing user tests for prototypes, mockups, clickable demos, product concepts, design flows, landing pages, or early product specs. Triggers on "test this prototype", "prototype testing", "user test plan", "validate this product idea", "test with users".
development
Use when creating a polished self-contained HTML page would help the user understand, compare, review, present, tune, or interact with information better than Markdown. Triggers on "make an HTML page", "HTML artifact", "nice HTML", "visual report", "interactive explainer", "one-page dashboard", "shareable page".
data-ai
Use when turning a textbook, PDF, blog post, article, paper, course, notes, transcript, or other source material into suggested agent skills or skill improvements. Triggers on "what skills could come from this", "extract skills from", "turn this into skills", "skill ideas from this source".
development
Run an extremely strict maintainability review for abstraction quality, giant files, and spaghetti-condition growth. Use for large prs, new features/architectures, a deep code quality audit, or especially harsh maintainability review.