| name | ideation-first |
| description | Use before planning a new feature or greenfield refactor whose requirements aren't yet pinned down — clarifies intent through a few questions and ends with a short scope brief the planner can build on. |
Ideation First
Overview
Planning against guessed requirements wastes work. The planner turns a request into ordered steps —
but if the request itself is vague, every step is built on a guess, and the further the pipeline
runs, the more expensive that guess is to unwind. This skill settles the what before anyone plans
the how.
Core principle: clarify the what before planning the how.
When this applies
A request for a new capability, feature, or greenfield refactor whose requirements aren't pinned
down — the goal, the boundaries, or the success criteria are open to interpretation. Signals:
"build a … screen", "add … support", "let users …", "we need something that …" with no spec.
When to skip
- Well-specified requests — the goal, inputs, and done-condition are already unambiguous. Don't
interrogate when the ask is clear; go straight to planning.
quick one-liners — typo fixes, obvious small edits. Ideation is overhead here.bugfix — bugs get root-cause investigation first via the debugger, not requirements
clarification. The "what" is already defined (make the broken thing work).
If you find yourself asking questions whose answers you already have, stop — you're past the point
this skill is for.
The process
Keep it lightweight. The value is a locked scope, not ceremony.
- Ask 3–5 clarifying questions, one at a time. One question per turn — each answer informs the
next. Cover purpose (what problem does this solve, for whom), constraints (what must it
fit within — existing patterns, platforms, non-negotiables), and success criteria (how do we
know it's done and right).
- Prefer the minimal interpretation. When the request is open-ended, propose the smallest thing
that satisfies it and confirm — don't quietly scope in an ambitious version. This is
smallest-change-first applied to requirements: don't build features nobody asked for (YAGNI).
- Propose 2–3 approaches when there's a real design fork, each with its trade-off and your
recommendation. Lead with the one you'd pick and say why.
- Confirm, then write the scope brief. Once the user agrees, produce the brief below — it
becomes the planner's input.
The scope brief
End by producing this block. It is the hand-off to the planner; keep it compact.
**Scope brief**
- Goal: <one sentence>
- In scope: <bullets>
- Out of scope: <bullets — the explicit "not doing" list>
- Key decisions: <choices made during ideation + why>
- Open questions: <anything still unresolved, or "none">
When routing through @orchestrator, pass this brief in the invocation so the planner receives it —
a cold subagent can't see the conversation it wasn't part of.
Red flags
| Thought | Reality |
|---|
| "I get the gist, I'll just start coding" | A gist is not an agreed scope. Confirm the what first. |
| "I'll ask all my questions at once" | One at a time — each answer changes what you'd ask next. |
| "The request was vague, so I'll pick something ambitious" | Pick the minimal interpretation and confirm it. Scope creep starts here. |
| "This feature is obviously simple, skip the brief" | Simple-looking features are where unexamined assumptions cost the most. The brief can be three lines, but write it. |
| "The out-of-scope list is empty" | If nothing is out of scope, you haven't bounded anything. Name what you're deliberately not doing. |
