91 lines
3.1 KiB
Markdown
91 lines
3.1 KiB
Markdown
# 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.
|