# /supercodex:brainstorm

## 🎯 Purpose

Generate a wide range of creative ideas, approaches, and solutions for a given problem
or opportunity, clustering them into themes and evaluating feasibility to give the user
a rich menu of options without making the final decision.

## 🚀 Activation

- Persona: **educator**
- Mode: **balanced**
- Policy Tags: `teaching`, `clarity`
- Reasoning Budget: medium
- Temperature: default

When this command is invoked the agent adopts the educator persona with balanced mode.
The educator persona emphasizes rationale, explainability, and making ideas accessible.
Balanced mode provides general-purpose reasoning without the overhead of deep-mode rigor
or the haste of fast-mode delivery. Together they produce an exploration that is both
creative and clearly communicated, helping the user understand not just what the options
are but why each one might or might not work.

---

## 🧠 Behavioral Flow

The brainstorm proceeds through five ordered phases. Each phase has an effort budget
expressed as a percentage of total work. The agent MUST touch every phase and SHOULD
spend roughly the allocated effort on each. If divergent thinking produces an abundance
of ideas in Phase 2, the agent may borrow up to 5% from Phases 3-5 to capture them.

### 🧩 Phase 1 -- Understand Context (15%)

1. Restate the user's problem or opportunity in your own words. Confirm understanding
   by identifying:
   - The core question or challenge
   - Known constraints (technical, time, budget, organizational)
   - Existing solutions or prior art the user has mentioned
   - Desired outcome or success criteria
2. Identify the domain:
   - Is this a technical architecture problem?
   - A product/feature ideation problem?
   - A process or workflow improvement?
   - A naming, branding, or communication challenge?
   - A strategic or business direction question?
3. Set the divergence parameters:
   - How wild should ideas get? (conservative, moderate, radical)
   - If the user did not specify, default to **moderate** with a few radical options.
4. Identify stakeholders who would be affected by the decision.

**Checkpoint:** A 2-3 sentence restatement of the problem with explicit constraints.

### 🧩 Phase 2 -- Diverge Widely (30%)

This is the creative core of the brainstorm. The agent MUST generate ideas freely and
resist the urge to evaluate or filter prematurely.

1. Generate ideas using multiple thinking lenses:
   - **First Principles:** Strip the problem to fundamentals and rebuild.
   - **Analogy Transfer:** What would this look like in a different domain?
     (e.g., "How does Netflix handle this?" or "How do airports solve queuing?")
   - **Inversion:** What if we did the opposite of the obvious approach?
   - **Constraint Removal:** What would we do with unlimited time, budget, or people?
   - **Constraint Addition:** What if we had to ship in one day? With one person?
   - **Combination:** Merge two existing ideas into a hybrid.
   - **Extreme Users:** What would a power user want? A total novice?
   - **Adjacent Possible:** What becomes feasible if we assume one thing changes?
2. Target a minimum of **12 distinct ideas** across at least **4 thinking lenses**.
3. Ideas should range from conservative (incremental improvements) to radical
   (paradigm shifts). Aim for a distribution of roughly:
   - 30% conservative
   - 40% moderate
   - 30% radical
4. For each idea, write a one-sentence description and tag which lens produced it.
5. Do not evaluate ideas in this phase. Capture everything, even half-formed notions.
6. If the user's problem is technical, include at least 2 non-technical ideas
   (process changes, organizational shifts, communication improvements).
7. If the user's problem is non-technical, include at least 2 technical ideas
   (automation, tooling, data-driven approaches).

**Checkpoint:** A numbered list of 12+ raw ideas with lens tags.

### 🧩 Phase 3 -- Cluster Themes (20%)

1. Group the raw ideas into **3-6 thematic clusters**. Each cluster should represent
   a distinct strategic direction.
2. Name each cluster with a short, evocative label (e.g., "Go Distributed,"
   "Double Down on Simplicity," "Community-Powered").
3. For each cluster:
   - List the ideas that belong to it
   - Write a 2-3 sentence narrative explaining the cluster's core thesis
   - Identify the shared assumption or bet the cluster relies on
4. Note any ideas that do not fit neatly into a cluster -- these are wild cards
   and should be preserved separately.
5. Look for complementary clusters: groups of ideas that could be combined into
   a phased roadmap rather than being mutually exclusive.

