/brainstorm

name: brainstorm
description: "Explore ambiguous or early-stage ideas interactively — tracks wish-readiness and crystallizes into a design for wish."

brainstorm — Explore Before Planning

**Runtime syntax:** in Codex, invoke the plugin copy with the owner-qualified `$genie:<skill>` selector; use bare `$<skill>` only when intentionally selecting a user-tier copy (a separately installed personal copy; Genie no longer seeds this tier). Claude Code and Hermes use `/<skill>`. Cross-skill prose below uses bare names as portable semantic routes; the orchestrator resolves the selector for the active tier.

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`

All artifacts live in `.genie/` within the shared worktree. When spawned as a native subagent, the dispatcher curates seed context (file path + extracted section) into your prompt — use it directly; do not re-read what was already provided.

Flow

1. **Read context:** scan relevant code, docs, conventions. Check the canonical `.genie/INDEX.md` for an existing entry matching this slug/topic — seed from it if found. If a legacy flat brainstorm jar (the pre-`INDEX.md` single-file index some repos still carry under `.genie/`) exists, migrate it first (see Index). 2. **Init persistence:** create `.genie/brainstorms/<slug>/DRAFT.md` immediately; create `.genie/INDEX.md` if missing (see Index). 3. **Scope-size check:** if the request spans multiple independent subsystems, decompose before refining (see Scope Size). 4. **Refine:** fill WRS dimensions. Ask only what an unfilled dimension needs — when the request or context already settles a dimension, mark it filled and move on; never re-litigate decisions the user already made. Prefer concrete options over open questions. 5. **Show the WRS bar** after every exchange; persist DRAFT.md whenever WRS changes. 6. **Pass the Simplicity Gate:** establish the simplest complete approach before considering more machinery. Reject speculative complexity or defer it behind a measurable trigger (see Simplicity Gate). 7. **Propose approaches:** 2-3 options with trade-offs, applying Design for Isolation. Recommend one and proceed when the choice follows from the request. 8. **Crystallize** when WRS = 100 (see Crystallize).

WRS — Wish Readiness Score

Five dimensions, 20 points each:

| Dimension | Filled when… | |-----------|-------------| | **Problem** | One-sentence problem statement is clear | | **Scope** | IN and OUT boundaries defined | | **Decisions** | Key technical/design choices made with rationale and the Simplicity Gate passes | | **Risks** | Assumptions, constraints, failure modes identified | | **Criteria** | At least one testable acceptance criterion exists |

WRS: ██████░░░░ 60/100
 Problem ✅ | Scope ✅ | Decisions ✅ | Risks ░ | Criteria ░

✅ = enough info to write that section of a wish; ░ = still needs discussion. Below 100: keep refining. At 100: auto-crystallize. If **Decisions** won't fill, convene domain experts (see Stuck Decisions).

Stuck Decisions

If **Decisions** stays unfilled after 2+ exchanges, convene **domain experts**: dispatch 2-3 lens subagents in parallel (native delegation surface), each reading a distinct deliberation card from `references/lenses/` relative to the directory containing this loaded `SKILL.md`. When the tradeoff is technical, also read the matching sibling lane skill (`../<lane>/SKILL.md`, resolved from this skill directory) when present. Present their perspectives to the user, then keep refining. Escalate to the full `council` workflow when the decision deserves a durable deliberation record.

Scope Size

Multi-subsystem requests waste refinement — assumptions for subsystem A rarely hold for B. Signs: 3+ unrelated modules, infrastructure + application layers together, UI + API + data model with no shared interface, parts that could ship or be staffed independently. When detected: stop refining, tell the user the request spans independent subsystems, decompose into sub-projects (purpose, rough scope, dependencies for each), and start a fresh brainstorm for the first one.

Design for Isolation

Apply to proposed approaches and the DESIGN.md Approach section:

• Single purpose per unit — describable in one sentence.
• Explicit interfaces and dependencies — contracts, not shared mutable state or hidden coupling.
• Independent testability — each unit understandable without loading the whole system.
• File size is a complexity signal — propose splits before a unit becomes unmanageable.

Simplicity Gate

Before recommending an approach or declaring **Decisions** filled:

1. State the simplest complete design that satisfies the current user stories. 2. For every added cache, delta, shard, queue, retry state machine, abstraction, or configuration option, name the present requirement or measurement that pays for it. 3. Count the new durable states, recovery paths, and cross-component invariants each option introduces; treat them as product cost, not implementation detail. 4. Prefer bounding current data, separating history behind pagination, recomputing, replacement, and opinionated defaults before synchronization or configurability. 5. Put plausible future machinery under a measurable adoption trigger instead of building it now. “This may scale later” is not evidence.

If the more complex approach lacks present evidence, recommend the simpler one. Do not split the difference by shipping dormant machinery: unused branches still impose protocol, test, security, and maintenance cost.

Index

The single brainstorm/planning index is `.genie/INDEX.md`; auto-create it if missing with sections:

# Plans Index
## Raw
## Simmering
## Ready
## Poured

Legacy migration is idempotent: if a repo still carries the pre-`INDEX.md` flat brainstorm jar under