| name | brainstorming |
| description | Design/spec a new feature, component, or behavior change before any code. Triggers: "how should we…", "what's the best way", "let's build/add/create", "design", "plan", "spec". Outputs an approved spec → hands off to worker. |
Brainstorming
Turn a fuzzy idea into an approved spec through dialogue. Do not write code or load worker until the user approves a written spec. Short specs fine — one must exist.
Flow
- Scout in parallel. Identify gaps (code, docs, APIs, constraints). Dispatch independent
explore agents in one turn. Skip when the question is self-contained or a direct read/grep answers it.
- Ask what scouting couldn't answer — one focused question at a time. Use
ask_user_question when choices are concrete.
- Decompose if the request spans subsystems → separate specs.
- Run the lazy pass: does this need to exist, already exist here, or fit stdlib/native/installed tools? Prefer the smallest viable spec.
- Propose 2–3 approaches with tradeoffs and your pick.
- Present the design clearly. Include what is explicitly not being built and when to add it later.
- Write the spec at a path the user agrees on.
- Self-review for placeholders, contradictions, scope drift. Fix inline.
- Wait for explicit approval, then hand off to
worker.
Principles
- YAGNI. Drop features that don't earn their keep.
- Smaller units with clear interfaces.
- Follow existing codebase patterns.
