Brainstorming Ideas Into Designs
Help turn ideas into fully formed designs and specs through natural collaborative dialogue.
Start by understanding the current project context, then ask questions one at a time to refine the idea. Once you understand what you're building, present the design and get user approval.
Checklist
You MUST create a task for each of these items and complete them in order:
- Explore project context — check files, docs, recent commits
- Offer visual companion (if topic will involve visual questions)
- Ask clarifying questions — one at a time, understand purpose/constraints/success criteria
- Propose 2-3 approaches — with trade-offs and your recommendation
- Present design — in sections scaled to their complexity, get user approval after each section
- Write design doc — save to
docs/specs/YYYY-MM-DD-<topic>-design.md and commit
- Spec review loop — dispatch
@Architect (SYARCH) or a spec-document-reviewer subagent with precisely crafted review context; fix issues and re-dispatch until approved
- User reviews written spec — ask user to review the spec file before proceeding
- Transition to implementation — invoke
writing-plans skill to create implementation plan
Process Flow
The terminal state is invoking writing-plans. Do NOT invoke any implementation skill. The ONLY skill you invoke after brainstorming is writing-plans.
The Process
Understanding the idea:
- Check out the current project state first (files, docs, recent commits)
- If the project is too large for a single spec, help the user decompose into sub-projects
- Ask questions one at a time to refine the idea
- Prefer multiple choice questions when possible
- Focus on understanding: purpose, constraints, success criteria
Exploring approaches:
- Propose 2-3 different approaches with trade-offs
- Present options conversationally with your recommendation and reasoning
Presenting the design:
- Once you believe you understand what you're building, present the design
- Scale each section to its complexity: a few sentences if straightforward, up to 200-300 words if nuanced
- Ask after each section whether it looks right so far
- Cover: architecture, components, data flow, error handling, testing
After the Design
Documentation:
- Write the validated design (spec) to
docs/specs/YYYY-MM-DD-<topic>-design.md
- Commit the design document to git
Spec Review Loop:
After writing the spec document:
- Dispatch
@Architect (SYARCH) or spec-document-reviewer subagent
- If Issues Found: fix, re-dispatch, repeat until Approved
User Review Gate:
After the spec review loop passes, ask the user to review the written spec before proceeding:
"Spec written and committed to <path>. Please review it and let me know if you want to make any changes before we start writing out the implementation plan."
Only proceed once the user approves.
Implementation:
- Invoke the
writing-plans skill to create a detailed implementation plan.
When to Use
- When this specific skillset is applicable to the current task.
Prerequisites
- Appropriate MCP servers and context.
Best Practices
- Always verify before completing the task.
Process
- Review the problem statement.
- Execute steps sequentially.
- Validate the output.
1---2name: brainstorming3description: "You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation."4type: skill5---67# Brainstorming Ideas Into Designs89Help turn ideas into fully formed designs and specs through natural collaborative dialogue.1011Start by understanding the current project context, then ask questions one at a time to refine the idea. Once you understand what you're building, present the design and get user approval.1213<HARD-GATE>14Do 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.15</HARD-GATE>1617## Checklist1819You MUST create a task for each of these items and complete them in order:20211. **Explore project context** — check files, docs, recent commits222. **Offer visual companion** (if topic will involve visual questions)233. **Ask clarifying questions** — one at a time, understand purpose/constraints/success criteria244. **Propose 2-3 approaches** — with trade-offs and your recommendation255. **Present design** — in sections scaled to their complexity, get user approval after each section266. **Write design doc** — save to `docs/specs/YYYY-MM-DD-<topic>-design.md` and commit277. **Spec review loop** — dispatch `@Architect` (SYARCH) or a spec-document-reviewer subagent with precisely crafted review context; fix issues and re-dispatch until approved288. **User reviews written spec** — ask user to review the spec file before proceeding299. **Transition to implementation** — invoke `writing-plans` skill to create implementation plan3031## Process Flow3233**The terminal state is invoking writing-plans.** Do NOT invoke any implementation skill. The ONLY skill you invoke after brainstorming is `writing-plans`.3435## The Process3637**Understanding the idea:**38- Check out the current project state first (files, docs, recent commits)39- If the project is too large for a single spec, help the user decompose into sub-projects40- Ask questions one at a time to refine the idea41- Prefer multiple choice questions when possible42- Focus on understanding: purpose, constraints, success criteria4344**Exploring approaches:**45- Propose 2-3 different approaches with trade-offs46- Present options conversationally with your recommendation and reasoning4748**Presenting the design:**49- Once you believe you understand what you're building, present the design50- Scale each section to its complexity: a few sentences if straightforward, up to 200-300 words if nuanced51- Ask after each section whether it looks right so far52- Cover: architecture, components, data flow, error handling, testing5354## After the Design5556**Documentation:**57- Write the validated design (spec) to `docs/specs/YYYY-MM-DD-<topic>-design.md`58- Commit the design document to git5960**Spec Review Loop:**61After writing the spec document:621. Dispatch `@Architect` (SYARCH) or spec-document-reviewer subagent632. If Issues Found: fix, re-dispatch, repeat until Approved6465**User Review Gate:**66After the spec review loop passes, ask the user to review the written spec before proceeding:6768> "Spec written and committed to `<path>`. Please review it and let me know if you want to make any changes before we start writing out the implementation plan."6970Only proceed once the user approves.7172**Implementation:**73- Invoke the `writing-plans` skill to create a detailed implementation plan.747576## When to Use77- When this specific skillset is applicable to the current task.787980## Prerequisites81- Appropriate MCP servers and context.828384## Best Practices85- Always verify before completing the task.8687## Process881. Review the problem statement.892. Execute steps sequentially.903. Validate the output.
gitwalter