Step 0: Scope Challenge

Run BEFORE research or design. Forces intent clarification before investing time.

Inspired by: gstack /plan-eng-review Step 0 + /plan-ceo-review scope modes.

Skip Conditions

Skip Step 0 when:

--fast mode explicitly set (user already wants minimal)
Task is clearly trivial (single file fix, typo, config change)
User says "just plan it", "quick", or similar urgency signal
Task description is under 20 words and unambiguous

The 3 Questions

Before planning, answer these concisely:

1. What already exists?

Scan codebase for code that partially/fully solves sub-problems
Check existing utilities, services, patterns that can be reused
Flag if plan would rebuild something that exists

2. What is the minimum change set?

Identify work that could be deferred without blocking core goal
Flag scope creep: nice-to-haves disguised as requirements
Be ruthless about what's truly necessary vs aspirational

3. Complexity check

If plan would touch >8 files: challenge whether same goal achievable with fewer
If plan would introduce >2 new classes/services: smell — justify each
If plan would have >3 phases: consider if phases can be merged

Scope Modes

After answering the 3 questions, present via AskUserQuestion:

Header: "Scope Challenge" Question: "Based on analysis, how should we scope this plan?"

Option	Label	Description
A	SCOPE EXPANSION	Dream big — explore the 10-star version, research deeply, add delight features
B	HOLD SCOPE	Scope is right — focus on bulletproof execution, edge cases, test coverage
C	SCOPE REDUCTION	Strip to essentials — defer everything non-blocking, minimal phases

After Selection

EXPANSION selected

Suggest --hard or --two mode if not already set
Research phase should explore alternatives and adjacent features
Plan should include "stretch" items clearly labeled
More phases are acceptable

HOLD selected

Proceed with auto-detected mode
Respect scope exactly — no silent reduction or expansion
Focus on failure modes, edge cases, test coverage
Standard number of phases

REDUCTION selected

Suggest --fast mode if not already set
Propose minimal version that achieves core goal
Defer everything non-critical to "NOT in scope" section
Fewer phases, simpler architecture

Critical Rule

Once user selects a mode, RESPECT IT.

Do not:

Silently reduce scope when user chose HOLD or EXPANSION
Silently expand scope when user chose REDUCTION
Re-argue for different scope in later review sections

Raise scope concerns ONCE in Step 0. After that, commit to chosen scope and optimize within it.

Output Format

After scope challenge, output brief summary before proceeding:

Scope Challenge:
- Existing code: [what was found that's reusable]
- Minimum changes: [what's essential vs deferrable]
- Complexity: [estimated files, new abstractions]
- Selected mode: [EXPANSION/HOLD/REDUCTION]

Then proceed to mode detection and research phase.

3.1 KiB Raw Permalink Blame History