Turn ideas into fully formed designs through collaborative dialogue. Understand the project context, ask questions one at a time, present the design, get user approval.
Use before any creative work: new features, components, modifications.
Use before any implementation skill — brainstorming produces the spec.
If the prompt has a project context (existing codebase) and you haven't onboarded this session, invoke `bp:onboarding-to-a-project` first. Standard flow: onboarding identifies key files & stack → brainstorming designs against those conventions → implementation. For purely abstract design questions with no specific project, brainstorming is the entry point.
Do NOT invoke any implementation skill, write any code, scaffold any project, or take any implementation action until you have presented a design and the user has approved it. This applies to EVERY project regardless of perceived simplicity.
"This is too simple to need a design." Every project goes through this process — a todo list, a single-function utility, a config change. "Simple" projects are where unexamined assumptions cause the most wasted work. The design can be short, but you MUST present it and get approval.
**Explore project context** — check files, docs, recent commits.
**Offer visual companion** (if visual questions ahead) — own message, no other content. See visual-companion.md.
**Ask clarifying questions** — one at a time. Multiple choice preferred. Understand purpose, constraints, success criteria.
**Scope check** — if the request spans multiple independent subsystems, flag it. Decompose into sub-projects before refining details. Each sub-project gets its own spec → plan → implementation cycle.
**Propose 2-3 approaches** — with trade-offs and your recommendation. Lead with recommended option.
**Present design** — scale each section to complexity. Ask after each section if it looks right. Cover: architecture, components, data flow, error handling, testing.
**Write design doc** — save to `docs/bearpaws/plans/YYYY-MM-DD-{topic}-design.md` (user prefs override). Commit.
**Spec self-review** — scan for placeholders/TBD, internal contradictions, scope creep, ambiguity. Fix inline.
**User reviews spec** — ask user to review before proceeding. Wait for approval.
**Transition** — invoke bp:writing-plans. That is the ONLY next skill.
```dot
digraph brainstorming {
"Explore context" [shape=box];
"Visual ahead?" [shape=diamond];
"Offer companion\n(own message)" [shape=box];
"Clarifying Qs" [shape=box];
"Propose approaches" [shape=box];
"Present design" [shape=box];
"Approved?" [shape=diamond];
"Write spec" [shape=box];
"Self-review" [shape=box];
"User reviews?" [shape=diamond];
"Invoke writing-plans" [shape=doublecircle];
"Explore context" -> "Visual ahead?";
"Visual ahead?" -> "Offer companion\n(own message)" [label="yes"];
"Visual ahead?" -> "Clarifying Qs" [label="no"];
"Offer companion\n(own message)" -> "Clarifying Qs";
"Clarifying Qs" -> "Propose approaches";
"Propose approaches" -> "Present design";
"Present design" -> "Approved?";
"Approved?" -> "Present design" [label="revise"];
"Approved?" -> "Write spec" [label="yes"];
"Write spec" -> "Self-review";
"Self-review" -> "User reviews?";
"User reviews?" -> "Write spec" [label="changes"];
"User reviews?" -> "Invoke writing-plans" [label="approved"];
}
```
The terminal state is invoking bp:writing-plans. Do NOT invoke frontend-design, mcp-builder, or any other implementation skill directly from brainstorming.
**One question at a time** — don't overwhelm with multiple questions.
**YAGNI ruthlessly** — remove unnecessary features from all designs.
**Design for isolation** — smaller units with clear boundaries and well-defined interfaces. Each unit has one purpose, can be understood and tested independently.
**Follow existing patterns** in existing codebases. Only propose improvements that serve the current goal.