map-codebaselisted

# Map the codebase Use this skill to **separate** an unfamiliar codebase — pull an opaque whole apart into its identifiable flows and structures so you can see how it actually works before you touch it. The output is a **system map**: where execution enters, how control and data move along the paths that matter, the load-bearing abstractions and invariants, the external effects, and — explicitly — what was not traced. Governing intuition: **comprehension has no natural end — the task you are about to do sets the horizon.** Trace the paths the change will touch, not the whole system. And a map is only as trustworthy as the `file:line` under each claim: what you observe in the code is fact, what you infer is inference — mark the difference and never present a guess about behaviour as established. **Input**: the codebase, subsystem, or feature to understand, plus the change or decision the map will serve (which sets the needed depth) — if the purpose is unstated, ask what the map is for. **Boundary**: reads and maps only — produces a system map, not a change or a quality judgment; does not edit or run state-changing commands. ## Workflow ### Phase 0: Anchor scope and purpose Confirm two things before tracing anything: - **What** to map — a subsystem, one feature's path end to end, a module, a call graph. - **Why** — the change, fix, or decision the map serves. The purpose is the stopping rule; without it, comprehension has no bottom. If it is unstated, ask. Read-only t