zoom-out
Use when you are lost in local code details — step one abstraction level up, map the owning modules and callers, and restate the system in project vocabulary
Best use case
zoom-out is best used when you need a repeatable AI agent workflow instead of a one-off prompt.
Use when you are lost in local code details — step one abstraction level up, map the owning modules and callers, and restate the system in project vocabulary
Teams using zoom-out should expect a more consistent output, faster repeated execution, less prompt rewriting.
When to use this skill
- You want a reusable workflow that can be run more than once with consistent structure.
When not to use this skill
- You only need a quick one-off answer and do not need a reusable workflow.
- You cannot install or maintain the underlying files, dependencies, or repository context.
Installation
Claude Code / Cursor / Codex
Manual Installation
- Download SKILL.md from GitHub
- Place it in
.claude/skills/zoom-out/SKILL.mdinside your project - Restart your AI agent — it will auto-discover the skill
How zoom-out Compares
| Feature / Agent | zoom-out | Standard Approach |
|---|---|---|
| Platform Support | Not specified | Limited / Varies |
| Context Awareness | High | Baseline |
| Installation Complexity | Unknown | N/A |
Frequently Asked Questions
What does this skill do?
Use when you are lost in local code details — step one abstraction level up, map the owning modules and callers, and restate the system in project vocabulary
Where can I find the source code?
You can find the source code on GitHub using the link provided at the top of the page.
SKILL.md Source
# 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: ```markdown ## 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`](../../copilot-exclusive/context-prime/SKILL.md) — load project-wide context at session start - [`code-tour`](../../documentation/code-tour/SKILL.md) — turn the mental map into an onboarding walkthrough - [`systematic-debugging`](../systematic-debugging/SKILL.md) — switch from orientation to root-cause analysis
Related Skills
verification-before-completion
Use before claiming any task is done — run the exact command that proves the fix works, read the output, and only then report success.
using-git-worktrees
Use when you need multiple branches checked out at once — create isolated working directories for parallel development without cloning the repository repeatedly
triage
Use when a single issue needs structured triage — classify it, reproduce if needed, request missing information, and leave a durable brief or close-out note in the tracker.
to-issues
Use when a plan, spec, or PRD must become an actionable backlog — break it into thin dependency-aware issues that each deliver a verifiable vertical slice
sprint-workflow
Use when starting a new feature, refactor, or multi-step dev task — runs the full sprint cycle (Think → Plan → Build → Review → Test → Ship → Monitor) using Copilot CLI's plan/autopilot modes.
sprint-retro
Use at the end of a sprint to run a data-driven retrospective — analyzes session history and git metrics to surface what shipped, what slowed you down, and concrete improvements.
security-audit
Use when a codebase needs a formal security audit beyond a quick scan — applies OWASP Top 10 and STRIDE threat modeling from a CSO perspective to surface systemic vulnerabilities.
release
Use when a sprint or feature is complete and ready to ship — tags the version, generates GitHub Release notes, runs rollout or smoke verification, and publishes to npm/PyPI/Docker registries.
prompt-optimizer
Use when a rough prompt, vague idea, or task description needs to become a finished copy-pasteable prompt for a chat-based LLM - rewrite it into one ready-to-send prompt with no blanks, no placeholders, and a clear output shape.
outside-voice
Use when you need an independent second opinion before, during, or after implementation — run challenge, consult, or review mode in a direct builder-to-builder voice
llm-wiki
Use when research or domain knowledge keeps getting rediscovered across sessions — build a supplementary markdown wiki that compounds synthesized knowledge without replacing GitHub or committed project guidance
interview-me
Use when a request is underspecified and you need to discover what the user actually wants before writing a plan, spec, or code - ask one question at a time, attach your current hypothesis, and stop only after the intent is explicitly confirmed.