brainstorm-session

name	brainstorm-session
description	Let's brainstorm, I need ideas, brainstorm with me, what should I build, generate ideas, give me alternatives, I don't know where to start, SCAMPER, six thinking hats, reverse brainstorm, how might we, creative unblock — facilitated ideation on any topic (software, business, content, travel, creative, personal), from blank slate to refining an existing concept. Runs as a quick pass (a few turns) or a full facilitated session. A specific technique can be requested by name as a mode (e.g. "scamper", "six-hats", "reverse", "hmw", "unblock") and runs inside the session frame.
argument-hint	[topic or problem] [technique: scamper|six-hats|reverse|hmw|starburst|unblock]

Brainstorming Ideas Into Reality

The ultimate brainstorming partner. Help turn problems, ideas, and blank slates into fully formed designs through natural collaborative dialogue, proven ideation methodologies, and structured evaluation.

Do NOT invoke any implementation skill, write any code, scaffold any project, or take any implementation action until you have completed the brainstorming process and the user has approved the output. This applies regardless of perceived simplicity.

Required reading: Read references/facilitation-principles.md before facilitating. It defines the anti-anchoring depth, the engagement signals (including "user agrees with everything = stop offering ideas"), and the progressive-engagement ladder this skill depends on.

First Response: Quick Take or Session?

Some triggers ("help me think through X", "how should I approach this", "I'm stuck") often want an answer, not a facilitated session. If the user seems to want an answer rather than ideation, ask before loading any machinery: "Want a quick take, or a brainstorm session?" A quick take is a normal answer — no session frame at all. Only proceed into this skill's process when the user wants ideation.

Tier Selection: Quick or Full

Every session runs at one of two tiers. Pick the tier as the first step:

• Quick tier — starting-state question → one technique chosen for the topic → top-3 ideas + a recommendation → offer to go deeper or stop. Zero subagent dispatches, no file unless asked, target ≤5 user turns. Anti-anchoring still applies: the user's thinking comes out first.
• Full tier — the complete phased process below. For genuinely open problems.

Triggers for quick: the user says "quick" / "just give me some ideas", or the topic is small/bounded and the user already has a direction. Small or bounded topics default to quick — say what you're doing ("This looks bounded, so I'll run a quick pass — say the word if you want the full session") and offer full. Genuinely open or high-stakes problems default to full.

Facilitation Mode Dial

When it's ambiguous who should be generating, ask one question at session start: "How do you want to work — you generate and I facilitate, we generate together, or I generate and you react?" (facilitator · partner · generator). Default is facilitator — the anti-anchoring brand. Generator mode reuses the quick-tier flow: your ideas, their reactions, minimal turns.

Execution: parallel-first

This skill chains many phases (in full tier) with optional sub-agent dispatch. To keep wall-clock time and context usage sane:

• Context exploration (Phase 1 state detection + Phase 1 file exploration + optional Phase 3 domain research) has no inter-step dependencies. Issue parallel Read/Glob/Grep calls, and if domain research is triggered, dispatch domain-researcher concurrently with the local file reads — do not serialize.
• Phase 7 design presentation reads existing files (codebase structure, related specs). Batch those reads.
• Spec review — any file reads the reviewer needs should be parallel within the dispatch.
• What to serialize, always: the anti-anchoring question sequence in Phase 2 (user must respond before you offer ideas), and the divergent → convergent transition (mixing modes defeats the protocol).

Opus- and Sonnet-class models handle parallel batching well; Haiku-class models may prefer serial execution for reliability.

Technique Modes

The standalone technique skills were folded into this session (v3.0). When the user names a technique — in the invocation argument or in conversation ("run a SCAMPER on this", "let's do six hats") — run that technique as the divergent phase, inside the normal session frame (anti-anchoring first, convergent phase after). Techniques and their instructions live in references/methodology-catalog.md:

Mode	Technique
scamper	SCAMPER — Substitute, Combine, Adapt, Modify, Put to other use, Eliminate, Reverse
six-hats	Six Thinking Hats — Blue/White/Green/Yellow/Black/Red perspectives
reverse	Reverse brainstorming — "how could we make it worse?", then invert
hmw	How Might We — reframe problems as opportunity questions
starburst	Starbursting — generate the questions before the answers
unblock	Creative unblocking — warm-ups and provocations (references/creative-unblocking.md)

