Brainstorm
Overview
Use this skill to convert rough ideas into clear, reviewable design outputs through structured dialogue.
The goal is to:
- Clarify requirements and constraints
- Explore alternatives with trade-offs
- Produce a concrete, validated design brief in artifacts or a handoff to planning
Workflow
Step 1: Gather Project Context
Load project context per the shared Context Loading Protocol. Also check key implementation files relevant to the idea and note constraints from existing architecture, dependencies, and conventions.
Keep this pass focused. Only gather what is needed for the current idea.
Step 2: Clarify Requirements
Ask targeted questions sequentially to remove ambiguity. Follow the Question Tool mandate.
- Focus on:
- Objective and user value - Scope boundaries - Constraints (technical, UX, performance, timeline) - Success criteria - Non-goals
Do not jump to implementation details too early.
Step 3: Explore Approaches
Propose 2-5 viable approaches.
For each approach, include:
- Short summary
- Pros
- Cons / risks
- Complexity estimate
- Recommended use conditions
Lead with your recommended option and explain why it best fits the project context and constraints.
After presenting all approaches, use Question Tool to let the user pick their preferred approach. List the summary options. Example:
- Approach A, short summary
- Approach B, short summary
- Approach C, short summary
- Other (please specify)
with the tag added for the recommended approach to guide the user.
Step 4: Present the Design Incrementally
Once requirements are clear, present the design incrementally in logical phases (about 200-300 words per phase) to avoid overwhelming the user.
- Phase 1: Foundation - Problem framing, goals, and proposed architecture/flow.
- Phase 2: Technical Details - Data model, interfaces, error handling, and edge cases.
- Phase 3: Delivery - Testing/verification strategy and rollout considerations (if applicable).
After presenting each phase, use Question Tool immediately to ask whether to:
- Proceed to the next phase
- Adjust the current phase
- Revisit a previous phase
Step 5: Close the Loop
After you and the user have worked through requirements and the design is validated, determine the next actions.
- Use
Question Toolto present the user with three high-level next actions:
- "Write plan immediately (in current context)" - skip the artifact step and move straight to a write-plan handoff. - "Write artifacts" - continue by authoring the brainstorm documents described in Step 6. - "End session (already provided enough information for user)" - stop; the conversation has produced enough insight for now.
- If the user picks Write artifacts, proceed to Step 6. Once the draft artifacts exist, use
Question Toolagain to validate them with options:
- "Write plan with current artifacts, context" - "End session - artifacts are sufficient for now" - "Need changes" (free-form text) - collect the feedback, revise the artifacts, and re-ask.
- If the user picked Write plan immediately, initiate a handoff to use skill
write-planusing the current brainstorming context; no additional artifact validation is required. - If the user picked End session, simply stop. The information collected so far is considered sufficient.
Step 6 (optional): Write Brainstorm Artifacts
Only perform this step after the user has explicitly chosen "Write artifacts" during Step 5.
Persist results to the standardized location:
- Directory:
docs/brainstorms/YYMMDD-HHmm-<topic-slug>/ - Main file (required):
docs/brainstorms/YYMMDD-HHmm-<topic-slug>/SUMMARY.md - Optional supporting files:
- docs/brainstorms/YYMMDD-HHmm-<topic-slug>/section-01-<slug>.md - docs/brainstorms/YYMMDD-HHmm-<topic-slug>/section-02-<slug>.md - etc.
SUMMARY.md format: strictly follow the template inside references/summary-template.md.
Rules
- Do not write production code or make implementation changes in this skill in the brainstorm session.
- Keep interaction lightweight and iterative; every step should be run in the same session.
- Prefer clarity over completeness when uncertain; ask a follow-up question.
- Align all recommendations with project documentation and standards.
- Keep assumptions explicit; do not guess silently.
- Think before coding: Surface assumptions explicitly. If multiple interpretations exist, present them — don't pick silently. If a simpler approach exists, say so and push back when warranted.