| name | idea-refine |
| description | Pre-spec idea refinement through structured divergent and convergent thinking. Use when a task is too vague for /define — needs exploration before spec generation. Triggers: "ideate", "brainstorm", "refine idea".
|
Idea Refine
Refine raw ideas into sharp, actionable concepts before writing a spec.
When to Use
- "I have an idea but not a task"
- Exploring feasibility of an approach
- Comparing multiple directions before committing
- Pre-spec brainstorming for complex features
- Stakeholder said something vague — need to sharpen it
When NOT to Use
- Requirements already clear (go straight to
/define)
- Implementation work (use builder)
- Code review or testing (use reviewer/tester)
- Single, well-defined bug fix
Core Process
Phase 1: Understand & Expand (Divergent)
Goal: Open up the solution space.
- Restate as "How Might We" — transform the idea into a problem statement. "Make it faster" becomes "How might we reduce p99 latency below 50ms for the payment flow?"
- Ask sharpening questions (3-5 max):
- Who is this for, specifically?
- What does success look like?
- What are the real constraints?
- What's been tried before?
- Why now?
- Generate 5-8 variations using these lenses:
- Inversion: what if we did the opposite?
- Constraint removal: what if time/tech weren't factors?
- Simplification: what's the 10x simpler version?
- Combination: merge with an adjacent idea?
- Audience shift: what if this were for a different user?
If inside a codebase: scan for existing patterns, prior art, architectural constraints. Ground variations in reality.
Phase 2: Evaluate & Converge
- Cluster resonating ideas into 2-3 distinct directions
- Stress-test each against:
- User value: painkiller or vitamin?
- Feasibility: what's the hardest part?
- Differentiation: what makes this genuinely different?
- Surface hidden assumptions — for each direction:
- What must be true (dealbreaker if wrong)?
- What could kill this idea?
- What are we choosing to ignore (and why that's ok for now)?
Be honest, not supportive. Weak ideas get called out with specificity and kindness.
Phase 3: Sharpen & Ship
Produce a concrete artifact — a task statement ready for /define:
## [Idea Name]
**Problem:** [one-sentence "How Might We" framing]
**Direction:** [chosen approach and why — 2-3 sentences max]
**Assumptions to Validate:**
- [ ] [Assumption 1 — how to test it]
- [ ] [Assumption 2 — how to test it]
**MVP Scope:** [minimum version that tests the core assumption]
**Not Doing (and Why):**
- [Thing 1] — [reason]
- [Thing 2] — [reason]
**Open Questions:**
- [Anything unresolved before building]
When complete, suggest running /define to generate a structured spec.
The "Not Doing" List
The most valuable part of ideation. Focus is about saying no to good ideas.
- Forces explicit trade-offs instead of implicit scope creep
- Prevents "while we're at it" additions
- Creates a reference for future scope discussions
- Every item needs a reason — "not now" is not a reason
Common Rationalizations
| Shortcut | Reality |
|---|
| "The idea is obvious, skip to building" | Obvious ideas have hidden assumptions. 5 minutes refining saves 5 hours building the wrong thing. |
| "We need more research first" | Research without a frame is procrastination. Start with what you know, surface what you don't. |
| "Let's just try it and see" | Trying without criteria for success means you can't tell if it worked. Define success first. |
| "We need to consider all options" | 5-8 considered variations beat 20 shallow ones. Depth over breadth. |
Red Flags
- Jumping straight to solution without framing the problem
- No assumptions surfaced before committing to a direction
- More than 8 variations generated (breadth without depth)
- Skipping "who is this for" — every idea starts with a person and their problem
- No "Not Doing" list — means scope isn't bounded
- Yes-machining weak ideas instead of pushing back
- Ignoring existing codebase constraints when ideating inside a project
Verification