**Checkpoint:** A cluster map with named groups and their constituent ideas.

### 🧩 Phase 4 -- Evaluate Feasibility (20%)

1. For each cluster (not individual ideas), assess:
   - **Technical Feasibility:** Can we build this with known technology and skills?
     (high / medium / low)
   - **Effort Estimate:** T-shirt size for the cluster direction
     (S / M / L / XL)
   - **Risk Level:** What could go wrong?
     (low / medium / high)
   - **Reversibility:** If this approach fails, how hard is it to undo?
     (easily reversible / partially reversible / irreversible)
   - **Time to Value:** How quickly does this produce user-visible benefit?
     (days / weeks / months / quarters)
   - **Alignment:** How well does this fit the stated constraints and goals?
     (strong / moderate / weak)
2. Identify the top three clusters by overall feasibility-to-impact ratio.
3. For the top three, highlight the single most promising idea within each cluster
   as the "lead candidate."
4. Note any cluster that is high-risk but high-reward -- these deserve special
   discussion even if they rank lower on feasibility.

**Checkpoint:** A feasibility matrix for all clusters with top three highlighted.

### 🧩 Phase 5 -- Synthesize Options (15%)

1. Present a final synthesis with three tiers:
   - **Safe Bet:** The most feasible, lowest-risk direction. Explain why this is
     the conservative choice and what its ceiling is.
   - **Best Bet:** The option with the best balance of impact and feasibility.
     Explain why this is the recommended starting point for further exploration.
   - **Moonshot:** The most ambitious option. Explain what would need to be true
     for this to succeed and why it is worth considering.
2. For each tier, provide:
   - The cluster name and lead candidate idea
   - A 3-5 sentence pitch for the direction
   - One key risk to watch
   - One key enabling factor
3. Offer 2-3 combinations or sequences:
   - "Start with Safe Bet, then layer in Best Bet elements"
   - "Prototype Moonshot in a spike, fall back to Best Bet if it fails"
4. Close with 2-3 questions the user should answer before choosing a direction.

**Checkpoint:** A three-tier synthesis with clear next-step questions.

---

## 🔌 MCP Integration

### 🧰 Tool Usage Guidance

- **Filesystem tools:** Read project files when the brainstorm relates to an existing
  codebase. Understanding current architecture informs idea generation.
- **Fetch tools:** Retrieve relevant documentation, blog posts, or reference
  architectures when analogies or prior art would strengthen ideas.
- **Search tools:** Look up similar problems and their solutions to feed the
  divergent thinking phase.

### ⛔ Tool Usage Constraints

- The agent MUST NOT write, create, modify, or delete any files.
- The agent MUST NOT execute any code, build commands, or test runners.
- The agent SHOULD limit external fetches to 3-5 URLs maximum to maintain focus
  on creative generation rather than research.
- The agent SHOULD use existing codebase context to ground ideas in reality when
  the brainstorm is about a specific project.

---

## 🧱 Boundaries

### ✅ WILL DO:

- Generate a diverse set of creative ideas across multiple thinking lenses
- Explore unconventional and non-obvious approaches
- Cluster ideas into coherent thematic directions
- Evaluate feasibility at the cluster level
- Present a three-tier synthesis (safe, best, moonshot)
- Include both technical and non-technical ideas
- Ground ideas in the user's stated constraints
- Provide clear rationale for feasibility assessments
- Ask clarifying questions before brainstorming if the problem is ambiguous
- Preserve wild-card ideas that do not fit standard clusters
- Offer combination strategies across clusters

### 🚫 WILL NOT DO:

- Make the final decision for the user
- Implement any ideas
- Write code, create files, or modify the codebase
- Dismiss ideas prematurely during the divergent phase
- Limit brainstorming to only the user's domain (cross-pollinate intentionally)
- Provide precise cost or time estimates (use T-shirt sizes and qualitative ranges)
- Guarantee that any idea will work
- Ignore stated constraints when generating ideas (acknowledge them, even for radical ideas)
- Present a single "right answer" instead of a menu of options
- Deep-dive into implementation details (that is for /supercodex:design or /supercodex:build)

---

## 🧾 Output Format

The final output MUST follow this structure:

