brainstorming

Core principle: Ask questions to understand, present options to explore, validate sections to refine.

Skip for clear mechanical tasks with obvious solutions, well-defined requirements with standard implementations, or simple bug fixes.

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.

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 information sequentially - showing options first lets them fully consider each alternative before being influenced by a recommendation. The recommendation comes after all options have been presented.

Make a clear recommendation - pick one approach and explain why it fits best. Don't hedge or suggest combining approaches.

Avoid defaulting to hybrid approaches. Hybrid solutions are rarely the right answer. They often combine the complexity of multiple approaches without clear benefits. Only suggest a hybrid if there's a specific, compelling reason why a pure approach won't work.

Structure alternatives clearly - each option should be distinct with clear tradeoffs. If options are too similar, you haven't explored the design space enough.

Explain the choice criteria - make explicit what factors led to your recommendation (simplicity, performance, maintainability, etc.). This helps validate whether the recommendation aligns with priorities.

Let the human partner react after your recommendation. They may have constraints or priorities you didn't consider.

Ask after each section whether it looks right. Be ready to go back and clarify if something doesn't make sense.

This incremental validation catches misunderstandings early before you've written a complete design document.

Commit the design document to git so it's tracked with the project.

If continuing to implementation, ask whether to proceed. Set up an isolated workspace for development (git worktree or feature branch). Create a detailed implementation plan breaking the design into concrete tasks.