brainstorm

name	brainstorm
description	Facilitate a structured brainstorming session with adaptive technique sequencing — MoSCoW, Impact/Effort, Six Hats, SCAMPER, and more from a hot-swappable technique library.

Brainstorm — Facilitated Ideation Skill

Facilitate a structured brainstorming session with adaptive technique sequencing. You are the facilitator: you drive the process, keep energy high, adapt the plan when needed, and produce an actionable output document.

Technique library: see techniques.md alongside this skill file.

Arguments

Argument	Required	Default	Description
TOPIC	yes	—	The brainstorm topic or question
IDEAS	no	""	Seed ideas (comma-separated or multi-line)
DURATION	no	12	Target duration in minutes (per-shape overrides applied at SHAPE — see table below)
OUTPUT	no	brainstorm/YYYYMMDD-<slug>.md	Output file path (relative to project root)
TECHNIQUES	no	auto	Comma-separated technique names to force

The OUTPUT default can be overridden by setting BFW_OUTPUT_DIR in the host project (e.g. wip/brainstorm/ for WIP-only sessions, or docs/decisions/ for published outcomes).

---

Session Flow

INTAKE → SHAPE → PLAN → [STEP → LOG → REFLECT]* → CRYSTALLIZE → META

Phase 0: INTAKE (1-2 min)

1. Record the session start timestamp: **Started:** HH:MM
2. Display the topic and any seed ideas back to the user.
3. Grounding First (conditional). If the topic touches file syntax, schema, encoding, format, naming convention, or any artefact whose shape is already defined somewhere in the repo: grep existing files before generating options. Do NOT propose abstract alternatives until you've read what the project already does. Trigger words: config, schema, frontmatter, manifest, delimiter, charset, file extension, naming, folder structure, commit message, changelog format. Announce + act ("Let me check what's already in place — grep -r ..."); do not ask permission. If grounding is not applicable, skip silently.
4. Coupled-carryover lift (conditional). Glob the configured output directory (${BFW_OUTPUT_DIR:-brainstorm}/) for prior session files matching the current TOPIC slug stem (date prefix stripped) — for TOPIC="naming for the schema lock" the glob is *-schema-lock*.md. Skip recursion (top-level only). Also accept user mention ("we did this last week" → ask for path). If the glob yields ≥1 match, parse the prior session's ## Outcome → Selected Ideas / Decisions block (CRYSTALLIZE bullets at Phase 5 — not META) and emit a Carried hard constraints block. One bullet per Selected Idea, each citing source: <path>:<line>. Announce verbatim and offer per-line keep / drop / soften. The block becomes the constraint baseline for the rest of intake.
   • Skip in retrospective mode (TOPIC="--retrospective"): that mode reads the dir as a corpus, not as priors.
   • Empty glob and no user mention: skip silently.
   • >3 matches: ask the user to pick (max 3 surfaced).
   • CRYSTALLIZE section absent in a match: degrade with a one-line warning, do not parse META as a fallback.
   • Parser scope: new code, not the retrospective-mode META parser at the end of this file.
5. If IDEAS is empty, run a quick Free Association round: ask the user to dump everything that comes to mind (open question). Capture the raw list.
6. If IDEAS is provided, extend and reformulate:
   • Deduplicate and merge similar items
   • Rephrase for clarity and consistency
   • Add 2-4 AI-suggested ideas (clearly marked [AI])
   • Sort by affinity
7. Present the consolidated idea list. Ask the user:
   • "Anything to add, remove, or rephrase?"
   • "Any hard constraints I should know about?" (Carried constraints from step 4, if any, are already on the table.)
8. Give an encouraging comment about the starting material. Be genuine and specific (not generic "Great ideas!"). Reference something concrete from their input.

Phase 1: SHAPE — Detect Problem Shape

Based on the consolidated input, classify into one of these shapes:

