brainstorming

Follow a structured brainstorming process: explore the project context, ask clarifying questions one at a time, propose 2-3 approaches with trade-offs, then present the design in sections for approval. Only after approval should you write a design doc and create an implementation plan.

A design document should cover architecture, components, data flow, error handling, and testing strategy. Scale each section to its complexity, from a few sentences for simple work to 200-300 words for nuanced areas, and save it under a dated path like docs/plans/YYYY-MM-DD-topic-design.md.

Yes, even simple tasks like a config change or single-function utility benefit from a brief explicit design and approval. Simple projects are where unexamined assumptions cause the most wasted work, though the design itself can be just a few sentences.

Never skip design when creating features, building components, adding functionality, or modifying behavior. The hard gate in this process prohibits writing code, scaffolding projects, or invoking implementation skills until a design is presented and explicitly approved.

Ask exactly one question per message to avoid overwhelming the stakeholder. Prefer multiple-choice questions when practical, and break complex topics into multiple sequential questions covering purpose, constraints, and success criteria.