ideation-first

# 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. 1. **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). 2. **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). 3. **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. 4. **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. |