brainstorm-deep

/brainstorm-deep — clarification-heavy ideation

The third member of the brainstorm family. Position:

Skill	Use when
/brainstorm	Fast conversational ideation, low ambiguity, you trust the model's first read
/brainstorm-deep	High ambiguity OR high stakes; misalignment risk dominates cost
/brainstorm-team	Multi-persona product strategy doc, autonomous, long-form output

The differentiator vs /brainstorm is structured saturation: questions are asked in batches drawn from a fixed 9-bucket typology, with an explicit stop rule (saturation OR 3-batch ceiling). The differentiator vs /brainstorm-team is that the perspective layer here is frames against the same idea (inversion, pre-mortem, steelman, adjacent reuse) rather than role-based personas writing separate sections.

When this skill triggers

• User types /brainstorm-deep or /brainstorm-deep <topic>
• User says "I'm not sure what I want", "this is vague", "high stakes", "really important to get right"
• User asks for more rigor than /brainstorm provided on a previous run
• A previous /brainstorm produced a plan the user is uncertain about — this skill can re-engage on the same topic with deeper clarification

Execution mode — prose by default; Pass 3 fan-out via Workflow when ultracode is on

This skill is a hybrid, so unlike /sdlc only part of it can ever run as a Workflow. The interactive passes (Pass 1 understand, Pass 2 saturate-by-questioning), the variant selection, and the expectation-contract pre-write gate are conversational — they always run in the main thread and can never be scripted (a Workflow orchestrates autonomous agents and cannot pause to converse).

The prose passes below are the default and the source of truth. The one autonomous slice — Pass 3's parallel perspective-frame fan-out + variant drafting — is delegated to a deterministic Workflow only when explicitly opted in (same flag and gate as /sdlc):

Use the Workflow for Pass 3 IFF ALL of: Claude Code with the Workflow tool available, ultracode explicitly enabled (keyword, session flag, or asked-for by name), and pipeline.skip_workflow not true in .claude/project.json.

When that holds, run Passes 1–2 interactively as usual, then at Pass 3 invoke:

Workflow({
  scriptPath: ".claude/skills/brainstorm-deep/workflows/brainstorm-deep.workflow.js",
  args: {
    framing:        "<agreed 'what we're solving' from Pass 1>",
    clarifications: "<the Q-A captured in Pass 2>",
    conventions:    "<the path:line reuse recon from Pass 1>",
    frames:         ["inversion","pre-mortem","steelman","adjacent-reuse"],  // or --frames
    ambition:       null   // or "conservative"|"default"|"ambitious" for --ambition
  }
})

It runs one Sonnet agent per frame in a guaranteed parallel barrier (no silently-serialized or dropped frames), validates each frame's output shape, drafts the variants, and returns {frames, conflicts, variants}. You then continue in the main thread: surface any conflicts for the user, present the variants for selection, assemble the plan per the Output template, run the four-section expectation-contract gate (Step 5), and Write.

Otherwise — the default — run Pass 3 as prose (the in-thread single-message parallel Agent dispatch in Pass 3 below). That covers any non-ultracode Claude run, Copilot/Codex (no Workflow tool — Codex has its own plan mode, but not this JS orchestration primitive, and uses the sequential overlay), older Claude Code, and skip_workflow: true. The prose is the source of truth; the Workflow mirrors it — change the prose first, then the Workflow (see CLAUDE.md → "Workflow-backed skills … the three-way sync contract").

How it works

Step 0: Enter Plan mode

Switch to Plan mode (EnterPlanMode on Claude Code; equivalent step-by-step approval flow on Copilot). This skill is conversational by design — implementation is for /sdlc later.

Pass 1 — Understand (≤2 minutes of chat)

Goal: agree on what we're solving before asking clarifying questions. Many "this missed the mark" outcomes come from the model anchoring on the wrong interpretation, not from too few clarifications.

1. Restate the ask in your own words. Use 2–3 sentences max.
2. Surface 2–3 plausible interpretations of what the user meant. Phrase them as concrete differences, not paraphrases. Example:
   • Interpretation A: build feature X as a standalone module.
   • Interpretation B: extend existing module Y to cover the X case.
   • Interpretation C: refactor Y so X falls out as a side-effect.
3. Ask the user to pick (or "none — here's what I really mean").
4. Capture the agreed framing as a "What we're solving" block at the top of the working notes. This block becomes the seed of the expectation contract in Pass 3.

If the user's pick reveals a much smaller or much larger scope than implied by the prompt, flag it explicitly: "this is narrower than I expected — should we use /brainstorm instead?" or "this is broader than I expected — /brainstorm-team may serve you better." Don't redirect silently.

