Brainstorming

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:

1. Explore project context — check files, docs, recent commits
2. Offer visual companion (if topic will involve visual questions)
3. Ask clarifying questions — one at a time, understand purpose/constraints/success criteria
4. Propose 2-3 approaches — with trade-offs and your recommendation
5. Present design — in sections scaled to their complexity, get user approval after each section
6. Write design doc — save to docs/specs/YYYY-MM-DD-<topic>-design.md and commit
7. Spec review loop — dispatch @Architect (SYARCH) or a spec-document-reviewer subagent with precisely crafted review context; fix issues and re-dispatch until approved
8. User reviews written spec — ask user to review the spec file before proceeding
9. 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:

1. Dispatch @Architect (SYARCH) or spec-document-reviewer subagent
2. 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

1. Review the problem statement.
2. Execute steps sequentially.
3. Validate the output.