Repo map zoom out

Skill stark-ai-de/agent-skills/incubator/skills/engineering-workflows/repo-map-zoom-out

Public Agent Skills for Codex operations, Cursor operations, Claude operations, repo maintenance, skill maintenance, productivity, and engineering workflows.

Install

npx -y skills add stark-ai-de/agent-skills --skill repo-map-zoom-out

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

4 stars4 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

Map unfamiliar code areas before implementation by identifying entry points, ownership boundaries, callers, data flow, ADRs, validation, and likely edit surfaces. Use when the user asks to understand a subsystem, zoom out, map a repo area, or prepare for a risky change.

The file declares its own license as Apache-2.0. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.

SKILL.md

2.9 KB, as published. Nobody here has run it

Repo Map Zoom Out

Goal

Build a compact map of an unfamiliar code area so implementation starts with the right boundaries, dependencies, and validation path.

When to use

The user asks to understand a subsystem, route, package, workflow, or architecture boundary.
A change looks risky because callers, data flow, or ownership are unclear.
An agent needs context before editing but should avoid broad file dumping.

When not to use

The user needs a direct code fix and the relevant files are already known.
The task is a full repo audit; use repo-health-audit.
The user wants an ADR; use adr-writer after the decision is clear.

Inputs to inspect

Repo tree, package files, routing files, tests, ADRs, domain docs, and validation docs.
Existing code search results for entry points, callers, imports, and tests.
CodeGraph or ast-grep outputs when available, but do not require them.

Workflow

Define the target area and the question the map must answer.
Identify entry points, exported APIs, routes, commands, jobs, or event handlers.
Trace likely callers, callees, imports, data models, and side effects.
Locate tests, fixtures, validation commands, docs, and relevant ADRs.
Produce a compact map with likely edit surfaces and risk points.
Recommend next implementation or investigation steps.

Safety rules

Do not read broad files just to fill space; prefer targeted search and source ranges.
Do not treat naming similarity as proof of ownership.
Do not propose edits until the map identifies the likely affected surface.
Do not claim complete coverage when only a subset was inspected.

References

No bundled references. If codegraph-ast-grep is available and the repo is indexed, it can help with symbol lookup and structural search. Local ADRs and domain docs should be inspected when relevant.

Scripts

No bundled scripts.

Output format

Return:

Target question
Entry points
Main data or call flow
Ownership boundaries
Tests and validation
Relevant docs or ADRs
Likely edit surfaces
Risks and unknowns

Completion criteria

The map is specific enough to guide implementation.
Relevant tests and validation are identified.
Unknowns are explicit.
The next step is clear.

Failure modes

If the target area is too broad, ask for a narrower subsystem or user workflow.
If code search is inconclusive, list the searched terms and fallback path.
If docs and code disagree, prioritize code behavior and note the docs drift.