5. Ground in the live code. Before clarifying further, do the convention recon in skills/sdlc/templates/convention-grounding.md: find the 2–3 closest existing implementations to the idea and note the patterns they follow (path:line). Live code is the source of truth, not AGENTS.md / CLAUDE.md — treat docs as hints, verify against code, and flag any drift. This both sharpens the Pass 2 questions (you ask about real seams, not imagined ones) and seeds the ## Conventions & reuse block in the output. Don't propose building what the repo already has.

Pass 2 — Saturate by questioning (max 3 batches)

Goal: ask enough clarifications that further questions would not change the design. Stop the moment that's true. --fast limits this pass to a single batch — one batch of clarifying questions (instead of up to 3), then proceed to Pass 3.

1. Read templates/question-typology.md for the 9 buckets: Scope, Success, Failure, Audience, Priors, Trade-offs, Constraints, Reversibility, Resemblance.

2. Pick the 3–5 buckets the ask is most ambiguous on. Do not ask all 9 — that's exhausting and signals the model didn't read the prompt. Justify the pick to the user in one line: "I'm asking about Scope, Failure, and Reversibility because those are where I'd most likely build the wrong thing."

3. Ask one batch of 3–5 questions. Wait for answers. Never ask one question at a time — batches of 3–5 keep the loop fast.

4. Self-score after each batch: "what do I still not know that would change the design?" If the answer is "very little," proceed to Pass 3. If "a lot," ask another batch (max 3 total batches).

5. Anti-ratholing rule: track scope creep across batches. If the user adds new requirements in 2+ rounds, surface explicitly:

   "We've added N requirements over M rounds — pause options: (a) decompose into multiple plans, (b) commit to current scope, (c) park the new requirements as follow-ups."

   Do not silently absorb scope creep into a single ballooning plan.

6. Hard ceiling: 3 batches. After the third batch, proceed to Pass 3 even if you'd love to ask more. The friction cost dominates beyond that point.

Pass 3 — Perspective frames + plan with alternates

Goal: stress-test the agreed framing from multiple angles, then produce a plan the user can act on.

1. Read templates/perspective-frames.md for the 8 available frames.

2. Pick frames. Defaults: inversion, pre-mortem, steelman, adjacent-reuse. --frames <comma-list> overrides.

3. Dispatch in parallel. In a single message, fire one Agent tool call per frame with subagent_type: "general-purpose", Sonnet model. Each agent gets the agreed framing, the user's clarified answers, and the frame's prompt from the template. Each returns ≤300 words.

