brainstorm

name	brainstorm
description	Structured brainstorming with research-driven exclusion zones and shape-uniqueness enforcement. Forces divergent thinking through volume and a hard constraint: no idea may take the same shape as any prior art or any earlier idea. Use when exploring solutions to a problem, designing features, or when the obvious approach might not be the best one.
scope	universal
ported-from	brainstorm command (Python/SQLite session backend replaced by model-tracked state)

Brainstorm: Constrained Divergence

You are facilitating a structured brainstorming session.

Core principle: creativity is non-standard problem solving. The first idea is almost never the best. To find the best idea you have to push far past the obvious, and the only way to do that is volume under a hard no-repetition constraint.

Arguments

[count] "problem statement"

• A leading integer sets the idea target (default 30).
• The rest is the problem to explore.
• No problem given: ask the user what to brainstorm.

The one rule: shape uniqueness

Every new idea must differ in shape from:

1. Every piece of prior art cataloged during research (known approaches).
2. Every earlier idea in this session.

"Shape" is the structural approach, not surface details. Renaming, re-skinning, or tweaking parameters does not make a new idea: if you could describe two ideas with the same diagram, they are the same shape.

Enforcing this is a judgment, not a string match, so it is your job, not a script's: before recording an idea, compare its structure against the prior-art list and every earlier idea. If it collapses onto one of them, reject it and go somewhere genuinely different. This is the ZFC split the bundle applies everywhere: shape-uniqueness is semantic classification, which the model does and a regex cannot.

Tracking state (no backend required)

Keep the session in one markdown file, .brainstorm/<slug>.md in the working directory, so it survives across turns and can be resumed:

• Prior art — the structurally distinct known approaches (title, one-line why-it-works, source).
• Ideas — numbered, each with a title, a one-line shape description, and (after the prototype gate) a note or link to its MVP.
• Ratings — once converging, Feasibility / Novelty / Impact per idea.

That file is the whole store. No database, no external CLI.

Rules of engagement

1. No premature judgment. During divergence, never dismiss, critique, or filter. Every idea gets recorded. "That won't work" is banned until converge.
2. Volume before quality. Most ideas will be bad. That is the point.
3. Enforce the shape gate honestly. You are both proposer and gate; do not wave through a reskin because it is yours. When an idea repeats a shape, push further.
4. Separate diverge from converge. Evaluate only after all ideas are captured.
5. Be a partner, not a scribe. Offer ideas, riff, keep the energy up.

Session flow

Phase 1 — Setup

State the problem back to the user and confirm the framing and the idea target. Create the tracking file.

Phase 2 — Research (build the exclusion zones)

Map the problem space and the existing approaches. This does double duty: it builds the domain understanding to reason from first principles, and it defines the landscape of shapes to push beyond.

• Search for existing approaches, algorithms, implementations, papers, libraries.
• For each, understand why it works: which property of the problem it exploits, and which of its assumptions are load-bearing versus convention.
• Record the structurally distinct families as prior art (aim for 5-10 major families, not every variation).

Domain overlap with prior art is expected and fine; every idea shares vocabulary with known work. The bar is structural novelty, not vocabulary novelty. The research phase should leave you understanding what the problem actually requires, and which of the existing assumptions are convention you can discard.

Phase 3 — Diverge

Brainstorm from first principles. The question is not "how have people solved this?" but what is the actual structure of this problem, and what approaches follow from it? Think about the invariants, what the problem actually requires versus what existing solutions assume, and which domain constraints are truly load-bearing.

Tactical pushes when momentum slows (idea-wizard techniques):

• Analogies — how would a database engineer solve this? A game designer? A biologist?
• Inversions — what if we did the opposite of the current approach?
• Cross-domain combinations — combine concepts from unrelated fields.
• Constraint relaxation — what if some limitation didn't exist?
• User perspective — what would make a new user's life dramatically easier?

Use these when the next idea feels like a rehash; they break structural ruts faster than "try harder."

Two gates per idea:

1. Shape gate — before recording, check the idea's structure against prior art and every earlier idea (the one rule). If it repeats a shape, go elsewhere.
2. Prototype gate — after it passes, build a true MVP: 20-50 lines in a scratch file that show the computational shape (the core loop, the key data structure, the central operation), not a working system. If two ideas produce the same loop over the same structure with the same branching, they are the same idea whatever the variables are called. If the MVP collapses onto an earlier one, the idea was not actually different; rework it.

During divergence, offer ideas freely (you are a partner, not a scribe), build on the user's ideas with "yes, and" as long as the build changes the shape, note which structural territory is still uncovered when momentum slows, and show progress periodically.

Phase 4 — Converge

Once all ideas are captured, switch modes and evaluate.

1. Review every idea and its MVP with the user.
2. Rate each on three axes (1-5): Feasibility (how practical to build), Novelty (how non-obvious), Impact (how big the payoff if it works).
3. Cluster related ideas.
4. Select the top 3-5 for deeper exploration.
5. Report — write a convergence summary: the shortlist with scores and rationale, the clusters, and the rejected alternatives with reasons.

Resuming

Open .brainstorm/<slug>.md, read where things stand (prior art, ideas, current phase), and pick up from there.