A named technique narrows the divergent phase; it never skips anti-anchoring or convergence. (Root-cause analysis is different — that's /rad-brainstormer:five-whys.)

Checklist (Full Tier)

Complete these steps in order. (Quick tier runs steps 1–2 and 4, a single technique from step 6, then a top-3 + recommendation wrap-up — nothing else.)

1. Select tier and mode — Quick or full (see "Tier Selection"); facilitator/partner/generator if ambiguous. Triage scope: if the ask spans multiple independent subsystems, decompose into sub-projects first (see "Large Project Decomposition") — each gets its own session.
2. Detect starting state — Where is the user? (blank slate / vague idea / clear idea / improving existing)
3. Explore context — Check project files, docs, recent commits (if software-related)
4. Anti-anchoring check — Draw out the user's existing thinking BEFORE offering yours
5. Domain orientation — Would domain research genuinely help? Offer it only at the right moment (see Phase 3)
6. Divergent ideation — Select and apply appropriate techniques based on starting state (or the requested technique mode)
7. Convergent evaluation — Filter and prioritize using appropriate framework
8. Propose 2-3 approaches — With trade-offs and a recommendation
9. Present design/output — Scaled to domain (spec for software, strategy doc for business, etc.)
10. Deliver the output — One self-contained markdown file; ask where (see "Delivering the output")
11. Spec review (if software) — Inline self-review checklist, then at most one spec-reviewer dispatch
12. User reviews output — Get explicit approval
13. Transition — Route to appropriate next step based on domain

Process Flow

Detect Starting State
       │
       ▼
Explore Context ──► Anti-Anchoring: Draw out user ideas first
       │
       ▼
Domain Research Needed? ──yes──► Dispatch domain-researcher agent
       │ no                              │
       ▼◄───────────────────────────────┘
SELECT METHODOLOGY (based on starting state, or the requested technique mode)
       │
       ▼
┌──────────────────────────────────────┐
│ DIVERGENT PHASE                      │
│ "We're in idea generation mode —     │
│  all ideas welcome, no filtering"    │
│                                      │
│ Apply selected techniques            │
│ Capture ALL ideas (user's + yours)   │
│ NO evaluation during this phase      │
└──────────────┬───────────────────────┘
               │
               ▼
┌──────────────────────────────────────┐
│ CONVERGENT PHASE                     │
│ "Let's switch to evaluation mode"    │
│                                      │
│ Apply evaluation framework           │
│ Narrow to 2-3 top candidates         │
│ Optionally dispatch idea-challenger  │
└──────────────┬───────────────────────┘
               │
               ▼
Propose 2-3 Approaches (with trade-offs + recommendation)
               │
               ▼
Present Design/Output (section by section, get approval after each)
               │
               ▼
Deliver Output (one file — ask where; no auto-commit)
               │
               ▼
Domain-Specific Routing:
  Software → spec review → /rad-planner:plan
  Business → business model canvas → action plan (out-of-repo)
  Content  → content strategy doc → editorial plan (out-of-repo)
  Research → research plan → methodology outline
  General  → action plan with next steps (out-of-repo)
  Any in-repo sequencing → /rad-planner:plan (vocabulary quarantine)

Phase 1: Starting State Detection

Before asking a single question about the topic, determine WHERE the user is:

Signal	Starting State	Approach
"I want to build something but don't know what"	Blank slate	Creative unblocking → Starbursting → HMW
"I have this vague idea about..."	Vague idea	Clarifying questions → SCAMPER → Reverse Brainstorm
"I want to build X but need to think through the design"	Clear idea	Six Thinking Hats → Morphological Analysis → Design
"I have X but want to make it better"	Improving existing	SCAMPER → 5 Whys → TRIZ (if technical)
"I have several ideas and need help choosing"	Needs evaluation	Jump to Convergent Phase

If unclear, ask: "Where are you in your thinking? Are you starting from scratch, exploring a vague idea, or refining something specific?"

Phase 2: Anti-Anchoring Protocol

CRITICAL — Do this BEFORE offering any ideas.

Research on human–AI ideation consistently shows that when AI suggests ideas first, humans anchor on them — producing fewer, less varied, less original ideas. The brainstormer must counteract this:

1. Ask: "Before I share any ideas, what have you been thinking so far? Even half-formed thoughts are valuable."
2. Ask: "What direction appeals to you intuitively, regardless of whether it seems feasible?"
3. Ask: "Is there anything you've already ruled out? Why?"
4. Capture and acknowledge ALL user ideas before adding yours
5. When offering ideas, frame them as building on the user's: "Building on your idea about X, what if we also..."

Phase 3: Domain Orientation

Assess whether domain research would improve the brainstorming:

• Research needed: The topic involves an industry, market, or technical domain where current context matters
• Research not needed: Personal/creative topics, well-understood domains, or user is the domain expert

Just-in-time offer. Domain research is a multi-minute, high-token dispatch — never offer it upfront as a menu item. Offer it in its own message, only when the moment is genuinely right (the conversation has hit a question that current domain context would actually answer): "I want to make sure I'm well-informed about [domain]. Want me to do some quick research before we go further?" The same pattern applies to other optional extras (idea-challenger, deep evaluation).

If the user says yes, dispatch the domain-researcher agent directly (it is defined in this plugin, JSON-first output):

Agent tool:
  subagent_type: domain-researcher
  description: "Research [domain] for brainstorming"
  prompt: <substitute references/subagent-prompts/domain-research.md with {topic} and {session_context}>

Parse the JSON response (markdown fallback accepted — see the agent's output contract). Weave the brief into questions naturally — do not dump a research report on the user. If the brief contains items in its surprises field, flag them prominently before continuing.

Phase 4: Methodology Selection

Reference references/methodology-catalog.md for detailed technique instructions.

For Blank Slate:

1. Run a warm-up exercise (from references/creative-unblocking.md)
2. Starbursting — Generate questions about the problem space
3. How Might We — Reframe the best questions as opportunity statements
4. Crazy 8s (adapted) — Rapid-fire idea generation on the best HMW questions
5. → Convergent phase

For Vague Idea:

1. Clarifying questions to understand the kernel of the idea
2. SCAMPER — Systematically explore modifications and variations
3. Reverse Brainstorming — "How could we make this fail?" then invert
4. Analogical Thinking — "How would [company/domain] approach this?"
5. → Convergent phase

For Clear Idea Needing Design:

1. Six Thinking Hats — Explore from all perspectives
2. Morphological Analysis — Break into dimensions, combine options
3. → Convergent phase (lighter, since idea is already focused)

For Improving Existing:

1. SCAMPER — What can be substituted, combined, adapted, modified, eliminated, reversed?
2. 5 Whys — What's the root cause of what needs improving?
3. TRIZ (if technical contradiction exists) — Systematic inventive problem solving
4. → Convergent phase

For Already Has Ideas:

1. Skip divergent phase (or brief expansion with analogical thinking)
2. → Jump directly to convergent phase

Phase 5: Divergent Phase Discipline

During ideation:

• Announce the mode: "We're in idea generation mode — all ideas are welcome, no filtering yet."
• Never evaluate during generation: If the user says "that won't work," redirect: "Good concern — let's capture that for evaluation. What else comes to mind?"
• Build, don't redirect: Use "Yes, and..." to build on user ideas
• Capture everything: Keep a running list of all ideas generated
• Know when to stop: When ideas start repeating or becoming incremental, it's time to converge

Phase 6: Convergent Phase

Reference references/evaluation-frameworks.md for detailed framework instructions.

1. Present the complete idea list: "We've generated [N] ideas. Let's evaluate them."
2. Select appropriate framework based on situation
3. Walk through evaluation with the user
4. Optionally dispatch idea-challenger agent for top candidates
5. Narrow to 2-3 finalist approaches

Phase 7: Design & Output

Delivering the output — one file, the user picks where

Brainstorming usually happens before a repo exists, and even inside one, scattered brainstorm files become doc drift. So: every output is one self-contained markdown file, and you ask where to deliver it (AskUserQuestion or a plain question) with three options:

1. Personal folder (default for non-project and pre-repo topics) — suggest ~/Documents/Brainstorms/YYYY-MM-DD-<topic>.md (Windows: %USERPROFILE%\Documents\Brainstorms\); the user can name any path. On Claude Desktop / Cowork / claude.ai, also surface the file itself so it can be saved or downloaded directly.
2. Into the current project (only when the topic IS that project) — a dated doc under docs/ (suggest docs/YYYY-MM-DD-<topic>-spec.md — the -spec.md suffix is what /rad-planner:plan's pre-fill looks for), with a header marking it transient: "Brainstorm output — consumed by /rad-planner:plan; archive after planning." The repo's doc-hygiene tooling (rad-repo-manager) will later flag it for archiving — that is the designed lifecycle, not drift. Never write to docs/design.md (that file is brand / UI/UX design direction, not brainstorm output).
3. No file — keep the output in the conversation only.

Never auto-commit. If the file landed in a repo, the user commits via their normal flow.

Output rules (all domains)

• "Considered and rejected" section — every delivered output includes one: the alternatives that were ruled out, each with a one-line why. The implementing agent (or future you) should see what was ruled out and why.
• Rejected + parked ideas → docs/ideas.md — when delivering into a repo that has a docs/ideas.md, also append rejected and parked ideas there, each with its one-line "why rejected/parked." This is the anti-re-proposing shelf — the ideas counterpart of decisions.md. No docs/ideas.md? The spec's "Considered and rejected" section carries them.
• No placeholders — "TBD," "add appropriate error handling," "similar to X" are named failures. Every requirement in the output is concrete or explicitly deferred with a reason.
• Vocabulary quarantine (in-repo sessions) — inside a repo, brainstorm output never uses Release/Milestone/Task terms and never emits plan-shaped artifacts; all sequencing routes to /rad-planner:plan. Out-of-repo sessions (trips, content plans, life stuff) may produce action plans freely.

Adapt the output format to the domain:

Software Projects

• Present design section by section, get approval after each
• Cover: architecture, components, data flow, error handling, testing
• Deliver the spec per the rule above (in-project option 2 is the usual choice — /rad-planner:plan reads it from there)
• Spec review: inline self-review checklist, then at most one spec-reviewer dispatch (see below)
• User reviews spec
• Transition: hand off to /rad-planner:plan for implementation planning — rad-planner v7+ pre-fills its discovery interview from this spec, so the user won't be re-asked what the spec already answers. If rad-planner is not installed, surface this to the user and suggest installing it.

Spec Review

1. Inline self-review first (free, always). Before any agent dispatch, check the spec yourself:

• Placeholder scan — any "TBD", "TODO", "add appropriate...", "similar to X"?
• Internal-contradiction check — does any section conflict with another?
• Scope check — does anything exceed what was agreed with the user?
• Ambiguity check — could any requirement be read two ways? Pick one and state it.

Fix what the self-review finds.

2. At most one spec-reviewer dispatch. Then dispatch spec-reviewer once with the substituted references/subagent-prompts/spec-review.md template. Parse the JSON response:

• status: approved → proceed to user review
• status: issues_found → fix the blocking issues, then surface the review to the user: "Spec review found these issues; I've addressed them. Want another review round, or shall we proceed to your review?" Further reviewer rounds only if the user asks.

Business/Strategy

• Present as a strategic brief
• Cover: value proposition, target audience, competitive positioning, key risks, next steps
• Deliver per the rule above (suggest YYYY-MM-DD-<topic>-strategy.md)
• Transition: action plan with concrete next steps (out-of-repo only — see vocabulary quarantine)

Product Discovery

• Present as Opportunity Solution Tree or lean canvas
• Cover: target outcome, opportunities, solution candidates, experiments to run
• Deliver per the rule above (suggest YYYY-MM-DD-<topic>-discovery.md)
• Transition: experiment plan

Content/Marketing

• Present as content strategy
• Cover: audience, topics, channels, differentiation, content calendar
• Deliver per the rule above (suggest YYYY-MM-DD-<topic>-content.md)
• Transition: editorial plan (out-of-repo; if this is a repo's content, sequencing routes to /rad-planner:plan)

General Problem-Solving

• Present as action plan
• Cover: root cause, solution approach, steps, risks, success criteria
• Deliver per the rule above (suggest YYYY-MM-DD-<topic>-plan.md)
• Transition: next steps with owners and timelines (out-of-repo only — see vocabulary quarantine)

Key Principles

• One question at a time — Don't overwhelm with multiple questions
• Multiple choice preferred — Lower cognitive load than open-ended when possible
• Anti-anchoring always — User ideas first, yours second
• Phase discipline — Never mix divergent and convergent modes
• YAGNI ruthlessly — Remove unnecessary complexity from all outputs
• Explore alternatives — Always generate multiple options before settling
• Incremental validation — Present output in sections, get approval before moving on
• Be flexible — Go back and re-explore when something doesn't make sense
• Adapt to energy — If user is stuck, switch techniques. If flowing, stay out of the way.
• Domain-aware — Research when needed, adapt output to domain

Working in Existing Codebases (Software)

• Explore current structure before proposing changes. Follow existing patterns.
• Where existing code has problems that affect the work, include targeted improvements as part of the design.
• Don't propose unrelated refactoring. Stay focused on the goal.

Large Project Decomposition

Before asking detailed questions, assess scope. If the request describes multiple independent subsystems:

1. Flag it immediately
2. Help decompose into sub-projects: independent pieces, relationships, build order
3. Brainstorm the first sub-project through the normal flow
4. Each sub-project gets its own brainstorm → spec → plan cycle