Go up a layer of abstraction and map the surrounding architecture. Use when the user is unfamiliar with an area of code, asks "how does this fit in", "what calls this", "give me the big picture", "where am I", "map this out", "I'm lost", "explain this area", or needs to understand how a file, module, or function connects to the rest of the system. Also use when the user says /zoom-out or "zoom out" mid-conversation — even without a specific file reference, orient them based on whatever code is currently in context.
Installation
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Go up a layer of abstraction and map the surrounding architecture. Use when the user is unfamiliar with an area of code, asks "how does this fit in", "what calls this", "give me the big picture", "where am I", "map this out", "I'm lost", "explain this area", or needs to understand how a file, module, or function connects to the rest of the system. Also use when the user says /zoom-out or "zoom out" mid-conversation — even without a specific file reference, orient them based on whatever code is currently in context.
disable-model-invocation
true
Zoom Out
The user needs a map, not a tour. They're disoriented in the codebase and want to understand how the thing they're looking at connects to everything around it.
What to produce
Build a context map anchored on whatever code is currently in focus (the file being discussed, the function just edited, or the module the user asked about). The map should answer: what is this, what does it talk to, and why does it exist?
Structure
One-sentence orientation — What this module/file is in plain terms and why it exists in the system.
Ancestry — Walk up the call chain or module hierarchy. Who owns this? What triggers it? Show the path from entrypoint to here, 2-3 levels up max.
Sibling map — What are the peer modules at this same level of abstraction? List them with one-line descriptions. This answers "what else lives here?"
Key connections — Inbound callers and outbound dependencies. Not every import — just the ones that matter for understanding the module's role. Use arrows or a simple ASCII diagram if it helps.
Domain vocabulary — If this area uses domain-specific terms (e.g., "tenant", "workspace", "pipeline stage"), define the 3-5 most important ones in the context of this codebase, not generic definitions.
How to research
Read the current file and its imports
Check the parent directory's structure (ls the containing folder)
Grep for usages of the main exports to find callers
Glance at sibling files to understand the neighborhood
Read any local README or CLAUDE.md for domain context
What NOT to do
Don't explain implementation details or line-by-line code
Don't suggest changes or refactors — this is orientation, not a code review
Don't produce a wall of text — keep the map scannable
Don't guess at architecture if you haven't read the code — investigate first