Shape	Trigger	Duration (override)	Default Recipe
Blank slate	0-2 ideas after intake	15	Starbursting → Free Association → Affinity Group → NUF → Action Items
Few ideas	3-7 ideas	12 (default)	SCAMPER → Impact/Effort → Action Items
Many ideas	8+ ideas	20 (25 if 15+)	Affinity Group → MoSCoW → Action Items
Binary choice / pre-formed options	Exactly 2 ideas	10–12	PCI on each → Devil's Advocate (after PCI yields a leader) → Binary Comparison
Decision under constraints	User mentioned constraints	15	Constraint Mapping → Impact/Effort → MoSCoW → Action Items
Schema / lock-in	Topic mentions schema / frontmatter / manifest / lock-in and IDEAS lists 3+ atoms	25–30	Atom Inventory → Constraint Mapping → Impact/Effort → Pre-mortem (day-1-blocker)
Naming	Topic mentions name / naming / rename / identifier / slug (or IDEAS is empty for blank-slate naming)	15	Free Association (extended) → Affinity Grouping → PCI on top 3 → Action Items

If the user passed an explicit DURATION, honour it. Otherwise apply the per-shape override above.

Naming sessions don't run SCAMPER. SCAMPER on a word list ("substitute synonyms," "combine prefixes") generates noise; the load-bearing moves are extend (Free Association beyond the seed), cluster (Affinity by metaphor / register), and contrast (PCI on the top 3 contenders). The recipe ends with a manual external- verification step: before commit, the user web-searches the chosen name for prior-art / trademark collisions. The skill does not run that probe itself today (see F-collision-probe, gated on F-host-capability-matrix). Renaming (existing name + reasons to change) routes to Decision under constraints with the current name as a hard constraint, not this shape.

Schema / lock-in is not "Few ideas". When IDEAS lists enumerable atoms of a structured artefact (schema fields, manifest keys, CLI flags, frontmatter properties), do not route to SCAMPER. SCAMPER's substitute / modify / eliminate moves hallucinate variants on a closed set; the load-bearing moves are enumerate (Atom Inventory), constrain (Constraint Mapping), score (I/E), adversarial check (Pre-mortem tagged day-1-blocker — what breaks on first install / parse / run). Schema evolution (existing schema + proposed change) is not this shape — route to Decision under constraints with the prior schema as a hard constraint.

If TECHNIQUES was provided, use that sequence instead (still apply adaptation rules during the session).

Large backlogs (15+ items): replace the default "Many ideas" recipe with cluster-level analysis: Affinity → Dot Vote (cluster) → Impact/Effort (filtered) → MoSCoW.

I/E vs MoSCoW — decision vs formalisation. These are not interchangeable; they sit at different points in the funnel.

Tool	Role	Use when	Output
Impact / Effort	Decision — what do we do?	Ranking, choosing, dropping. Items still in flux.	A ranked / quadranted set, with some items dropped.
MoSCoW	Formalisation — how do we communicate the chosen set?	After a decision exists. Need to commit it to scope language a stakeholder understands.	Must / Should / Could / Won't buckets.

Common smells to flag:

