init

.opencode/skills/ck-plan/references/scope-challenge.md

@@ -0,0 +1,90 @@
+# 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.