
Brainstorm
- 45 installs
- 52 repo stars
- Updated July 6, 2026
- buiducnhat/cobrew
Brainstorm is a Claude Code skill that turns a rough idea into a validated design brief by clarifying requirements and comparing approaches with trade-offs.
About
Brainstorm is a Claude Code skill for collaborative discovery and design framing on ambiguous or high-risk work. A developer uses it to clarify requirements, explore multiple approaches with trade-offs, and produce a validated design brief before any planning or coding. It runs as a structured dialogue and can hand off to a planning skill or write brainstorm artifacts.
- Explores 2-5 viable approaches with pros, cons, complexity, and a recommended option
- Presents design incrementally across Foundation, Technical Details, and Delivery phases
- Can persist a design brief to docs/.brainstorms/ or hand off to a write-plan skill
Brainstorm by the numbers
- 45 all-time installs (skills.sh)
- Ranked #1,674 of 3,282 Productivity & Planning skills by installs in the Skillselion catalog
- Data as of Jul 28, 2026 (Skillselion catalog sync)
brainstorm capabilities & compatibility
- Capabilities
- ask · quick implement · write plan · execute plan
- Use cases
- planning · research
- Pricing
- Free
What brainstorm says it does
Collaborative discovery and design framing for ambiguous or high-risk work.
Propose 2-5 viable approaches.
Do not write production code or make implementation changes in this skill in the brainstorm session.
npx skills add https://github.com/buiducnhat/cobrew --skill brainstormAdd your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| Installs | 45 |
|---|---|
| repo stars | ★ 52 |
| Last updated | July 6, 2026 |
| Repository | buiducnhat/cobrew ↗ |
What it does
Convert a rough idea into a validated design brief through structured dialogue, exploring 2-5 approaches with trade-offs before planning.
Who is it for?
Framing ambiguous or high-risk work into a reviewable design before planning.
Skip if: Writing production code or making implementation changes (explicitly disallowed in-session).
When should I use this skill?
Requirements are unclear, multiple approaches are possible, or you need to turn an idea into a validated design brief before planning or coding.
What you get
A validated design brief with a chosen approach, scope, non-goals, decisions, and risks.
- A validated design brief
- Optional brainstorm artifacts in docs/.brainstorms/
By the numbers
- Proposes 2-5 viable approaches per session
- Presents design across 3 phases: Foundation, Technical Details, Delivery
Files
Brainstorm
Overview
Use this skill to convert rough ideas into clear, reviewable design outputs through structured dialogue.
The goal is to:
1. Clarify requirements and constraints 2. Explore alternatives with trade-offs 3. Produce a concrete, validated design brief in artifacts or a handoff to planning
Workflow
Step 1: Gather Project Context
Load only the project context relevant to the current idea:
- If
docs/SUMMARY.mdexists, read it first. - Load only task-relevant detail docs.
- Prioritize
Code Standarddocs for implementation conventions. - If docs conflict with code or user intent, use the available input/question tool before broad changes.
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 only when ambiguity cannot be resolved from the request, project docs, or code. Use the input/question tool when available; otherwise ask a concise direct question.
- 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 input/question tool to ask the user to pick a preferred approach only when the choice materially changes the design or delivery path. List the summary options. Example:
1. Approach A, short summary 2. Approach B, short summary 3. Approach C, short summary 4. 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. For small topics, combine phases when separate checkpoints would add friction.
- 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 a phase, use input/question tool to ask for confirmation only when user input would materially change the next phase. Use these options when a checkpoint is needed:
1. Proceed to the next phase 2. Adjust the current phase 3. 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.
Before asking for next actions, summarize the current design brief in chat. Keep it compact unless the user asks for artifacts:
- Goal and user-visible outcome
- Chosen or recommended approach
- Scope and non-goals
- Key decisions and trade-offs
- Main risks, assumptions, or unresolved questions
- Recommended next step
1. Use input/question tool to present the user with four high-level next actions:
- "Write plan immediately (in current context)" - skip the artifact step and move straight to a
write-planhandoff. - "Write artifacts" - continue by authoring the brainstorm documents described in Step 6.
- "Implement immediately (skip design artifacts and planning)" - if the design is very clear and low-risk, the user may choose to skip both artifacts and planning and move straight to implementation.
- "End session (already provided enough information for user)" - stop; the conversation has produced enough insight for now.
2. If the user picks Write artifacts, proceed to Step 6. Once the draft artifacts exist, use input/question tool again 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.
3. If the user picked Write plan immediately, initiate a handoff to use skill write-plan using the current brainstorming context; no additional artifact validation is required.
4. 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>.mddocs/.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.
Brainstorm: <Title>
Created: YYYY-MM-DD HH:mm:ss
Context
- Background and motivation for the brainstorm.
Goals
- What success looks like.
Non-Goals
- What is explicitly excluded.
Chosen Approach
- Selected approach and rationale.
Alternatives Considered
- Alternative 1 — pros, cons, why not chosen
- Alternative 2 — pros, cons, why not chosen
Risks & Mitigations
- Risk → mitigation
Open Questions
- Items requiring further investigation or user confirmation.
Next Step Recommendation
- Recommended follow-up action (e.g., proceed to
write-plan, prototype, research further).