4. Synthesize. Frames go in their own labeled section in the plan (## Perspective passes); they inform the design but do not override user intent. If a frame's output contradicts a user clarification, surface the conflict for the user to resolve, don't silently side with the agent.

5. Produce three plan variants at different ambition levels:

   • Conservative — minimum viable, narrowest scope, smallest blast radius.
   • Default — what the conversation has been pointing at.
   • Ambitious — what we'd build if budget weren't a constraint.

   Each variant: 1-paragraph summary + 5–10 bullet implementation outline + estimated effort + key risks. The user picks; the picked variant becomes the body of the plan file.

6. --ambition <level> collapses to a single variant up front. Useful for follow-up runs once the user knows what they want.

Step 4 — Expectation contract (mandatory output block)

Every plan file produced by this skill must end with this block:

## Expectation contract

**What you said**
<verbatim ask, lightly edited for grammar>

**What I heard**
<restatement of the agreed framing from Pass 1, plus any reframing
that emerged in Pass 2>

**What I'm NOT doing**
- <explicit non-goal 1>
- <explicit non-goal 2>
- ...

**How we'll know it worked**
- <observable success signal 1>
- <observable success signal 2>
- ...

/sdlc and /task can grep this block to ground their own work.

Step 5 — Write the plan file

Pre-write gate (mandatory). Before calling Write, verify the expectation contract block:

1. The block exists at the bottom of the plan content.
2. All four sub-sections are present and populated: What you said, What I heard, What I'm NOT doing (≥1 non-goal bullet), How we'll know it worked (≥1 success-signal bullet).

If any sub-section is missing, empty, or filled with a placeholder like <TBD>, refuse to call Write. Instead, ask the user to supply the missing pieces and only proceed once they're filled in. The expectation contract is this skill's misalignment-catching net; writing a plan without it defeats the skill's purpose.

Write to plans/brainstorm-deep-<topic-slug>.md. Slug is derived from the user's topic the same way /brainstorm does it. Same naming convention so downstream /sdlc <plan> consumption is uniform. Plan-mode sandbox: if the host only permits writes to a transient plan path during plan mode, author there while planning, then persist the canonical copy to repo-root plans/brainstorm-deep-<topic-slug>.md immediately after exiting plan mode — same handling as /brainstorm Step 6.

Args

• <topic> (optional) — if absent, ask in Pass 1.
• --fast — limit Pass 2 to a single batch of clarifying questions (instead of up to 3). Useful when the user knows the skill and wants only the perspective-frame pass.
• --frames <list> — comma-separated frame names from templates/perspective-frames.md. Default: inversion,pre-mortem,steelman,adjacent-reuse.
• --ambition <level> — conservative / default / ambitious. Skips the 3-variant output and produces only that level.

Rules

• Plan mode only for the conversational passes. Sub-agent dispatch in Pass 3 happens after Plan mode exits and the user has approved the framing.
• Batches of 3–5 questions, never one at a time.
• 3-batch ceiling, no exceptions. If you reach it and still feel uncertain, say so out loud and proceed anyway — that's a useful signal to the user.
• Sub-agents return ≤300 words each. Frame agents are punchy stress-tests, not essays.
• Frames inform, don't override. User intent wins ties.
• You MUST refuse to call Write if the expectation contract block is missing, incomplete, or contains placeholder text. All four sub-sections (What you said, What I heard, What I'm NOT doing, How we'll know it worked) must be populated. This is a hard stop, not a soft preference.
• --fast is the eject hatch, not the default. If users start passing it every time, the skill's depth is wrong for them and they should be using /brainstorm.

When to redirect to a sibling skill

• Ask is small, well-scoped, low-stakes → /brainstorm
• User wants faster divergent ideation with model-tier-driven rigor (3 Haiku + Sonnet stress-test + 2 Opus reviewers) on a plan they're already mostly happy with → /brainstorm --vet ultra. Difference: ultra is a validator stack applied to an existing draft; brainstorm-deep is a clarification loop run before the draft exists. If you're not sure what you want, you want this skill, not ultra.
• User wants competitive analysis or a multi-persona team to write separate sections → /brainstorm-team
• User already has a clear PBI in mind and just wants it written up → /task for now (/pbi will be the right answer once Phase 1D lands; it doesn't exist yet)
• Ask is "audit the existing X for issues," not "design something new" → /repo-health or /dead-code-review

Subagent usage summary

Step	Subagents	Model	Count
Pass 1, Pass 2	none — main context window	—	0
Pass 3 frame stress-test	yes — parallel single-message dispatch	Sonnet	1–8 (default: 4)

Per the model/cost reference table, this skill costs roughly $0.20–0.40 per run at 2026 list pricing — comparable to /brainstorm --vet light. The cost is dominated by the frame agents in Pass 3; Passes 1 and 2 are pure conversation.

Cross-tool notes

• Claude Code: full skill works as designed. Plan mode + parallel agent dispatch.
• GitHub Copilot: Plan mode is unavailable; treat each pass as a step requiring the user's "continue" approval. Frame stress-tests run sequentially rather than in parallel — slightly slower, same output. A Copilot-optimized overlay already exists at copilot/skills/brainstorm-deep/ (sequential frame execution); setup.sh installs it in preference to this canonical version for Copilot targets.

Output

A single plan file at plans/brainstorm-deep-<topic-slug>.md containing:

# Brainstorm-deep: <topic>

## What we're solving
<agreed framing from Pass 1>

## Clarifications captured
<bulleted Q-A from Pass 2 batches>

## Perspective passes
### Inversion
<agent output>

### Pre-mortem
<agent output>

### Steelman the opposite
<agent output>

### Adjacent reuse
<agent output>

## Plan variants
### Conservative
<summary + outline + effort + risks>

### Default (recommended)
<summary + outline + effort + risks>

### Ambitious
<summary + outline + effort + risks>

## Selected variant
<which variant the user picked>

## Conventions & reuse
<from the Pass 1 grounding recon — what the plan reuses from the live code so
implementation follows the repo instead of reinventing it; cite `path:line`.
Include a "Doc drift" line if AGENTS.md/CLAUDE.md disagreed with the code.>

## Expectation contract
<the four-block contract — mandatory>

That's the contract. Don't stop at the file — continue the flow. Hand it to the pipeline: /sdlc-lite <plan> (full pipeline, hands you the validated changes to commit — the safe default, no git writes) or /sdlc <plan> (full pipeline → PR; confirm first since it opens a PR). Continue whichever flow you've used this session; default to /sdlc-lite otherwise. /plan-html <plan> renders the plan for a visual read first if the user wants to see the shape of the work. Both pipeline skills grep the expectation-contract block to ground their work.