brainstorming

name	brainstorming
description	Use this skill when the user asks to "brainstorm", "brainstorm ideas", "generate ideas about", "what options do we have for", "explore solutions", "ideation session", "lluvia de ideas", "hacer un brainstorming", "generar ideas", "explorar opciones", "qué alternativas tenemos", or mentions "brainstorm" while solving a technical problem, designing a feature, choosing an approach, shaping a product idea, or making a strategic decision. This skill turns unclear ideas into options, tradeoffs, and a Markdown design brief. Do not use it for implementation after a direction is already chosen, normal code review, factual Q&A, commit messages, or premortems.
license	MIT
metadata	{"version":"0.1.0"}

Structured Brainstorming

Brainstorming turns a fuzzy goal into a clearer set of options before the user commits to a path. It separates exploration from evaluation: first understand the context and generate possibilities, then compare tradeoffs and converge on a concrete next step or Markdown design brief.

When To Apply

Apply when the user needs to discover, compare, or shape options:

• Designing a feature when the solution space is not clear
• Choosing between technical approaches, architectures, or tradeoffs
• Naming domain concepts, services, APIs, modules, or products
• Exploring solutions to an ambiguous operational or product problem
• Planning a sprint, experiment, or roadmap item with multiple possible paths
• Turning a rough idea into a lightweight design brief before implementation

Do not use when:

• The user already chose an implementation and wants execution
• The user asks for a code review, debugging help, or factual answer
• The user asks for a premortem; use the relevant premortem skill only if explicitly invoked
• The user asks for a commit message; use commit-message

Core Rules

• Explore context before asking questions.
• Ask one focused question at a time when context is missing.
• Prefer multiple-choice questions when options are clear.
• Do not evaluate ideas during divergence.
• Always propose alternatives with tradeoffs before recommending a path.
• End with either next steps or a Markdown design brief.
• Do not generate HTML reports; keep outputs in Markdown.

Workflow

Phase 1: Explore Context

Before asking the user anything, scan available context:

• Current conversation
• Files, docs, or snippets the user referenced
• Relevant project files when working inside a repo
• Existing constraints, patterns, design systems, or architecture notes

Do not over-search. Gather enough to avoid asking questions the environment can answer.

If the request describes multiple independent subsystems, pause and decompose it before brainstorming details. Name the pieces, explain the dependency order, and start with the first sensible subproblem.

Phase 2: Frame The Problem

Restate the problem as a focused "How might we..." question.

Good frames:

• "How might we sync inventory with the ERP without downtime?"
• "How might we reduce initial app load below 2 seconds on slow networks?"
• "How might we let customers see order history without requiring a full login?"

Bad frames:

• "Improve performance" - too vague
• "Add Redis caching" - prescribes a solution too early
• "Build the platform" - too broad for one brainstorm

Identify constraints that should shape the brainstorm:

• Time, budget, or team capacity
• Existing tech stack or architecture
• Business, compliance, or customer constraints
• Reversibility and rollout constraints
• Success criteria and non-goals

If the frame, audience, success criteria, or hard constraints are missing and cannot be inferred, ask one focused question. Continue only once there is enough context for useful ideas.

Phase 3: Diverge Without Judgment

Generate at least 6 ideas unless the user asks for quick mode. Keep each idea to one sentence and do not score, rank, or critique yet. Quality over quantity — stop when you run out of meaningfully different ideas, not when you hit a number.

Use these lenses:

Conventional ideas - Obvious solutions worth naming because they set the baseline.

Constraint-driven ideas - What changes if time, budget, latency, staffing, or compatibility is the dominant constraint?

Extreme ideas - Push a constraint to its limit: 10x faster, no backend change, no user training, zero downtime, no manual support.

Inversions - Instead of making the task easier, make it unnecessary. Instead of handling invalid input faster, prevent invalid input from existing.

Analogies - Borrow patterns from adjacent domains: logistics, healthcare, games, marketplaces, banking, support ops, or developer tools.

Do not pad the list. If there are only 8 good ideas, stop at 8 and say why.

Phase 4: Cluster And Compare

Group related ideas into named approaches. Score promising ideas 1-3 on:

• Impact - how much it moves the success metric
• Feasibility - how realistic it is under current constraints
• Reversibility - how cheaply the team can undo or pivot

Then select 2-4 approaches for deeper comparison. For each approach:

### [Approach Name]

**What it is:** [One sentence.]
**Best when:** [Situation where this approach wins.]
**Tradeoffs:** [2-3 bullets.]
**Risks:** [2-3 bullets.]
**Smallest useful test:** [Action completable in less than a day when possible.]
**Discard if:** [Concrete signal that this path is not worth pursuing.]

Lead with the recommended approach unless the user explicitly wants a neutral list.

Phase 5: Converge

End with one of these outputs depending on the user's request:

Option A - Decision Summary

## Recommendation

Choose [approach] because [reason tied to constraints].

## Why Not The Others

- [Rejected approach]: [specific reason]

## Next Step

[One concrete action, owner if known, and expected learning.]

Option B - Markdown Design Brief

Use this when the brainstorm is about a feature, workflow, architecture, product idea, or implementation path:

# Design Brief: [Title]

## Goal
[What we are trying to achieve.]

## Context
[Relevant facts, constraints, and assumptions.]

## Recommended Approach
[The chosen approach and why.]

## Alternatives Considered
- [Alternative]: [why it was not chosen]

## User / System Flow
[Step-by-step behavior or data flow.]

## Edge Cases And Failure Modes
[Important cases to handle.]

## Open Questions
- [Only questions that materially affect implementation.]

## Next Steps
- [ ] [Concrete action]

Do not save a design file unless the user explicitly asks for a file or artifact.

Quick Mode

If the user says "quick brainstorm" or clearly needs speed:

1. Reframe the problem in one sentence.
2. Generate 6-8 ideas.
3. Mark the top 2-3 with a short rationale.
4. Give one concrete next step for each top idea.

Skip deeper facilitation unless the user asks to continue.

Async Mode

If the user wants a distributed/team brainstorm, produce a paste-ready Markdown template:

# Async Brainstorm: [How might we...?]

## Context
[Problem, constraints, success criteria.]

## Instructions
1. Add ideas without evaluating them.
2. Keep each idea to 1-2 sentences.
3. Add risks or constraints only after idea collection closes.
4. Close submissions by [date].

## Ideas

### [Participant]
-

## Clusters
- [Cluster name]:

## Vote
Vote on impact, feasibility, and reversibility.

## Decision
[Chosen path, owner, next step.]

Quality Bar

• Make the brainstorm specific to the user's context.
• Protect divergent thinking before evaluation.
• Avoid fake choice: alternatives must be meaningfully different.
• Avoid "it depends" endings; make a recommendation when enough context exists.
• Keep Markdown scannable and ready to paste into docs, tickets, or planning notes.