Brainstorming

Presenting the design:

• Once you believe you understand what you're building, present the design
• Break it into sections of 200-300 words
• Ask after each section whether it looks right so far
• Cover: architecture, components, data flow, error handling, testing
• Be ready to go back and clarify if something doesn't make sense

After the Design

Documentation:

• Write the validated design to docs/plans/YYYY-MM-DD-<topic>-design.md
• Use context-compressor skill if available for efficient documentation
• Commit the design document to git

Implementation (if continuing):

• Ask: "Ready to set up for implementation?"
• Use writing-plans skill to create detailed implementation plan

Key Principles

• One question at a time - Don't overwhelm with multiple questions
• Multiple choice preferred - Easier to answer than open-ended when possible
• YAGNI ruthlessly - Remove unnecessary features from all designs
• Explore alternatives - Always propose 2-3 approaches before settling
• Incremental validation - Present design in sections, validate each
• Be flexible - Go back and clarify when something doesn't make sense

Iron Laws

1. NEVER propose a single solution — always surface 2–3 distinct approaches with trade-offs; a single solution forecloses exploration and anchors the user prematurely.
2. ALWAYS apply YAGNI (You Ain't Gonna Need It) — challenge every feature or complexity not directly required by the stated problem; unneeded features become permanent maintenance debt.
3. NEVER ask multiple questions in one response — one focused question at a time maintains dialogue flow; multiple questions cause partial answers and leave the most important question unanswered.
4. ALWAYS prefer multiple-choice over open-ended questions — specific options reduce cognitive load; open-ended questions require the user to invent answers rather than evaluate them.
5. NEVER proceed to implementation details until design decisions are confirmed — premature implementation locks in unvalidated assumptions; confirm the "what" and "why" before the "how".

Anti-Patterns

Memory Protocol (MANDATORY)

Before starting: Read .claude/context/memory/learnings.md

After completing:

• New pattern -> .claude/context/memory/learnings.md
• Issue found -> .claude/context/memory/issues.md
• Decision made -> .claude/context/memory/decisions.md

ASSUME INTERRUPTION: If it's not in memory, it didn't happen.