drvoss Zoom Out
Zoom Out is for moments when a function or file is understandable in isolation but the surrounding system is not. The goal is to move up one abstraction level and rebuild the mental map around the code you are reading.
When to Use
- You understand the local code but not why it exists
- A file is readable, yet the owning module and its callers are still unclear
- You need the domain-language explanation of a technical area before editing it
- The next step should be "show me the bigger picture," not "change this line"
Workflow
1. Start from the current artifact
Pick the function, file, or class you are staring at.
2. Move one level up
Ask:
- Which module or subsystem owns this?
- What broader workflow is this code participating in?
- Which upstream callers depend on it?
3. Translate into project vocabulary
Do not stop at implementation terms. Re-express the answer using the product or domain language the project actually uses.
4. Produce a compact map
Return something like:
## Zoom-Out Map
- **Current artifact:** `src/...`
- **Owning module:** ...
- **Upstream callers:** ...
- **Adjacent collaborators:** ...
- **Domain purpose:** ...
- **Next best file to read:** ...
Tips
- Move only one abstraction level at a time; jumping straight to "the whole architecture" often produces generic summaries
- Prefer real callers and collaborators over speculative architecture prose
- If the picture is still too large, run Zoom Out again from the owning module
See Also
context-prime— load project-wide context at session startcode-tour— turn the mental map into an onboarding walkthroughsystematic-debugging— switch from orientation to root-cause analysis