Session Brainstorm

Session Brainstorm

Turn an idea into a decision the user has approved, before anything is built.

Open with one sentence saying what you are about to do and what it will produce.

Rules

1. Nothing is implemented until the user has approved a design. This holds for a two-sentence change as much as for a subsystem. The size of the design scales with the task; the approval does not.
2. One question per message. Prefer multiple choice when the options are known. Let each answer shape the next question.
3. Options come with a recommendation. Present two or three approaches with their trade-offs and say which one you recommend and why.
4. Classify out loud. Say which path the request is on, so the user can override it.
5. Nothing leaves this skill without a captured work item. Every path that continues past a spike allocates identity first, through /session-add-task, which writes the record with the runtime. Capture is not permission: the item lands in captured, select refuses it by name, and the user's approval of the design is what makes it acceptable — not the fact that a record now exists.

Three paths

Classify the request before the first question, and say the classification.

• Spike. A feasibility question: "can we", "is it possible", "quick and dirty is fine". The output is an answer, not code to keep. Say what you will try in two or three sentences, get a nod, find out as cheaply as correctness allows, and report a recommendation. Anything built is labelled throwaway.
• Bounded. A well-scoped change to a flow that already exists in the repo: a flag, a small endpoint, a one-file fix. Ask the questions that matter, present a short design in chat (approach, files touched, how it will be tested), and stop until the user says yes. Then capture it with /session-add-task — the design becomes the record's interpreted intent and the approved behaviour becomes its scope — and implement against that identity, or leave it captured if it is for later.
• Architectural. A new subsystem, a new project, or a change to how components fit together. Do not design it here. Frame the problem with the user, capture the framed problem with /session-add-task so the work has an identity before anyone researches it, then hand that identity to /session-research-design, which produces the research report and the plan against it.

When in doubt between two paths, take the larger one. Complexity found mid-task moves the work up a path; say so when it happens.

Understanding the idea

• Read the current state first: files, docs, recent commits.
• If the request describes several independent pieces, say so before refining any of them, and help the user decide which piece comes first.
• Focus on purpose, constraints, and what success looks like.
• Remove features that do not serve the purpose from every option you present.

Presenting a design

• Scale each part to its difficulty: a few sentences where it is straightforward, a short paragraph where it is not.
• Cover the approach, the files touched, how it will be tested, and what it deliberately leaves out.
• Where existing code has a problem the work must touch, include the targeted fix in the design. Do not propose unrelated refactoring.
• Ask whether the design looks right, and wait for the answer.

Capturing what came out

/session-add-task writes the record; this skill supplies what goes in it, and the distinction it must preserve is the one this conversation is uniquely able to make:

• original_request — the user's own words that opened the brainstorm, verbatim. Not the refined version you arrived at together.
• Interpreted intent — what you understood, including what you removed from the idea and why.
• Scope — the approved behaviour, in terms the user would recognize as what they asked for.
• Provenance — origin: "user", the actor, and the capture time. No [auto]: the user was here for this.
• Open questions — anything the design left unsettled, in the body. A brainstorm that ended in agreement can still have them.

Report the allocated SEQ-NNN and say plainly that it is captured, not accepted.

Handoff

• Spike: report the recommendation. Done — a throwaway answer is not a work item. Capture only the follow-up work the answer revealed, if any.
• Bounded, approved: capture with /session-add-task, then implement against that identity, or leave it captured for later.
• Architectural: capture with /session-add-task, then /session-research-design against that identity.

Derived from the brainstorming skill in superpowers by Jesse Vincent (MIT); see THIRD_PARTY_NOTICES.md. Chain context: references/workflow-overview.md.