brainstorming

<objective>
Turn rough ideas into fully-formed designs through natural collaborative dialogue. Understand the context, explore alternatives, validate incrementally.

Core principle: Ask questions to understand, present options to explore, validate
sections to refine. </objective>

<when-to-use>
Use brainstorming when you have a rough idea but unclear implementation, multiple approaches exist and you need to choose, requirements are fuzzy or incomplete, or design decisions need validation before coding.

Skip for clear mechanical tasks with obvious solutions, well-defined requirements with
standard implementations, or simple bug fixes. </when-to-use>

<understanding-context>
Explore the current project state. Check existing files, documentation, recent commits. Understand what's already built.

Ask questions one at a time to refine the idea. Use multiple choice when possible -
easier to answer than open-ended. Focus on understanding purpose (what problem does this
solve?), constraints (what limits the solution?), and success criteria (how do we know
it works?).

One question per message. If a topic needs more exploration, break it into multiple
questions. Don't overwhelm with a list of questions. </understanding-context>

<exploring-alternatives>
Propose different approaches with their tradeoffs. Present conversationally, showing all options first before making a recommendation.

Example pattern: "I see three main approaches:

1. Direct integration - Fast to implement but creates coupling. Good if this is
   temporary.

2. Event-driven - More flexible, better separation, but adds complexity. Worth it if
   we'll extend this.

3. Separate service - Maximum isolation, easier to scale, but operational overhead.
   Overkill unless we need independent scaling.

I'd recommend #2 (event-driven) because the requirements suggest we'll add features
here, and the loose coupling will make that easier. What do you think?"

Present options before recommendation. LLMs process infor