zoom-out

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.

Zoom Depth

Situation	How Far to Zoom
Modifying one function	Module level (what calls it, what it calls)
Changing an interface/API	Service level (all consumers, all implementations)
Architectural change	System level (all services, data flow, deployment)
"I don't know what this does"	Start at system, narrow to module

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

# Before modifying auth.ts, zoom out:
# 1. What calls auth.ts?
grep -r "from.*auth" src/ --include="*.ts" -l
# 2. What does auth.ts import?
head -20 src/auth.ts | grep "import"
# 3. What tests cover this?
find . -name "*auth*test*"