Brainstorming
Structured pre-implementation design exploration. Transforms a vague idea into a written spec through focused, one-at-a-time questioning before any code is written, any plan is created, or any architecture is decided. The spec is the deliverable - everything else follows from it.
No code until the spec is written and approved.
When to Use
- The user says "I want to build X" but has no written requirements
- A feature request exists as a sentence or two with no detail
- The user asks "how should I build X" before defining what X actually is
- Someone says "let's brainstorm" or "help me figure this out"
- A problem statement exists but the solution space is unexplored
Quick Start
/brainstorming user authentication for a SaaS app
/brainstorming migrate our monolith to services
/brainstorming # asks what to explore
If $ARGUMENTS is provided, use it as the initial topic and skip straight to Phase 1. If no argument, ask: "What idea, feature, or problem would you like to explore?"
Workflow
This skill uses guided phases - each phase is a separate file loaded one at a time. Every phase ends with a gate where you must wait for user confirmation before proceeding. Do not skip phases or merge them.
| Phase |
File |
What it covers |
| 1 |
Intake |
Read context, classify maturity, summarize understanding |
| 2 |
Divergence |
Expand problem space with one-at-a-time questions across 7 categories |
| 3 |
Convergence |
Narrow to concrete scope, lock must-haves and non-goals |
| 4 |
Spec Writing |
Write full spec from gathered material, run quality checklist |
| 5 |
Approval |
Get explicit user approval, hard-gate implementation |
Start by loading Phase 1. After the user confirms each phase, load the next. Never load multiple phases at once. Never skip a phase.
Critical Rules
- No code until the spec is approved. Not pseudocode, not scaffolding, not "just a quick example."
- One question per message. Compound questions produce shallow answers.
- Open questions before closed questions. Explore before narrowing.
- Challenge assumptions, not people. "Is X a hard requirement, or an assumption we should test?"
- The user defines scope, not the agent. Surface possibilities through questions, let the user decide.
- Non-goals are as important as goals. A spec without explicit non-goals has undefined boundaries.
- Acceptance criteria must be testable. "It should be fast" is not testable. "Under 200ms at p95" is.
- Scale depth to complexity. Simple features get short specs. System redesigns get thorough ones.
- Resolve contradictions before locking scope.
- The spec is a living document until approved.
Question Technique
| Principle |
Meaning |
| One at a time |
One question, one message |
| Open before closed |
"What" and "why" first; "which" and "would you prefer" later |
| Challenge assumptions |
When something is stated as obvious, ask what would happen if it were not true |
| Surface constraints early |
Constraints eliminate solution space - the sooner known, the less rework |
| Offer options when narrowing |
Present 2-3 concrete choices instead of open-ended questions during convergence |
| Name the silence |
If an important topic has not come up, ask about it explicitly |
See question-playbook for the full catalog.
Anti-Patterns
| Anti-Pattern |
Fix |
| Solution jumping |
Stay in divergence until goals and constraints are clear |
| Compound questions |
One question per message |
| Leading questions |
Ask neutral: "What scale needs exist?" not "Should we use microservices?" |
| Premature implementation |
Hard-gate: no code until spec is approved |
| Fake consensus |
Probe: "Can you walk me through how you'd use this?" |
| Scope creep during convergence |
Park in "future considerations", re-lock scope |
See anti-patterns for the full guide.
Reference Files
| Reference |
Contents |
| question-playbook |
Full catalog of question types with example phrasings |
| spec-template |
Output template the spec must follow |
| anti-patterns |
Failure modes that derail brainstorming |
| when-to-exit |
Criteria for "done" vs. "needs more rounds" |
Integration with Other Skills
| Situation |
Recommended Skill |
| Spec approved, ready for planning |
writing-plans |
| Complex requirements, need stakeholder analysis |
product-manager role |
| Spec reveals architectural decisions needed |
architect role |
| Spec approved, ready for direct TDD |
test-driven-development |
| Acceptance criteria need test plan detail |
qa-engineer role |
| API design decisions |
api-design |
| Database schema decisions |
database-design |
1---2name: brainstorming3description: Interactive pre-implementation design exploration. Use when the user has a vague idea, feature request, or problem statement but no written spec. Asks focused questions one at a time to surface goals, non-goals, constraints, success criteria, and risks, then produces a written spec and hard-gates implementation until approved. Use before writing any code, before planning, and before answering 'how should I build X'. Triggers: 'I want to build', 'I'm thinking about', 'help me figure out', 'let's brainstorm', 'help me spec out'.4---56# Brainstorming78Structured pre-implementation design exploration. Transforms a vague idea into a written spec through focused, one-at-a-time questioning before any code is written, any plan is created, or any architecture is decided. The spec is the deliverable - everything else follows from it.910**No code until the spec is written and approved.**1112## When to Use1314- The user says "I want to build X" but has no written requirements15- A feature request exists as a sentence or two with no detail16- The user asks "how should I build X" before defining what X actually is17- Someone says "let's brainstorm" or "help me figure this out"18- A problem statement exists but the solution space is unexplored1920## Quick Start2122```23/brainstorming user authentication for a SaaS app24/brainstorming migrate our monolith to services25/brainstorming # asks what to explore26```2728If `$ARGUMENTS` is provided, use it as the initial topic and skip straight to Phase 1. If no argument, ask: "What idea, feature, or problem would you like to explore?"2930---3132## Workflow3334This skill uses **guided phases** - each phase is a separate file loaded one at a time. Every phase ends with a gate where you must wait for user confirmation before proceeding. Do not skip phases or merge them.3536| Phase | File | What it covers |37|---|---|---|38| 1 | [Intake](phases/01-intake.md) | Read context, classify maturity, summarize understanding |39| 2 | [Divergence](phases/02-divergence.md) | Expand problem space with one-at-a-time questions across 7 categories |40| 3 | [Convergence](phases/03-convergence.md) | Narrow to concrete scope, lock must-haves and non-goals |41| 4 | [Spec Writing](phases/04-spec-writing.md) | Write full spec from gathered material, run quality checklist |42| 5 | [Approval](phases/05-approval.md) | Get explicit user approval, hard-gate implementation |4344**Start by loading Phase 1.** After the user confirms each phase, load the next. Never load multiple phases at once. Never skip a phase.4546---4748## Critical Rules49501. **No code until the spec is approved.** Not pseudocode, not scaffolding, not "just a quick example."512. **One question per message.** Compound questions produce shallow answers.523. **Open questions before closed questions.** Explore before narrowing.534. **Challenge assumptions, not people.** "Is X a hard requirement, or an assumption we should test?"545. **The user defines scope, not the agent.** Surface possibilities through questions, let the user decide.556. **Non-goals are as important as goals.** A spec without explicit non-goals has undefined boundaries.567. **Acceptance criteria must be testable.** "It should be fast" is not testable. "Under 200ms at p95" is.578. **Scale depth to complexity.** Simple features get short specs. System redesigns get thorough ones.589. **Resolve contradictions before locking scope.**5910. **The spec is a living document until approved.**6061---6263## Question Technique6465| Principle | Meaning |66|---|---|67| **One at a time** | One question, one message |68| **Open before closed** | "What" and "why" first; "which" and "would you prefer" later |69| **Challenge assumptions** | When something is stated as obvious, ask what would happen if it were not true |70| **Surface constraints early** | Constraints eliminate solution space - the sooner known, the less rework |71| **Offer options when narrowing** | Present 2-3 concrete choices instead of open-ended questions during convergence |72| **Name the silence** | If an important topic has not come up, ask about it explicitly |7374See [question-playbook](references/question-playbook.md) for the full catalog.7576---7778## Anti-Patterns7980| Anti-Pattern | Fix |81|---|---|82| Solution jumping | Stay in divergence until goals and constraints are clear |83| Compound questions | One question per message |84| Leading questions | Ask neutral: "What scale needs exist?" not "Should we use microservices?" |85| Premature implementation | Hard-gate: no code until spec is approved |86| Fake consensus | Probe: "Can you walk me through how you'd use this?" |87| Scope creep during convergence | Park in "future considerations", re-lock scope |8889See [anti-patterns](references/anti-patterns.md) for the full guide.9091---9293## Reference Files9495| Reference | Contents |96|---|---|97| [question-playbook](references/question-playbook.md) | Full catalog of question types with example phrasings |98| [spec-template](references/spec-template.md) | Output template the spec must follow |99| [anti-patterns](references/anti-patterns.md) | Failure modes that derail brainstorming |100| [when-to-exit](references/when-to-exit.md) | Criteria for "done" vs. "needs more rounds" |101102## Integration with Other Skills103104| Situation | Recommended Skill |105|---|---|106| Spec approved, ready for planning | `writing-plans` |107| Complex requirements, need stakeholder analysis | `product-manager` role |108| Spec reveals architectural decisions needed | `architect` role |109| Spec approved, ready for direct TDD | `test-driven-development` |110| Acceptance criteria need test plan detail | `qa-engineer` role |111| API design decisions | `api-design` |112| Database schema decisions | `database-design` |
krzysztofsurdy