Explain this

Explain how $ARGUMENTS works — the file, symbol, or path the user named — as a read-only investigation that produces a written explanation, not a code change.

Resolve the target

• If $ARGUMENTS is a path or file, start there. If it's a bare symbol (function, class, type, constant), locate its definition with grep/symbol search before reading.
• If $ARGUMENTS is empty, find the real entry point: read package.json/pyproject.toml/Cargo.toml/go.mod/Makefile for the main/bin/scripts target, or the framework's conventional root (main, index, app, cmd/). State which entry point you chose and why.
• Detect the stack and its conventions from manifests and neighboring files (dependency list, naming style, module/folder layout, error-handling idioms); explain in the project's own vocabulary and file names, not a generic template.

Investigate

• Read the target fully, then follow its edges: what calls it (callers/routes/CLI), what it calls (imports, services, DB, network), and where its output goes.
• Trace the primary path end to end. If the target has several equally-important call sites, overloads, or fans out to multiple handlers, trace the one that most represents its purpose in full, then list the rest with file:line and a one-line note on how each differs. Open every file you cite — never infer behavior from a name. Prefer reading the implementation over docstrings/comments, which may lie.
• Identify the data that flows through: key structures, their shape, where state is created, mutated, and persisted. Note ownership and lifetime.
• Hunt the non-obvious: concurrency, retries, caching, error/edge handling, feature flags, implicit ordering, side effects, and anything that would surprise a new contributor. Check tests to confirm intended behavior; if there are none, infer intent from callers, usage sites, and in-code validation/assertions, and flag that behavior is unverified by tests.

Output

Produce Markdown with these sections. Back every concrete claim about what the code does with a path:line reference; for judgment calls (why it exists, whether something is intentional), state it as your read of the code and cite the evidence you based it on rather than forcing a single line number.

1. Summary — 2-4 sentences: what it does, and your best read of why it exists (grounded in callers/usage, not a single line).
2. Flow — an ordered walkthrough: entry → key steps → output, each step tagged with file:line.
3. Data & state — the important structures/variables, their purpose and where they live.
4. Gotchas — non-obvious behavior, invariants, edge cases, and assumptions that can bite.
5. Open questions — anything you could not verify from the code.

Rules

• Never edit, run, or stage anything. This command only reads and reports.
• Always cite file:line for concrete claims about behavior; for inferences and judgments say so explicitly and name the evidence, rather than presenting them as line-cited fact.
• Mark unknowns as unknown — do not guess and present it as fact.
• Match depth to the target's size: a one-file utility gets a tight answer; a subsystem gets the map plus the one path that matters most. Do not pad.
• Explain the actual code in front of you, including its warts — not how it ideally should work.