zoom-outlisted

## Overview Before modifying unfamiliar code, explain the broader system context — what depends on this code, what this code calls into, and what breaks if you change it. ## Process Stop. Zoom out. Before touching this code, explain: 1. **What system is this part of?** (name the module/service/layer) 2. **What calls this?** (trace UP — who depends on this code?) 3. **What does this call?** (trace DOWN — what does it depend on?) 4. **Why does it exist?** (what problem did the original author solve?) 5. **What breaks if this changes?** (blast radius) 6. **What's the simplest mental model?** (explain to a new team member in 2 sentences) ## When to Auto-Trigger - About to modify a file you didn't write and haven't read fully - Making a change that touches 3+ files - The function/class name doesn't clearly explain its purpose - You feel uncertain about side effects ## Rules - Read FIRST, explain SECOND, modify THIRD. Never modify what you don't understand. - If you can't explain it simply, you don't understand it well enough to change it safely. - Cite specific file paths and line numbers when explaining relationships. ## Common Mistakes - Modifying before understanding (leads to cascading breakage) - Explaining only the file in isolation (miss the system relationships) - Skipping "what breaks if this changes" (the most critical question) - Using vague descriptions — always cite specific file paths and line numbers ## Example ```bash # Before modifying auth.ts, zoom ou