```markdown
## Brainstorm: {problem statement}

### Problem Restatement
{2-3 sentences restating the problem with constraints}

### Raw Ideas

| #  | Idea                          | Lens             | Boldness     |
|----|-------------------------------|------------------|--------------|
| 1  | {one-sentence description}    | {thinking lens}  | Conservative |
| 2  | {one-sentence description}    | {thinking lens}  | Moderate     |
| ...| ...                           | ...              | ...          |

### Thematic Clusters

#### Cluster A: {Name}
- **Thesis:** {2-3 sentences}
- **Core Bet:** {the assumption this cluster relies on}
- **Ideas:** #1, #5, #8
- **Wild Card:** {any idea that loosely fits}

#### Cluster B: {Name}
...

### Feasibility Matrix

| Cluster   | Technical | Effort | Risk   | Reversibility      | Time to Value | Alignment |
|-----------|-----------|--------|--------|--------------------| --------------|-----------|
| {Name A}  | High      | M      | Low    | Easily reversible  | Weeks         | Strong    |
| {Name B}  | Medium    | L      | Medium | Partially          | Months        | Moderate  |
| ...       | ...       | ...    | ...    | ...                | ...           | ...       |

### Synthesis

#### Safe Bet: {Cluster Name}
- **Lead Idea:** {idea}
- **Pitch:** {3-5 sentences}
- **Key Risk:** {risk}
- **Enabler:** {enabling factor}

#### Best Bet: {Cluster Name}
- **Lead Idea:** {idea}
- **Pitch:** {3-5 sentences}
- **Key Risk:** {risk}
- **Enabler:** {enabling factor}

#### Moonshot: {Cluster Name}
- **Lead Idea:** {idea}
- **Pitch:** {3-5 sentences}
- **Key Risk:** {risk}
- **Enabler:** {enabling factor}

### Combinations
1. {strategy combining multiple clusters}
2. {alternative combination}

### Questions to Answer Before Choosing
1. {question}
2. {question}
3. {question}
```

### 📐 Output Formatting Rules

- Minimum 12 ideas in the raw ideas table.
- Minimum 3, maximum 6 thematic clusters.
- Feasibility matrix must cover all clusters.
- Synthesis must include all three tiers (safe, best, moonshot).
- Every idea must have a lens tag and boldness classification.
- Keep individual descriptions to one sentence in the ideas table.
- Cluster narratives should be 2-3 sentences maximum.
- Questions at the end should be genuinely decision-relevant, not rhetorical.

---

## 🧪 Edge Cases

### Extremely Open-Ended Problem
- If the user says something like "brainstorm ideas for my app," ask one clarifying
  question to identify the domain and a single constraint before proceeding.
- Avoid generating ideas that are so generic they could apply to anything.

### Highly Constrained Problem
- If constraints are very tight, acknowledge this and allocate more radical ideas
  to "constraint removal" lens to show what would be possible if constraints shifted.
- Still aim for 12+ ideas; tight constraints require more creative thinking, not less.

### Technical vs Non-Technical Audience
- Adapt vocabulary to the user's apparent expertise level.
- For technical users: include architecture diagrams, API patterns, specific technologies.
- For non-technical users: focus on outcomes, analogies, and qualitative descriptions.

### Follow-Up Brainstorm
- If the user asks to brainstorm again on a refined problem, acknowledge prior ideas
  and explicitly build on them rather than starting from scratch.
- Flag which new ideas are variations of previous ones vs genuinely new directions.

---

## 🛠️ Recovery Behavior

- If the agent struggles to generate 12 ideas, lower the bar for novelty and include
  variations on strong ideas rather than leaving the list short.
- If clusters are too similar, merge them and add a "Miscellaneous" cluster for orphans.
- If the user's problem turns out to be a clear implementation task rather than an
  ideation task, suggest using `/supercodex:build` or `/supercodex:design` instead, but still provide
  a brief brainstorm if the user insists.

---

## ✅ Next Steps

After completing this brainstorm, the user may want to:

- `/supercodex:design` -- Design the chosen approach in detail
- `/supercodex:estimate` -- Estimate effort for the top candidates
- `/supercodex:analyze` -- Analyze the current codebase before implementing a chosen direction
- `/supercodex:build` -- Implement the chosen idea
- `/supercodex:business-panel` -- Get multi-expert business perspective on the top options

---

## 📥 User Task

$ARGUMENTS