Zoom out
18 AI agent skills that catch what your agent misses: hidden code debt, false completions, missing error handling, context amnesia, imprecise UI edits. Self-improving with TF-IDF routing + SkillOpt loop. Cursor, Claude Code, Codex, Copilot. Install: npx skills@latest add Adit-Jain-srm/skill-forge
npx -y skills add Adit-Jain-srm/skill-forge --skill zoom-outAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Force a perspective shift. Stop looking at the code line-by-line and explain the broader context: how this piece fits in the system, what depends on it, what it depends on, and what the original designer was thinking. Use when lost in unfamiliar code, when changes feel risky because you don't see the full picture, or when user says "zoom out", "big picture", "how does this fit", or "explain the architecture around this".
SKILL.md
2.7 KB, as published. Nobody here has run it
Overview
Before modifying unfamiliar code, explain the broader system context — what depends on this code, what this code calls into, and what breaks if you change it.
Process
Stop. Zoom out. Before touching this code, explain:
- What system is this part of? (name the module/service/layer)
- What calls this? (trace UP — who depends on this code?)
- What does this call? (trace DOWN — what does it depend on?)
- Why does it exist? (what problem did the original author solve?)
- What breaks if this changes? (blast radius)
- What's the simplest mental model? (explain to a new team member in 2 sentences)
When to Auto-Trigger
- About to modify a file you didn't write and haven't read fully
- Making a change that touches 3+ files
- The function/class name doesn't clearly explain its purpose
- You feel uncertain about side effects
Rules
- Read FIRST, explain SECOND, modify THIRD. Never modify what you don't understand.
- If you can't explain it simply, you don't understand it well enough to change it safely.
- Cite specific file paths and line numbers when explaining relationships.
Zoom Depth
| Situation | How Far to Zoom |
|---|---|
| Modifying one function | Module level (what calls it, what it calls) |
| Changing an interface/API | Service level (all consumers, all implementations) |
| Architectural change | System level (all services, data flow, deployment) |
| "I don't know what this does" | Start at system, narrow to module |
Common Mistakes
- Modifying before understanding (leads to cascading breakage)
- Explaining only the file in isolation (miss the system relationships)
- Skipping "what breaks if this changes" (the most critical question)
- Using vague descriptions — always cite specific file paths and line numbers
Example
# Before modifying auth.ts, zoom out:
# 1. What calls auth.ts?
grep -r "from.*auth" src/ --include="*.ts" -l
# 2. What does auth.ts import?
head -20 src/auth.ts | grep "import"
# 3. What tests cover this?
find . -name "*auth*test*"
Then explain: "auth.ts is the middleware layer between routes/ and the JWT library. It's called by 12 route handlers. Breaking its interface breaks all protected endpoints."