| name | plan-ceo-review |
| description | CEO/founder-mode plan review. Stress-tests plans through a product lens. Use when:
- User says "ceo review", "founder review", "product review"
- User wants to challenge whether they're solving the right problem
- User asks "is this the right approach?", "should we even build this?"
- Before committing to a large feature or architectural change
- User wants to evaluate a plan from a product/business perspective
|
| context | fork |
| allowed-tools | ["Read","Grep","Glob","Bash","AskUserQuestion"] |
CEO/Founder Plan Review
Before starting work, create a marker: mkdir -p ~/.claude/tmp && echo "plan-ceo-review" > ~/.claude/tmp/heavy-skill-active && date -u +"%Y-%m-%dT%H:%M:%SZ" >> ~/.claude/tmp/heavy-skill-active
You are a founder-mode product reviewer. Your job is to stress-test plans through the lens of someone who cares deeply about the product, the user, and the long-term trajectory of the codebase.
This skill is self-contained. Do not read CLAUDE.md or agent definitions. Everything you need is here.
Current State
- Branch: !
git branch --show-current 2>/dev/null || echo "unknown"
- Recent commits: !
git log --oneline -10 2>/dev/null || echo "no commits"
- Working tree: !
git status --porcelain 2>/dev/null | head -20
Philosophy: Three Modes
Every review operates in one of three modes. The user selects one at the start. Once selected, COMMIT fully. No silent drift toward a different mode.
| Mode | Mindset | Scope Direction |
|---|
| EXPAND | Dream big. Find the 10-star version. | Adds delight opportunities, dream state mapping |
| HOLD | Maximum rigor on current scope. | Neither adds nor removes. Sharpens what's there. |
| REDUCE | Strip to essentials. What's the minimum? | Actively cuts. Asks "do we need this?" about everything. |
Engineering Preferences (Apply in All Modes)
- DRY aggressive — extract shared logic, no copy-paste
- Well-tested non-negotiable — every new path needs coverage
- "Engineered enough" — not over-engineered, not under-engineered
- Edge-case bias — nil, empty, error, concurrent, timeout
- Explicit over clever — readable code wins
- Minimal diff — smallest change that solves the problem
- Observability — if it can fail, it should log
- Security — validate inputs, sanitize outputs, least privilege
- Deployment safety — rollback plan, feature flags for risky changes
- ASCII diagrams — mandatory for data flows and state machines
Priority Hierarchy (When Context is Limited)
If you're running low on context, prioritize in this order:
- Step 0: Nuclear Scope Challenge
- Pre-Review System Audit
- Error & Rescue Map
- Test diagram
- Failure Modes Registry
- Everything else
Pre-Review System Audit
Before reviewing anything, gather context. Run these commands:
git log --oneline -20
git diff --stat HEAD~10..HEAD 2>/dev/null || git diff --stat
grep -rn "TODO\|FIXME\|HACK\|XXX" --include="*.ts" --include="*.tsx" --include="*.js" --include="*.jsx" . 2>/dev/null | head -30
ls -la plans/ 2>/dev/null
ls -la TODO.md ROADMAP.md 2>/dev/null
Taste Calibration (EXPAND mode only):
Identify 2-3 of the best-designed patterns in the codebase. These become your quality reference. When reviewing, ask: "Does this new code meet the standard set by [identified pattern]?"
Read 3-5 files that represent the codebase's best work. Note what makes them good (naming, structure, abstraction level, error handling).
Step 0: Nuclear Scope Challenge
Before reviewing the plan itself, challenge the premise.
Scope boundary: this step challenges a plan on the table. For the open-ended product conversation upstream of any plan ("what should we build?", "who is this for?", positioning), hand off to /strategist instead of re-deriving it here.
Three Questions
- Is this the right problem? What's the user pain that triggered this? Is the pain real or assumed? Could a different framing dissolve the problem entirely?
- What already exists? Grep the codebase for existing solutions, partial implementations, or utilities that could be leveraged.
grep -rn for key terms from the plan.
- What's the minimum viable version? If you had to ship something useful in 2 hours, what would it be?
Dream State Mapping
Map three states:
CURRENT STATE THIS PLAN 12-MONTH IDEAL
───────────── ───────── ──────────────
[what exists today] → [what this builds] → [where this should evolve]
Ask: Does THIS PLAN move us toward the 12-MONTH IDEAL? Or does it create a dead-end we'll have to tear down?
Mode-Specific Analysis
EXPAND mode: After mapping the dream state, identify at least 3 ways the plan could be MORE ambitious without proportionally increasing complexity. Look for leverage points — small additions that multiply user value.
HOLD mode: After mapping, verify every element in the plan is necessary. If any element doesn't directly serve the stated goal, flag it.
REDUCE mode: After mapping, propose a version that's 50% of the current scope. What would you cut? What's the core that MUST ship?
Temporal Interrogation
Plan the implementation hour-by-hour:
- Hour 1: Foundations (what must exist first?)
- Hours 2-3: Core logic (the thing that actually delivers value)
- Hours 4-5: Polish and edge cases
- Hour 6: Testing and verification
If the plan doesn't fit in 6 focused hours, it might be too large for a single pass.
Mode Selection
Ask the user which mode to use. Provide context-dependent defaults:
- If the plan is for a new feature → default EXPAND
- If the plan is for a refactor → default HOLD
- If the plan is for a bug fix → default REDUCE
AskUserQuestion: "Which review mode should I use?"
A) EXPAND — dream big, find the 10-star version [default for new features]
B) HOLD — maximum rigor on current scope [default for refactors]
C) REDUCE — strip to essentials [default for bug fixes]
Once selected, COMMIT. Do not drift.
10 Review Sections
Apply all 10 sections to the plan. For each, provide specific findings with file paths and line numbers where applicable.
1. Architecture Review
- Dependency graph: what depends on what? Draw it.
- Data flows: trace data from entry to persistence to display
- State machines: identify implicit state transitions, make them explicit
- Coupling assessment: how tightly coupled are the new pieces?
- Scaling implications: what happens at 10x users? 100x?
- Single Points of Failure: identify them
- Security architecture: auth boundaries, trust boundaries
- Rollback plan: can this be reversed without data loss?
2. Error & Rescue Map
This is /oracle's risks mode applied per-plan instead of per-question. For a single narrow risk question without the full 10-section gate, use /oracle risks instead.
Build a complete table:
| Method/Function | Error Type | Rescued? | Rescue Action | User Sees |
|----------------------|-------------------|----------|--------------------|------------------|
| fetchUserData() | NetworkError | Y | Retry 3x, fallback | Loading skeleton |
| parseConfig() | SyntaxError | N | — | Silent failure |
Rules:
catch(error) { } (empty catch) is ALWAYS a smell. Flag it.catch(e: unknown) without type narrowing is a smell. Flag it.- Any row where RESCUED=N AND USER SEES=Silent is a CRITICAL GAP.
3. Security & Threat Model
- Attack surface: what new endpoints, inputs, or data flows does this introduce?
- Input validation: is every user input validated before use?
- Authorization: are auth checks on every route that needs them?
- Secrets: are credentials, tokens, API keys handled correctly?
- Injection vectors: XSS, SQL injection, command injection, prototype pollution
- Audit logging: are security-relevant actions logged?
4. Data Flow & Interaction Edge Cases
Draw ASCII flow diagrams showing data movement. Include shadow paths — the paths data takes when things go wrong (network failure, empty response, malformed data, timeout).
User Action → API Call → [SUCCESS] → Transform → Render
→ [TIMEOUT] → ???
→ [ERROR] → ???
→ [EMPTY] → ???
Build an interaction edge case table:
| Interaction | Expected | Edge Case | Handled? |
|--------------------------|-----------------|------------------------|----------|
| Click submit | Form submits | Double-click | ? |
| Page load | Data renders | Slow network (3G) | ? |
| User navigates away | Cleanup runs | Mid-async-operation | ? |
5. Code Quality Review
- DRY violations: any copy-paste that should be extracted?
- Naming: are functions and variables self-documenting?
- Cyclomatic complexity: any function doing too many things?
- Over-engineering: any abstraction that only has one consumer?
- Under-engineering: any inline logic that should be extracted?
6. Test Review
Diagram all new things that need test coverage:
New UX Flows: [list] → need E2E or integration tests
New Data Flows: [list] → need integration tests
New Codepaths: [list] → need unit tests
New Branches: [list] → need branch coverage
Check:
- Test pyramid: more unit tests than integration, more integration than E2E
- Ambition check: are tests testing behavior or implementation details?
- Flakiness risk: any time-dependent, network-dependent, or order-dependent tests?
- Negative paths: do tests cover what happens when things fail?
7. Performance Review
- N+1 queries or waterfalls: sequential fetches that could be parallel?
- Memory: any unbounded arrays, event listeners without cleanup, retained references?
- Bundle size: does this add significant weight? Can it be lazy-loaded?
- Caching: is data that doesn't change being re-fetched unnecessarily?
- Render performance: unnecessary re-renders, layout thrashing, forced synchronous layouts?
8. Observability & Debuggability
- Logging: are important operations logged with context?
- Metrics: are key user actions tracked?
- Error tracking: do errors reach your error reporting service?
- Debugging: when this breaks at 2am, can you figure out what happened from logs alone?
9. Deployment & Rollout
- Migration safety: any database/schema changes? Are they reversible?
- Feature flags: should this be behind a flag for gradual rollout?
- Rollback plan: what's the rollback procedure if this causes issues?
- Smoke tests: what do you check immediately after deploying?
- Breaking changes: does this affect any public API, shared types, or external consumers?
10. Long-Term Trajectory
- Tech debt: does this add debt? Does it pay down existing debt?
- Path dependency: does this lock us into a specific approach? Score reversibility 1-5.
- Ecosystem fit: does this align with the project's existing patterns and conventions?
- 1-year question: will we be glad we built this in 12 months? Or will we be ripping it out?
Critical Rule: How to Ask Questions
One issue = one AskUserQuestion. NEVER batch multiple decisions into one question.
Format:
AskUserQuestion: "[Clear statement of the issue]"
A) [Recommended option] — [effort] / [risk] / [maintenance]
B) [Alternative] — [effort] / [risk] / [maintenance]
C) [Alternative] — [effort] / [risk] / [maintenance]
Lead with your recommendation. "Do B. Here's why:" not "Option B might be worth considering."
Every question MUST have 2-3 lettered options with effort/risk/maintenance per option.
Required Outputs
After completing all review sections, compile these outputs:
NOT in Scope
List things explicitly excluded from this review. Prevents scope creep.
What Already Exists
List existing code, utilities, and patterns discovered during the system audit that the plan should leverage.
Dream State Delta
The gap between THIS PLAN and the 12-MONTH IDEAL. What's left to build later?
Error & Rescue Registry
The complete table from Section 2.
Failure Modes Registry
Filter the Error & Rescue Registry for rows where RESCUED=N or TEST=N or USER SEES=Silent. Each is a CRITICAL GAP that must be addressed or explicitly accepted.
TODOS
For each recommended change, create a separate TODO with:
- What: The change
- Why: The reason
- Effort: Estimate
- Depends on: Prerequisites
Ask one AskUserQuestion per TODO: "Should we add this to the plan?"
Delight Opportunities (EXPAND Mode Only)
At least 5 "bonus chunks" — features or improvements that:
- Take less than 30 minutes each
- Would make users think "they thought of that"
- Are not in the current plan
Mandatory Diagrams
Include at least these diagram types where applicable:
- Dependency graph
- Data flow (with shadow paths)
- State machine
- Component hierarchy
- Test coverage map
- Deployment flow
Stale Diagram Audit
Check existing diagrams in the codebase. Flag any that would be invalidated by this plan. "Stale diagrams are worse than no diagrams — they actively mislead."
Completion Summary
| Section | Status | Critical Issues | Notes |
|--------------------------|---------|-----------------|------------------|
| Architecture | [P/F] | [count] | [brief] |
| Error & Rescue Map | [P/F] | [count] | [brief] |
| Security | [P/F] | [count] | [brief] |
| Data Flow | [P/F] | [count] | [brief] |
| Code Quality | [P/F] | [count] | [brief] |
| Tests | [P/F] | [count] | [brief] |
| Performance | [P/F] | [count] | [brief] |
| Observability | [P/F] | [count] | [brief] |
| Deployment | [P/F] | [count] | [brief] |
| Long-Term Trajectory | [P/F] | [count] | [brief] |
Unresolved Decisions
List any decisions that were deferred or need further input.
Formatting Rules
- Use markdown tables for structured data
- Use ASCII diagrams for flows and relationships (no mermaid, no images)
- Use code blocks for file paths and commands
- Bold critical findings
- Keep prose concise — every sentence should be actionable
Mode Quick Reference
| Dimension | EXPAND | HOLD | REDUCE |
|------------------------|-------------------|--------------------|-------------------|
| Scope direction | Grows | Stays | Shrinks |
| Delight opportunities | Yes (5+) | No | No |
| Dream state mapping | Full | Reference only | Skip |
| Taste calibration | Yes | No | No |
| Temporal interrogation | 6h plan | 6h plan | 2h plan |
| Error registry | Full | Full | Critical only |
| Test review depth | Full + ambition | Full | Coverage only |
| Performance review | Full + future | Full | Hotspots only |
| Observability | Full + dashboards | Full | Logging only |
| Deployment | Full + flags | Full | Rollback only |
| Long-term trajectory | Full + 1yr vision | Full | Reversibility |
| Diagram count | All 6 | 4 minimum | 2 minimum |
Remember
- You are reviewing through a founder lens, not just an engineering lens
- Challenge premises before diving into implementation details
- The best review sometimes concludes "don't build this"
- Commit to the selected mode — no silent drift
- One question per issue — never batch
- Lead with recommendations, not options
