zoom-out
by mattpocockThe zoom-out skill helps an agent step back from a narrow code question and map the broader system, including related modules, callers, and project vocabulary. It is best for Code Editing workflows when you need context before making a change, especially in unfamiliar repos or subsystems.
This skill scores 72/100, which means it is acceptable to list for directory users, but it is a fairly lightweight utility rather than a deeply operationalized workflow skill. The trigger is clear and the intended outcome is easy to understand: ask the agent to zoom out, map relevant modules and callers, and use the project’s domain vocabulary for broader context.
- Clear, specific trigger language for when to use it: unfamiliar code areas or need for higher-level context.
- Operational intent is easy for an agent to follow: map modules and callers, then explain the bigger picture.
- No placeholder or experimental markers, and the frontmatter is valid, which supports basic trust in the listing.
- Very little workflow scaffolding beyond a short instruction, so agents may still need guesswork on output format and depth.
- No support files, references, scripts, or install command, so the directory page cannot promise strong progressive disclosure or implementation detail.
Overview of zoom-out skill
What zoom-out is for
The zoom-out skill helps an agent step back from a narrow code question and explain the larger system around it. Use zoom-out when you need the zoom-out skill to map related modules, callers, and domain terms instead of jumping straight into a local fix.
Best fit for code comprehension
This is strongest for Code Editing workflows where the problem is architectural context, not syntax. It is useful when you are new to a repo, entering an unfamiliar subsystem, or trying to understand how one file fits into the bigger picture before editing.
What makes it different
zoom-out is not a generic “summarize this code” prompt. It pushes for higher-level structure and project vocabulary, which is useful when a raw skim would miss dependencies, boundary lines, or the functions that actually govern behavior.
How to Use zoom-out skill
Install and trigger
Use the zoom-out install flow for the mattpocock/skills repo, then invoke the skill in a task where the agent is already looking at code. The key is to ask for context expansion, not a direct patch.
Give the skill a narrow target
The best zoom-out usage starts with a concrete area: a file, folder, feature, bug, or function. Good input tells the model what to expand from, what you already suspect, and what output format you want. For example: “Zoom out from src/payments/stripe.ts and show the related modules, entry points, and likely callers before I edit anything.”
Read the right file first
Start with SKILL.md in skills/engineering/zoom-out, since this skill is intentionally tiny and self-contained. There are no supporting rules/, resources/, or helper scripts to learn, so the main job is to apply the instruction well inside your own repo.
Use it as a pre-edit step
A practical workflow is: identify the subsystem, ask for a broader map, review the returned module graph and domain terms, then decide the edit boundary. That sequence reduces guesswork and helps avoid changes that look local but break surrounding code paths.
zoom-out skill FAQ
When should I use zoom-out instead of a normal prompt?
Use zoom-out when you do not yet trust your mental model of the codebase. If you already know the module boundaries and only need a small transformation, a normal prompt is usually enough.
Is zoom-out good for beginners?
Yes, especially if you are still learning a repository. The zoom-out guide is designed to answer “where am I in the system?” before “how do I change this line?” That makes it beginner-friendly for navigation, not for final implementation by itself.
Does it replace repository search or reading files?
No. It works best alongside repo search and file inspection. Think of it as a way to organize what you find, not a substitute for evidence from the code itself.
When is zoom-out a bad fit?
Skip it if the task is purely mechanical, tightly scoped, or already well understood. It is less useful when you only need a one-file edit, a refactor with obvious dependencies, or a prompt that already names every relevant module.
How to Improve zoom-out skill
Ask for the map you need
The best zoom-out for Code Editing inputs specify the level of abstraction you want: “show callers,” “list upstream entry points,” “name the module boundaries,” or “explain the domain vocabulary.” Those constraints produce a better context map than a vague request like “explain this area.”
Include the decision you are trying to make
The skill improves when you tell it what the context is for. For example, “I need to add validation without breaking the checkout flow” gives the model a reason to surface relevant edges, tests, and cross-cutting dependencies instead of a broad overview with no edit guidance.
Iterate from broad to specific
A strong zoom-out skill workflow is to start broad, then narrow once the map is clear. If the first answer misses an important caller or over-focuses on implementation details, ask for a second pass centered on that gap rather than restating the whole task.
Watch for the two common failure modes
The most common problems are over-broad summaries and under-named domain terms. Fix both by providing the target file, adjacent feature area, and the vocabulary used in the repo so the model can anchor the output to the project’s actual structure.