Ideation First

---
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.

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. |