| name | zoom-out |
| description | Force a perspective shift. Stop looking at the code line-by-line and explain the broader context: how this piece fits in the system, what depends on it, what it depends on, and what the original designer was thinking. Use when lost in unfamiliar code, when changes feel risky because you don't see the full picture, or when user says "zoom out", "big picture", "how does this fit", or "explain the architecture around this". |
Stop. Zoom out. Before touching this code, explain:
- What system is this part of? (name the module/service/layer)
- What calls this? (trace UP — who depends on this code?)
- What does this call? (trace DOWN — what does it depend on?)
- Why does it exist? (what problem did the original author solve?)
- What breaks if this changes? (blast radius)
- 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.
Example
grep -r "from.*auth" src/ --include="*.ts" -l
head -20 src/auth.ts | grep "import"
find . -name "*auth*test*"
Then explain: "auth.ts is the middleware layer between routes/ and the JWT library. It's called by 12 route handlers. Breaking its interface breaks all protected endpoints."
