Brainstorm

Step 1 — Load Context (if --context given)

# File context
cat "<file>" 2>/dev/null | head -100

Or read the file with the Read tool. Extract the relevant constraints and requirements.

Step 2 — Devil's Advocate Analysis (default and both modes)

Produce structured critique across these dimensions:

A. What Could Break

Think about: failure modes, race conditions, edge cases, load scenarios, error propagation.

• List 3-5 concrete failure scenarios
• For each: what breaks, what's the blast radius, how detectable is it?

B. What's Not Considered

Think about: security, scalability, operability, cost, backward compatibility, developer experience, team expertise.

• What assumptions does this proposal implicitly make?
• What's left undefined that will cause pain later?

C. Counter-Arguments

If this proposal is arguing for approach X over Y:

• What are the strongest arguments for Y?
• What evidence exists that X fails in similar contexts?
• Is there a consensus in the field that contradicts this approach?

D. Questions to Validate First

Before committing to this proposal, what needs to be answered?

• List 3-5 questions ordered by risk (biggest unknown first)
• Format: Q: <question> | Risk if wrong: <consequence>

Step 3 — Exploration (explore and both modes)

Alternative Approaches

Generate 2-4 genuinely different approaches to the same problem:

For each alternative:

### Alternative: <name>
**Core idea:** <one sentence>
**Strengths:** <what this does better than the proposal>
**Weaknesses:** <what this does worse>
**Best fit when:** <conditions where this wins>

Adjacent Ideas

What adjacent patterns or tools exist that the user may not have considered?

• These are not full alternatives but worth knowing about

Historical Context

Have others tried this approach? What was the outcome?

• Reference real-world cases if known (don't invent)
• If no known cases, say so

Step 4 — Output

If --mode devils-advocate:

# Devil's Advocate: <proposal summary>

## What Could Break
1. <failure scenario 1> — blast radius: <scope> — detection: <easy/hard>
2. ...

## What's Not Considered
- <gap 1>
- <gap 2>

## Strongest Counter-Arguments
- <counter 1>
- <counter 2>

## Validate These First
| Priority | Question | Risk if Wrong |
|----------|----------|---------------|
| 1 | <question> | <consequence> |
| 2 | ... | ... |

## Verdict
<Is this a strong proposal with manageable risks, or does it need more work before committing?>
<One paragraph. Constructive — the goal is to strengthen the proposal, not kill it.>

If --mode explore:

# Alternatives: <proposal summary>

## Alternative 1: <name>
...

## Alternative 2: <name>
...

## Adjacent Ideas
- ...

## Historical Context
- ...

## Recommendation
<Which alternative (or the original) looks strongest given the stated context, and why?>

If --mode both:

Produce both sections above in sequence.

Tone Rules

• Be constructive, not dismissive. The goal is to make the proposal stronger, not to kill it.
• Be specific. "This could have performance issues" is useless. "At 10k concurrent users, this will saturate the single Redis connection because X" is useful.
• Source claims when possible. If you assert that approach X fails at scale, cite a known case.
• Don't manufacture problems. Only raise issues that are plausible given the stated context. Hypothetical edge cases that require malicious actors or hardware failures should be labeled as such.
• End with a verdict. Don't leave the user with a list of problems and no synthesis.

Examples

/brainstorm We should use Redis for session storage instead of JWT

/brainstorm --mode both Refactor the auth module from cookie-based to token-based sessions

/brainstorm --mode explore We need a background job system for sending emails

/brainstorm --context ./docs/adr-012.md Migrate from monolith to microservices