claude-code-ultimate-guide/examples/commands/plan-ceo-review.md
Florian BRUNIAUX 1728b6de39 docs: add Cognitive Mode Switching workflow + gstack integration (v3.34.9)
- guide/workflows/gstack-workflow.md (new): Cognitive Mode Switching
  pattern — 6 gears table, pre-implementation strategic gate concept,
  /browse non-MCP native Chromium daemon architecture (~100ms/cmd),
  full ship cycle demo. Reference impl: gstack by Garry Tan (YC CEO).
- examples/commands/plan-ceo-review.md (new): strategic product gate
  template with 3 modes (SCOPE EXPANSION / HOLD SCOPE / REDUCTION)
- examples/commands/plan-eng-review.md (new): engineering architecture
  gate template with Mermaid diagrams, failure modes, test matrix
- guide/workflows/README.md: add entry + 2 Quick Selection Guide rows
- guide/ecosystem/third-party-tools.md: gstack in Plugin Ecosystem
- machine-readable/reference.yaml: v3.34.9, 11 new gstack entries

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
2026-03-13 10:34:51 +01:00

137 lines
4.9 KiB
Markdown

---
name: plan-ceo-review
description: Strategic product gate — challenge the brief, find the 10-star product hiding inside the request, before writing any code
version: 1.0.0
inspired-by: https://github.com/garrytan/gstack
---
# /plan-ceo-review — Strategic Product Gate
Pre-implementation command. Inserts an explicit gate between "I have a request" and "I start coding". Challenges the literal request and asks what the real product should be.
**Use in plan mode, before any implementation.**
---
## The Problem This Solves
Claude Code is optimized to build what you ask. If you say "add X", it builds X. It will not ask whether X is actually the right product. This command corrects that by explicitly switching into product-thinking mode before the implementation instinct kicks in.
---
## When to Use
- Before implementing any significant feature request
- Especially when the request is specific ("add photo upload") — specificity often signals the requester has already collapsed the solution space
- When you want to pressure-test a direction before committing engineering time
---
## Three Modes
The command asks the user to choose one before proceeding:
| Mode | Posture | Use when |
|------|---------|----------|
| **SCOPE EXPANSION** | Find the 10-star product, push scope up | Direction is fuzzy, want to dream |
| **HOLD SCOPE** | Accept direction, make the plan bulletproof | Direction is locked, want rigor |
| **SCOPE REDUCTION** | Strip to minimum viable, cut ruthlessly | Overloaded backlog, need to ship fast |
The assistant commits to the selected mode and does not drift mid-review.
---
## Prompt Template
```markdown
# /plan-ceo-review
You are in CEO / founder review mode. Your job is NOT to implement anything.
Your job is to review the plan or feature request with product-level thinking
and return a better brief.
## Step 0: Choose Mode
Ask the user which mode to use (if not specified):
- SCOPE EXPANSION: Find the 10-star product. Push scope up. What's the version
that feels inevitable and delightful?
- HOLD SCOPE: Accept the direction. Make this plan bulletproof. Catch every
failure mode and unstated assumption.
- SCOPE REDUCTION: Find the minimum viable version that achieves the core
outcome. Cut everything else.
Once the user selects, commit to that mode for the entire review.
## Step 1: Restate the Request
Summarize the literal request in 1-2 sentences. Be precise — not editorialized.
## Step 2: Challenge the Premise
Ask the more important question: what is this product actually FOR?
- What is the user's real job-to-be-done?
- Is the literal request the best way to solve it?
- What assumption is the request making that might be wrong?
## Step 3: The Real Product (EXPANSION) / Bulletproof Plan (HOLD) / MVP (REDUCTION)
**SCOPE EXPANSION**: Describe the 10-star version of this product.
- What would make this 10x better for 2x the effort?
- What do users actually want, not what they asked for?
- List 5-8 specific features or design decisions that would make this feel
inevitable.
**HOLD SCOPE**: Accept the direction. Now find everything that can go wrong.
- Unstated assumptions in the request
- Edge cases that are not covered
- Missing error states
- UX gaps
- Security or trust boundary issues
- Operational concerns (monitoring, rollback, data migration)
**SCOPE REDUCTION**: What is the smallest version that proves the core value?
- What is the one thing this must do?
- What can be cut without losing the point?
- What can be deferred to v2?
## Step 4: Recommendation
Return one of:
- **Proceed as stated** — the original request is the right product
- **Reframe** — here is the better brief (with specifics)
- **Reject** — here is why this is the wrong direction, and what to build instead
Do NOT make any code changes. This is a review, not an implementation.
```
---
## Example
**Input**: "Let sellers upload a photo for their listing"
**Output (SCOPE EXPANSION)**:
> "Photo upload" is not the feature. The real job is helping sellers create listings that actually sell.
>
> Here's the 10-star version: auto-identify the product from the photo, pull SKU and specs from the web, draft a title and description automatically, suggest which uploaded photo converts best as the hero image, detect low-quality photos (dark, cluttered, low-trust) before they go live.
>
> **Recommendation**: Reframe. The brief should be "smart listing creation from photo" not "photo upload".
---
## Integration with Other Commands
```
/plan-ceo-review → lock product direction
/plan-eng-review → lock technical architecture
[implement]
/review → paranoid pre-merge check
/ship → release
```
## See Also
- [Cognitive Mode Switching](../../guide/workflows/gstack-workflow.md) — full workflow context
- [plan-eng-review](./plan-eng-review.md) — next step after direction is locked
- [plan-start](./plan-start.md) — native plan mode command