zoom-out

Generate a structured map of modules, callers, and boundaries for an unfamiliar codebase area.

Updated Apr 6, 2026
One-click install
npx skills add https://github.com/toderian/project_template --skill zoom-out-toderian
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: zoom-out
Source: https://github.com/toderian/project_template/tree/main/plugins/agents-extras/skills/zoom-out
Command: npx skills add https://github.com/toderian/project_template --skill zoom-out-toderian

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? When starting work in an unfamiliar part of a codebase, narrow file-by-file reading loses the bigger picture. This Skill steps up a layer of abstraction and produces a one-screen architectural map of the relevant modules, callers, and boundaries, grounded in the project's domain glossary. ## Core Features & Use Cases - Structured area map: Produces purpose, inputs, outputs, internal shape (3-7 key modules), edges and seams, and open questions for a named code area. - Glossary-aligned language: Reads docs/resources/CONTEXT.md first and bolds canonical domain terms, noting aliases where code names differ from glossary names. - Bounded scope: Stops at the map — it does not propose changes or critique design, deferring follow-up to architecture or diagnosis skills. - Use Case: You are assigned a bug in a billing module you have never touched. Run this Skill to get a one-screen map of the module's callers, outputs, and database boundary before reading any implementation code. ## Quick Start Ask the agent to zoom out on the billing module and map its callers, outputs, and boundaries using the project glossary.

Frequently Asked Questions about zoom-out

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I understand an unfamiliar part of a codebase quickly?

Use a zoom-out approach: identify the target area, read the project's domain glossary first, then produce a structured map covering purpose, inputs, outputs, key modules, and boundary seams. This gives broader context before reading implementation details.

What should a codebase architecture map include?

A useful map includes the area's purpose in one sentence, its callers and call shapes, what downstream code consumes its outputs, the 3-7 modules that matter with one-line roles, edges with adjacent contexts, and unresolved open questions.

Does this skill modify or critique the code it maps?

No. It only produces a descriptive map and stops there. If the map surfaces an architectural problem, it is noted under open questions and the user decides whether to follow up with architecture-improvement or diagnosis skills.

Why read a domain glossary before reading the code?

The glossary fixes canonical domain names so the map stays legible and consistent with project language. Where code uses different words than the glossary, the map notes the alias so readers can connect code terms to domain terms.

When is a zoom-out map not the right approach?

It is not suited for proposing changes, writing code, or deep design critique. For a narrow bug with a known location, a direct trace may be faster; for redesign decisions, a dedicated architecture-review workflow is more appropriate.