Install any skill in seconds. Free to start, no credit card required.
Get Started Free →Explore ambiguous or early-stage ideas interactively — tracks wish-readiness and crystallizes into a design for wish.
.claude/skills/automagik-dev-brainstorm/SKILL.md| Test case | Without → With | Effect | Δ tokens | Δ turns |
|---|---|---|---|---|
| case-07 | ✗→✓ | ▲ Improved | 174% | 0% |
| case-08 | ✗→✓ | ▲ Improved | 79% | 0% |
| case-10 | ✗→✓ | ▲ Improved | 113% | 0% |
| case-12 | ✗→✓ | ▲ Improved | 117% | 0% |
| case-15 | ✗→✓ | ▲ Improved | 15% | 0% |
Runtime syntax: invoke the plugin copy through the active runtime's owner-qualified skill selector; use a bare selector only when intentionally selecting a user-tier copy (a separately installed personal copy; Genie no longer seeds this tier). Cross-skill prose below uses bare names as portable semantic routes; the orchestrator resolves the selector for the active runtime.
Collaborate on fuzzy ideas until they are concrete enough for wish.
brainstormAll 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.
.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)..genie/brainstorms/<slug>/DRAFT.md immediately; create .genie/INDEX.md if missing (see Index).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).
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.
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.
Apply to proposed approaches and the DESIGN.md Approach section:
Before recommending an approach or declaring Decisions filled:
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.
The single brainstorm/planning index is .genie/INDEX.md; auto-create it if missing with sections:
markdown# Plans Index ## Raw ## Simmering ## Ready ## Poured
Legacy migration is idempotent: if a repo still carries the pre-INDEX.md flat brainstorm jar under .genie/, merge each unique entry into the matching section of .genie/INDEX.md, verify every legacy entry is present, then remove the legacy file and stage that deletion if it was tracked. Never update or retain both indexes after a successful merge. (The genie repo itself has already completed this migration — its jar is retired; .genie/INDEX.md is the sole tracker here.)
| Event | Action | |-------|--------| | Start | Fuzzy-match slug/topic — use as seed context | | WRS change | Move entry to the matching section (Raw/Simmering/Ready) | | Design review SHIP | Keep the entry in Ready and invoke wish | | Wish plan review SHIP | Move entry to Poured and link the existing approved wish |
At WRS = 100:
.genie/brainstorms/<slug>/DESIGN.md from DRAFT.md using references/design-template.md (in this skill dir) — fill every placeholder.bash git add .genie/brainstorms/<slug>/DESIGN.md .genie/brainstorms/<slug>/DRAFT.md .genie/INDEX.md If migration removed a tracked legacy flat jar, stage that deletion too. The genie repo's wish linter fails any wish whose design link doesn't resolve to a real file — uncommitted brainstorms are missing in CI and sibling worktrees, so never skip the stage.
.genie/INDEX.md — keep the entry under Ready and link the staged DESIGN.md. Do not move it to Poured before a WISH.md exists and its plan review is persisted as APPROVED..genie/genie.db yet, CLI unavailable), warn and continue — DESIGN.md and .genie/INDEX.md in git are the source of truth:bash genie task create --title "<brainstorm title>"
review (design review) on the DESIGN.md. The invoking orchestrator receives the verdict, reviewer-returned reviewed-content SHA-256, reviewer agent/thread identifier, and review timestamp; the reviewer remains read-only.references/design-review-evidence.mjs from this loaded skill directory. The invoking orchestrator passes the reviewer-returned digest unchanged through --reviewed-sha256 with the returned verdict, reviewer identifier, and review timestamp, then runs verify and stages DESIGN.md again. The stamp command compares that digest to the current reviewable DESIGN.md before writing and rejects an edit made after review. The SHA-256 subject is the exact UTF-8 DESIGN.md with the bounded evidence block removed, so changing any reviewed design content invalidates the evidence and requires a fresh review. Only a verified SHIP block permits wish; FIX-FIRST/BLOCKED evidence remains auditable but does not advance.bash node "<brainstorm-skill-dir>/references/design-review-evidence.mjs" stamp ".genie/brainstorms/<slug>/DESIGN.md" --verdict SHIP --reviewed-sha256 "<reviewer-returned-sha256>" --reviewer "<agent-or-thread-id>" --reviewed-at "<ISO-8601-UTC>" node "<brainstorm-skill-dir>/references/design-review-evidence.mjs" verify ".genie/brainstorms/<slug>/DESIGN.md" git add ".genie/brainstorms/<slug>/DESIGN.md"
| Complexity | Output | |-----------|--------| | Standard | Write DESIGN.md, auto-invoke review (design review), then route through wish and plan review | | Small but non-trivial | Write the compact design, run design review, then route through wish and plan review before any implementation | | Trivial | One-liner in .genie/INDEX.md (Raw), no design file |
After review returns SHIP and the digest-bound evidence verifies on the design:
Design reviewed and validated (WRS {score}/100). Proceeding to wish.Invoke wish to create and review .genie/wishes/<slug>/WISH.md. Only after the invoking orchestrator has persisted plan SHIP as WISH status APPROVED may it move the .genie/INDEX.md entry to Poured and link that existing wish. FIX-FIRST or BLOCKED leaves the brainstorm in Ready with the current design/wish link.
Never reuse design-review evidence after editing DESIGN.md. verify must pass immediately before wish consumes the design.
Note cross-repo or cross-agent dependencies — they become depends-on/blocks fields in the wish.
When spawned as a native subagent, your final message IS the completion signal — the dispatcher is notified when you finish; do not poll or emit a separate contract call. End with exactly one terminal outcome as the last word:
wish handed off. Report the DESIGN.md path.blocked / failed must include a one-line reason.
| Case | Status | Duration (ms) | Turns | Tokens | Tool calls | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Without | With | Δ | Without | With | Δ | Without | With | Δ | Without | With | Δ | ||
case-19 | pass→pass | 8,912 | 2,686 | -70% | 1 | 1 | 0% | 1,324 | 3,088 | +133% | 0 | 0 | — |
case-01 | fail→fail | 8,985 | 7,700 | -14% | 1 | 1 | 0% | 1,553 | 3,095 | +99% | 0 | 0 | — |
case-02 | fail→fail | 15,478 | 18,355 | +19% | 1 | 1 | 0% | 2,311 | 5,618 | +143% | 0 | 0 | — |
case-03 | fail→fail | 9,917 | 5,384 | -46% | 1 | 1 | 0% | 1,548 | 2,885 | +86% | 0 | 0 | — |
case-04 | fail→fail | 9,219 | 4,275 | -54% | 1 | 1 | 0% | 1,446 | 3,299 | +128% | 0 | 0 | — |
case-05 | pass→pass | 15,680 | 8,544 | -46% | 1 | 1 | 0% | 2,312 | 3,987 | +72% | 0 | 0 | — |
case-06 | fail→fail | 15,611 | 19,433 | +24% | 1 | 1 | 0% | 2,188 | 5,285 | +142% | 0 | 0 | — |
case-07 | fail→pass | 7,719 | 5,811 | -25% | 1 | 1 | 0% | 1,290 | 3,536 | +174% | 0 | 0 | — |
case-08 | fail→pass | 11,806 | 3,890 | -67% | 1 | 1 | 0% | 1,838 | 3,287 | +79% | 0 | 0 | — |
case-14 | fail→fail | 9,798 | 3,162 | -68% | 1 | 1 | 0% | 1,343 | 3,116 | +132% | 0 | 0 | — |
case-09 | pass→pass | 6,487 | 3,268 | -50% | 1 | 1 | 0% | 1,085 | 3,248 | +199% | 0 | 0 | — |
case-10 | fail→pass | 14,466 | 14,750 | +2% | 1 | 1 | 0% | 2,282 | 4,866 | +113% | 0 | 0 | — |
case-11 | pass→fail | 12,926 | 6,395 | -51% | 1 | 1 | 0% | 1,978 | 2,951 | +49% | 0 | 0 | — |
case-12 | fail→pass | 9,558 | 4,467 | -53% | 1 | 1 | 0% | 1,525 | 3,315 | +117% | 0 | 0 | — |
case-13 | fail→fail | 8,889 | 2,305 | -74% | 1 | 1 | 0% | 1,344 | 2,997 | +123% | 0 | 0 | — |
case-15 | fail→pass | 13,461 | 4,302 | -68% | 1 | 1 | 0% | 2,826 | 3,260 | +15% | 0 | 0 | — |
case-16 | pass→pass | 5,102 | 4,252 | -17% | 1 | 1 | 0% | 804 | 3,401 | +323% | 0 | 0 | — |
case-17 | fail→pass | 11,317 | 2,628 | -77% | 1 | 1 | 0% | 1,806 | 3,105 | +72% | 0 | 0 | — |
case-18 | fail→fail | 8,673 | 3,344 | -61% | 1 | 1 | 0% | 1,251 | 3,214 | +157% | 0 | 0 | — |
case-20 | fail→pass | 4,571 | 10,181 | +123% | 1 | 1 | 0% | 271 | 4,381 | +1517% | 0 | 0 | — |
case-21 | fail→fail | 4,415 | 8,880 | +101% | 1 | 1 | 0% | 448 | 3,126 | +598% | 0 | 0 | — |
case-22 | pass→pass | 7,230 | 14,602 | +102% | 1 | 1 | 0% | 1,301 | 4,894 | +276% | 0 | 0 | — |
DecimalAI ran this skill against gemini-3.6-flash twice over the same eval suite — once with the skill loaded and once without — and compared the two runs case by case. 22 cases were attempted, and 17 counted toward the lift figure. The other 5 produced results that are not comparable between the two arms, so they are excluded from the headline rather than averaged into it. The headline lift of +27 percentage points is the difference between those two pass rates over the 17 comparable cases. 2 cases got worse with the skill loaded, and they are included in that figure.
Without the skill loaded, the model failed this case. With it loaded, the same prompt on the same model passed. This is one improved case from the latest verified run; every case, including any that regressed, is in the table above.
Other measured skills in the registry, with their headline benchmark lift.