module-map

module-map

Orient fast in unfamiliar code. The deliverable is a map, not a tour.

Deliverable

A single response containing, in this order:

1. One-line summary of what the area does from a caller's point of view.
2. Entry points — every function, route, CLI command, event handler, or cron that starts a call chain in this area. File path + symbol.
3. Core modules — the two to five modules that contain the real logic. One line each describing their role.
4. Data flow — ASCII arrows showing the dominant path for the most common input. Skip error paths unless they matter architecturally.
5. External callers — who outside this area calls in, and through which entry points.
6. Hidden coupling — anything that looks independent but is not (shared singletons, global state, implicit ordering, undocumented contracts between files).

Rules

• Fifteen-second read target. If the map exceeds one screen, cut it.
• Every claim must be backed by a file path. No remembered or inferred structure without a grep behind it.
• Do not list every file. Curate. A good map omits deliberately.
• Do not propose changes. Mapping is orientation; refactoring is a different skill.
• If the area is too large to map in one screen, segment it and ask the user which segment to expand. Do not silently drop half the code.

Format

AREA: <one-line summary>

ENTRY POINTS
- <path>:<symbol>  — <role>

CORE MODULES
- <path>  — <role>

FLOW
<entry> -> <module> -> <module> -> <sink>

CALLERS
- <path>  — uses <entry>

HIDDEN COUPLING
- <description>  (<path>)

Use the exact headers. Consistency lets the user scan.