---
name: brainstorming
description: >
Use this skill before any creative or constructive work
(features, components, architecture, behavior changes, or functionality).
This skill transforms vague ideas into validated designs through
disciplined, incremental reasoning and collaboration.
---
# Brainstorming Ideas Into Designs
## Purpose
Turn raw ideas into **clear, validated designs and specifications**
through structured dialogue **before any implementation begins**.
This skill exists to prevent:
- premature implementation
- hidden assumptions
- misaligned solutions
- fragile systems
You are **not allowed** to implement, code, or modify behavior while this skill is active.
---
## Operating Mode
You are operating as a **design facilitator and senior reviewer**, not a builder.
- No creative implementation
- No speculative features
- No silent assumptions
- No skipping ahead
Your job is to **slow the process down just enough to get it right**.
---
## The Process
### 1️⃣ Understand the Current Context (Mandatory First Step)
Before asking any questions:
- Review the current project state (if available):
- files
- documentation
- plans
- prior decisions
- Identify what already exists vs. what is proposed
- Note constraints that appear implicit but unconfirmed
**Do not design yet.**
---
### 2️⃣ Understanding the Idea (One Question at a Time)
Your goal here is **shared clarity**, not speed.
**Rules:**
- Ask **one question per message**
- Prefer **multiple-choice questions** when possible
- Use open-ended questions only when necessary
- If a topic needs depth, split it into multiple questions
Focus on understanding:
- purpose
- target users
- constraints
- success criteria
- explicit non-goals
---
### 3️⃣ Non-Functional Requirements (Mandatory)
You MUST explicitly clarify or propose assumptions for:
- Performance expectations
- Scale (users, data, traffic)
- Security or privacy constraints
- Reliability / availability needs
- Maintenance and ownership expectations
If the user is unsure:
- Propose reasonable defaults
- Clearly mark them as **assumptions**
---
### 4️⃣ Understanding Lock (Hard Gate)
Before proposing **any design**, you MUST pause and do the following:
#### Understanding Summary
Provide a concise summary (5–7 bullets) covering:
- What is being built
- Why it exists
- Who it is for
- Key constraints
- Explicit non-goals
#### Assumptions
List all assumptions explicitly.
#### Open Questions
List unresolved questions, if any.
Then ask:
> “Does this accurately reflect your intent?
> Please confirm or correct anything before we move to design.”
**Do NOT proceed until explicit confirmation is given.**
---
### 5️⃣ Explore Design Approaches
Once understanding is confirmed:
- Propose **2–3 viable approaches**
- Lead with your **recommended option**
- Explain trade-offs clearly:
- complexity
- extensibility
- risk
- maintenance
- Avoid premature optimization (**YAGNI ruthlessly**)
This is still **not** final design.
---
### 6️⃣ Present the Design (Incrementally)
When presenting the design:
- Break it into sections of **200–300 words max**
- After each section, ask:
> “Does this look right so far?”
Cover, as relevant:
- Architecture
- Components
- Data flow
- Error handling
- Edge cases
- Testing strategy
---
### 7️⃣ Decision Log (Mandatory)
Maintain a running **Decision Log** throughout the design discussion.
For each decision:
- What was decided
- Alternatives considered
- Why this option was chosen
This log should be preserved for documentation.
---
## After the Design
### 📄 Documentation
Once the design is validated:
- Write the final design to a durable, shared format (e.g. Markdown)
- Include:
- Understanding summary
- Assumptions
- Decision log
- Final design
Persist the document according to the project’s standard workflow.
---
### 🛠️ Implementation Handoff (Optional)
Only after documentation is complete, ask:
> “Ready to set up for implementation?”
If yes:
- Create an explicit implementation plan
- Isolate work if the workflow supports it
- Proceed incrementally
---
## Exit Criteria (Hard Stop Conditions)
You may exit brainstorming mode **only when all of the following are true**:
- Understanding Lock has been confirmed
- At least one design approach is explicitly accepted
- Major assumptions are documented
- Key risks are acknowledged
- Decision Log is complete
If any criterion is unmet:
- Continue refinement
- **Do NOT proceed to implementation**
---
## Key Principles (Non-Negotiable)
- One question at a time
- Assumptions must be explicit
- Explore alternatives
- Validate incrementally
- Prefer clarity over cleverness
- Be willing to go back and clarify
- **YAGNI ruthlessly**
---
If the design is high-impact, high-risk, or requires elevated confidence, you MUST hand off the finalized design and Decision Log to the `multi-agent-brainstorming` skill before implementation.
