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

4.9 KiB

name description version inspired-by
plan-ceo-review Strategic product gate — challenge the brief, find the 10-star product hiding inside the request, before writing any code 1.0.0 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

# /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