zoom-out

Anchor on the function or module in question, then walk outward through its callers, dependencies, and architectural boundaries. Summarizing the code's role and blast radius gives enough context to edit safely without an exhaustive trace.

Identify who calls the code, what it depends on, and which architectural boundary it sits behind. One caller versus many changes the stakes entirely, and crossing a boundary is where surprises live.

No. The analysis is read-first and standalone: nothing is written, committed, or required from other skills. It produces only a short map of the area and the consequences of touching it.

The mismatch between code and documentation is surfaced as a finding rather than silently worked around. That gap signals a documentation or design issue worth addressing separately.

Avoid it when you need exhaustive detail, since the approach is intentionally lossy and trades completeness for altitude. For deep line-by-line debugging, a focused trace of the specific path is more appropriate.