System Zoom Out
When local detail is crowding out system understanding, step back and draw the map.
Output
Explain:
- the relevant modules;
- the entrypoints and callers;
- the key dependencies and boundaries;
- the domain language used in this area;
- why this local change matters to the wider system.
Rules
- Use the repo's domain language, not generic abstractions.
- Prefer maps and relationships over line-by-line summaries.
- Name what is outside the current focus so the user sees the edge of the map.
- If the repo already has architecture docs, align with them or call out contradictions.
Best Use Cases
- architecture audits;
- unfamiliar code areas;
- refactor proposals;
- onboarding into a subsystem;
- explaining blast radius before a change.
Final Report
Give the map, the boundaries, and the best next file or module to inspect if the user wants to go deeper.