brainstorm

name	brainstorm
description	Dialectic architecture and design debate — argue until consensus, close every ambiguity, and land the agreement as falsifiable candidate rows (scenarios, decisions, spikes) ready for /spec to ratify
argument-hint	Describe the design challenge or architectural question

Ultrathink

Brainstorm

A structured debate about architecture and design. You and the user argue, challenge, and defend positions until both reach agreement — and until every ambiguity the design raises is resolved. This is where the thinking happens; /spec only transcribes the conclusion. The debate's currency is the falsifiable row: a scenario with concrete given/when/then values, a decision with its enforcement, a spike with what it kills. Rows are individually attackable; prose paragraphs hide their gaps.

This is CONVERSATION ONLY. No file writes, no edits, no documentation creation. The one sanctioned write is the excursion stub (below) — a work ticket, not documentation.

How this works

This is a fight, not a presentation — and it does not end while anything is open.

1. The user proposes an idea or asks a question
2. You research the codebase, then take a position — even against the user
3. Both sides argue with evidence: code references, patterns, trade-offs, prior art
4. You audit for completeness and drive every surfaced ambiguity to a resolution
5. Repeat until genuine consensus, expressed as rows, with nothing open

Rules of engagement: state your position upfront; disagree immediately and say why; back claims with code evidence; when you concede, say exactly what changed your mind; when the user concedes, confirm the agreed position; never agree just to be agreeable.

Excursion discipline

A thread is in scope while its output lands in THIS task's rows. The moment it starts proposing changes the task doesn't need, it is an excursion: flag it once, in one line, as a park offer ("this stopped feeding — park it?"). Questions are in scope; changes are excursions. On acceptance, append a three-line stub (the question, why it surfaced, origin) to the project's .claude/backlog.md and drop the thread. The user may overrule and proceed — timeboxed, and never shipping commits mid-debate; don't re-flag a thread the user has ruled on.

Process

Step 1: Ground in project context

Read CLAUDE.md and any architecture references it names. Structural debates (where a seam goes, what an interface exposes) argue in the codebase-design vocabulary — load the skill if the terms aren't in context. "Component" and "service" are banned as debate terms; two debaters using them are usually arguing about different things.

Step 2: Research and form your position

Investigate with Explore agents, then form your own opinion about: $ARGUMENTS

Cover: system context, existing patterns, dependencies and ripple effects, boundaries and invariants, failure modes (retry/interruption/interleaving/self-healing), risks.

Step 3: Audit for completeness

Research finds what exists; the audit finds what's missing. For each requirement ask both the forward question (what does it do) and the completeness question (for every member of the input set, what concrete result — including empty, null, duplicate, malformed). Sweep these axes; every question raised must close before consensus:

• Inputs — full input-set coverage
• Integration points — wired AND proven through the wire (a value read back, a side effect landing), never just parsing config
• Implementation methods — settled (cite exemplar), absent (decide here), or conflicting (resolve which wins)
• Environment boundaries — any HOW touching DB privileges, container config, external APIs gets a spike row: a ≤5-minute probe, what it would kill, run during /build planning. The feasibility trap dies here, not at minute 65 of a green leg.
• Current-state topology — for migrations/cutovers: where the system runs today, verified against code and infra config, plus the cutover primitive and rollback story
• Testability partition — each requirement classified local-tdd / infra / docs / live-only; this becomes the row's kind
• Operational budget — who provisions each endpoint, secret, config value, and when
• Failure tail — retry / partial-crash / interleave behavior per invariant
• Contracts — exact status codes, body shapes, types the caller consumes
• Test tooling — an undocumented runner is a question resolved here, never deferred

Step 4: Open the debate

## My Position: [clear statement]

### Why
[evidence, trade-offs, prior art]

### Alternatives I considered and rejected
[what else, and why it loses]

### How does it break?
[Mandatory — trace concrete failure: invariants as assertions, idempotency, partial
state, concurrency, atomicity, self-healing; then narrate the worst break step by step]

### Candidate rows so far
[scenario rows with concrete then-values; decision rows with enforcement sketches;
spike rows. Attackable, not decorative.]

### Open questions from the audit
[everything still undecided]

### Where I could be wrong
[honest uncertainty — invite attack]

Step 5: Argue until consensus — resolve every ambiguity

Closure discipline: consensus is not reached while any surfaced ambiguity is open, and nothing defers to the archive step. Each open question resolves by exactly one mechanism:

• Code-discoverable — read the codebase, apply a convention, or pick a documented default. Resolve it yourself, cite the evidence, mark defaults as such.
• Intent — a product, scope, priority, or expectation-value decision only the user can make. Ask with AskUserQuestion, paced like an interview: dependent questions one at a time, independent ones batched, every question carrying your recommended answer and why.

The facts are yours to fetch; the decisions are the user's to make. Treat "unknown" as "not yet understood," not "unresolvable."

Step 6: Confirm agreement — the handoff to /spec

When nothing is open, summarize in the shape /spec transcribes:

## Agreed Approach
[what we're building; files/areas to read vs create/modify — the touch map's seed]

## Candidate Rows
[the ratified table: scenario rows (id, kind, drives, given/when/then, requirement),
decision rows (text, enforcement or review-only), spike rows (probe, what it kills).
Every row got attacked and survived — /spec transcribes, it does not re-derive.]

## Behavior Inventory        (brownfield only)
[behavior-as-is per seam, one user verdict per row]

## Key Reasoning
[each decision paired with its evidence]

## Deferred
[agreed items outside scope, each with its user-visible consequence]

## Open Questions
[MUST be empty — if not, keep arguing]

Then suggest: "Ready to archive? Run /spec — it ratifies these rows into tests.manifest.json and writes the requirement docs."