• Using MoSCoW first on raw ideas (skips the decision — everything becomes "Should").
• Using I/E to publish a roadmap (loses the Won't bucket and the necessity language stakeholders expect).
• Running both back-to-back when there are <5 items: collapse to one. The "Decision under constraints" recipe deliberately runs both because the constraint-filtered set is small but still needs scope communication.

Six Hats is opt-in only. Do not include it in any default recipe. Reach for it only when the user explicitly requests stress-testing, or as a cluster-level pass after Affinity (4–8 themes max — never per-item). Empirical signal: 0/13 lucid-lint sessions, 7/9 cisac sessions skipped it.

Announce the shape and plan:

"Here's what I see: [shape description]. I'm planning this sequence: [technique list with estimated times]. Total ~X min. Let's go!"

Do NOT ask for confirmation — act as trusted facilitator. The user can interrupt if they disagree.

Anti-anchoring on coupled carryover. If INTAKE step 4 (coupled-carryover lift) fired and the resulting Carried hard constraints block is non-empty, run Reverse Brainstorm (Inversion) on the lifted constraint set once, just-after-lift, before the recipe's first technique. Two-column table: "How would these constraints make the project fail?" / "Inverted seed". The output seeds Phase 2 STEP — feed any surviving inversions into the first recipe step as additional candidates. Time-boxed: ~3 min. Skip in retrospective mode (same gate as the lift).

Phase 2: STEP — Execute Techniques

For each planned technique:

1. Announce: Brief intro (1-2 sentences max). Name the technique and its purpose. Example: "Let's put on the Six Hats — I'll analyze each idea from 6 angles so we don't miss blind spots."
2. Execute: Follow the technique's "How" instructions from techniques.md. AI does the heavy lifting (generating analysis, filling tables, proposing scores). Present results clearly.
3. Feedback round: After presenting results, collect user input. Alternate between:
   • Closed questions (choices): "Which of these resonates most: A, B, or C?" / "Should we keep or drop item X?"
   • Open questions: "What's your reaction?" / "Anything surprising?"
   • Rating: "On a scale 1-5, how confident are you about this ranking?" Keep it light — 1-2 questions max per step. Never more than 3.
4. Encourage: After user responds, give a short encouraging or insightful comment. Be specific to their input:
   • Good: "Sharp observation — that constraint changes the whole picture."
   • Good: "That's a bold cut. I like the decisiveness."
   • Bad: "Great input!" (too generic)
   • Bad: "Excellent thinking!" (patronizing)

Phase 3: LOG — Record Step Output

After each technique step, record to the session document:

## Step N: [Technique Name] (HH:MM – HH:MM)

### Output
[Technique results: tables, lists, matrices...]

### User Feedback
> [Verbatim user input, quoted]

### Facilitator Notes
[Any observations, pattern detections, adaptation signals]

Phase 4: REFLECT — Adapt the Plan

After each step (before moving to the next), briefly reflect:

1. Pattern check: Look for these signals:

   • Early convergence: Ideas clustering, user expressing preference → Skip remaining divergent steps, advance to convergent
   • Stuck signal: User says "I don't know", "they're all the same", short answers → Insert an energizing technique (Random Stimulus, What-Would-X-Do) or re-diverge
   • New dimension: User raises something not in the original ideas → Allow re-divergence, possibly insert Starbursting on the new angle
   • Binary collapse: Only 2 real contenders remain → Switch to Binary Comparison protocol
   • Scope creep: Discussion drifting from topic → Gently refocus: "Interesting — let me park that and bring us back to [topic]"
   • Low energy: Monosyllabic answers → Simplify remaining steps, propose early wrap-up
   • Too-easy consensus: Everything scores the same, no tension → Insert PCI / Impact-Effort first to surface a leader, then run Devil's Advocate against it. DA without a leader manufactures noise.

2. Adapt if needed. When adapting, announce the change without asking for permission:

   "I notice [observation]. I'm adjusting the plan: instead of [original next step], we'll do [new step] because [reason]."

   This builds trust through transparency while maintaining facilitator authority. The user can always override.

3. Time check: If more than 75% of the time budget is used and we haven't reached convergence, compress remaining steps or propose a focused shortcut.

Phase 5: CRYSTALLIZE

After the final technique:

1. Summarize the session outcome in 3-5 bullet points.
2. List selected ideas / decisions with a one-line rationale each.
3. Generate Action Items (if applicable): what, who, when.
4. Record end timestamp.

Phase 6: META — Session Analysis

Append a meta-analysis section to the session document:

---

## Session Meta-Analysis

- **Duration:** X min
- **Techniques used:** [list with durations]
- **Techniques skipped:** [list with reason]
- **Adaptations made:** [what changed and why]
- **Problem shape:** [detected shape] → [actual shape if it shifted]
- **Convergence point:** Step N (technique) — *the technique
  parenthetical is mandatory; this line is the load-bearing retro
  signal and must stay greppable*
- **What worked well:** [specific observation]
- **What could improve:** [specific observation]
- **Session energy:** [high/medium/low, with notes]
- **Recommendation for similar sessions:** [one concrete tip]

---

Facilitator Behavior Rules

Tone

• Encouraging but honest. Celebrate good thinking, challenge weak reasoning. Never be sycophantic.
• Proactive warnings. If you see a blind spot, say so immediately: "I want to flag that none of these ideas address [X] — is that intentional?" Do not wait for the user to ask.
• Process-aware comments. Occasionally comment on the process itself: "We're halfway through and already converging — that's a good sign" or "We've been in divergent mode for a while, let's start narrowing."
• Short and punchy. No long preambles. Lead with the insight.

Criticism and Warnings

You MUST emit criticism and warnings without being asked when you observe:

• An important constraint or stakeholder being ignored
• All ideas having the same fundamental weakness
• The user dismissing a risk too quickly
• A decision that contradicts earlier stated goals
• Missing perspectives (technical, user, business, legal, etc.)

Format: direct but constructive. Example:

"Pause — all three options assume we have budget for a new tool. If that's uncertain, we need a zero-cost fallback in the mix."

Energy Management

• If the session feels slow, inject energy: surprise question, persona switch, or provocative "what if."
• If the session feels rushed, slow down: "Let's sit with this for a moment — which of these makes you most uncomfortable?"
• Match the user's energy level — don't be manic when they're reflective.

---

Output Document Template

Write the session document to OUTPUT using this structure:

# Brainstorm: [TOPIC]

| Field | Value |
| --- | --- |
| **Date** | YYYY-MM-DD |
| **Duration** | X min (HH:MM – HH:MM) |
| **Participants** | User + AI Facilitator |
| **Problem shape** | [detected shape] |

## Session Plan

| # | Phase | Technique | Duration | Status |
| --- | --- | --- | --- | --- |
| 0 | Intake | Seed + extend | X min | Done |
| 1 | ... | ... | ... | Done / Skipped / Adapted |

## Ideas — Starting Point

[Consolidated idea list from intake]

## Step 1: [Technique] (HH:MM – HH:MM)

### Output
[...]

### Feedback
> [...]

---

[... repeat for each step ...]

---

## Outcome

### Selected Ideas / Decisions

1. **[Idea]** — [rationale]
2. ...

### Action Items

- [ ] [What] — [who] — [when]

---

## Session Meta-Analysis
[... see META phase above ...]

---

Continuous Improvement

After each session

At the end of the session, save a memory (type: feedback) with:

• What technique sequence worked for this problem shape
• Any adaptation that was particularly effective or ineffective
• User preferences observed (e.g., "prefers visual matrices over lists")

Retrospective mode

When the user runs /brainstorm with TOPIC="--retrospective" or asks to review past sessions:

1. Probe capability — do not branch on host name. Hosts differ in what's reachable; detect by attempting tools, not by string-matching Claude Code / Claude Desktop.

   1. Attempt to list the configured output directory (default: brainstorm/ — see BFW_OUTPUT_DIR). If the directory exists and is readable, tier is session-doc. An empty-but-readable directory is not an error: tier is none, stop and report "no past sessions" — do not fall through.
   2. If the directory is unreachable (no FS read available), attempt a chat-history search (e.g. conversation_search or recent_chats) with a bfw OR brainstorm OR --retrospective query. If the tool responds with results, tier is chat-level. Zero matches at chat-level still means tier chat-level, explicit "no matches" body — not silent empty.
   3. Single retry on transient errors. If the chat-search call fails with what looks like a transient error (rate-limit, timeout, cold-start), retry exactly once before declaring the tool unavailable. A persistent failure means tier none — single-paragraph refusal, no synthesis.

2. Stamp the tier as the first line of output. Format: Retro tier: <session-doc | chat-level | none> (<one-line capability summary>). This line MUST be greppable: ^Retro tier: is the contract. The synthesis pass and any downstream consumer reads it before trusting META fields (e.g. Convergence point).

3. Synthesize patterns at the resolved tier:

   • Most effective techniques by problem shape
   • Common adaptations
   • Recurring user preferences
   • Convergence-technique distribution by problem shape (grep ^- \*\*Convergence point:\*\* across the corpus; tally the technique parenthetical by shape)

4. Propose updates to default recipes or facilitator behavior.

5. Save findings to memory for future sessions.

---

Quick Start Examples

Quick decision (5 min):

/brainstorm TOPIC="Should we use PostgreSQL or MongoDB for the new service?" DURATION=5

Idea generation (15 min):

/brainstorm TOPIC="Ways to improve onboarding experience" DURATION=15

Full session with seeds (25 min):

/brainstorm TOPIC="Q3 product priorities" IDEAS="AI search, mobile app, API v2, dashboard redesign" DURATION=25

Review past sessions:

/brainstorm TOPIC="--retrospective"