Explain this error

Explain the error or stack trace in $ARGUMENTS: what it actually means, what most likely caused it, and the concrete fix — grounded in this codebase, not generic advice.

If $ARGUMENTS is empty, look for the error in the most recent terminal output, test run, or log; if none is visible, ask the user to paste the error or stack trace and stop.

Method

1. Parse the error. Identify the error type/class and the message, and note the language/runtime and framework from the syntax (Python traceback, JS at frames, Java Caused by, Go panic, Rust panic, compiler/linter diagnostic, etc.). If there is a stack trace, record every frame. If there is none — a compiler or build error, linter output, a bare Segmentation fault, or a runtime message with only a file:line or no location at all — extract whatever locators exist: the file:line in the message, the failing symbol or rule id, the offending command.
2. Locate candidate code. With a trace: separate library frames from application frames. The deepest in-project frame is the throw site and your first suspect, but not automatically the bug — the fault is frequently a caller a few frames up that passed bad state downward. Treat the throw site AND its in-project callers as candidates. Without a trace: jump to the file:line in the message, or grep for the message text / failing symbol to find the origin.
3. Read the actual code. Open each candidate in-project file:line with Read. Trace variable values and control flow backward from the throw site through its in-project callers to find both what state triggered the error and where that bad state was introduced.
4. Follow Caused by: / cause: chains and re-thrown wrappers to the root exception — the outermost message is often a symptom, not the cause.
5. Confirm the runtime context: check the relevant config, env vars, and dependency versions (package.json / requirements.txt / go.mod / lockfile). For "why does it fail now", check recent changes with git log/git diff -- <implicated file> — but only if the project is a git repo and the file has history; if git is unavailable or the file is untracked/new, say so and instead compare against the lockfile, config, or ask the user what changed recently.
6. Reproduce the meaning of the message precisely. For a known error type (NPE, undefined is not a function, KeyError, CORS, ECONNREFUSED, segfault, type mismatch, etc.), state the exact invariant that was violated — do not paraphrase vaguely.

Output

• What it means — 1-2 plain sentences. Translate the jargon; name the specific value/operation that failed (e.g. "user was null when .email was read at auth.ts:42").
• Where — the in-project file:line that throws, quoting the offending line; if the bad state originated in a different caller, name that site too and say which one you would edit.
• Most likely cause — the specific reason, tied to code you read. If multiple causes are plausible, rank them by likelihood and give each a one-line discriminator: the check, log, or command that confirms or rules it out.
• Fix — the concrete change: file, what to edit, and why it resolves the violated invariant. Match the project's existing patterns (error handling, null-checks, validation) rather than importing a new style. Note any adjacent call sites with the same latent bug.

Rules

• Never propose a fix for code you have not opened and read; do not guess at code that the trace or message lets you locate.
• Never suppress the symptom (empty catch, broad except, optional-chaining over a value that should exist, // @ts-ignore) unless the value is genuinely expected to be absent — fix the cause.
• Distinguish what the error proves from what you infer; mark inferences as such.
• Prefer the smallest change that fixes the root cause. Do not refactor beyond the bug.
• If the trace is truncated or the cause is genuinely ambiguous after reading the code, say so and name the one log line or command that would resolve it — do not invent a definitive answer.