/brainstorm — Explore Before Planning
Collaborate on fuzzy ideas until they are concrete enough for/wish.
When to Use
- User has an idea but unclear scope or approach
- Requirements are ambiguous and need interactive refinement
- User explicitly invokes
/brainstorm
Flow
- Read context — scan current code, docs, conventions. Check
.genie/brainstorm.mdfor an existing entry matching the topic. - Init persistence — create
.genie/brainstorms/<slug>/DRAFT.mdimmediately. - Clarify intent — one question at a time, prefer multiple-choice.
- Show WRS bar after every exchange.
- Persist draft when WRS changes or every 2 minutes.
- Propose approaches — 2–3 options with trade-offs. Recommend one.
- Crystallize when WRS = 100 — write
DESIGN.md, update jar, hand off.
Wish Readiness Score (WRS)
Five dimensions, 20 points each. Displayed after every exchange.| Dimension | Filled when… |
|---|---|
| Problem | One-sentence problem statement is clear |
| Scope | IN and OUT boundaries defined |
| Decisions | Key technical/design choices made with rationale |
| Risks | Assumptions, constraints, failure modes identified |
| Criteria | At least one testable acceptance criterion exists |
Brainstorm Jar
An index at.genie/brainstorm.md tracks all topics across sessions with four sections:
| Section | Purpose |
|---|---|
| Raw | New ideas, just captured |
| Simmering | Under active discussion |
| Ready | WRS = 100, ready to crystallize |
| Poured | Crystallized into a wish |
Crystallize
Triggered automatically when WRS = 100:- Write
.genie/brainstorms/<slug>/DESIGN.mdfrom the draft. - Move entry to Poured in the jar with a wish link.
- Auto-invoke
/review(plan review) on the design.
Output Options
| Complexity | Output |
|---|---|
| Standard | Write DESIGN.md, auto-invoke /review |
| Small but non-trivial | Write design, ask whether to implement directly |
| Trivial | Add one-liner to jar (Raw section) |
Handoff
After/review returns SHIP on the design:
Rules
- One question per message — never batch questions
- YAGNI and simplicity first
- Always propose alternatives before recommending
- Never assume requirements without confirmation
- No implementation during brainstorm
- Persist early and often