diegosouzapw 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:
Direct integration - Fast to implement but creates coupling. Good if this is temporary.
Event-driven - More flexible, better separation, but adds complexity. Worth it if we'll extend this.
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.
Once you understand what you're building, present the design in small, manageable sections covering architecture and component structure, data flow and state management, error handling and edge cases, and testing approach.
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.
Multiple choice preferred. "Should we use events or direct calls?" is easier than "How should components communicate?"
YAGNI ruthlessly. Remove unnecessary features from designs. Build what's needed, not what might be needed someday.
Explore alternatives always. Present multiple approaches before settling on one. This surfaces tradeoffs. Choose one clear recommendation - avoid defaulting to hybrid approaches which rarely solve the problem well.
Incremental validation. Present design in sections, validate each before continuing. Don't write a complete design then ask for feedback - you might be heading the wrong direction.
Be flexible. When something doesn't make sense to your partner, go back and clarify. Don't defend the design, refine it.