Error Forensics Is Its Own Discipline — and the Scores Prove It

Every engineer has watched an LLM "debug": read the stack trace, guess a fix, re-run, guess again. Two skills in the directory — debugging-wizard at 9.3 and monitoring-expert at 9.2 — formalize the alternative: errors are evidence, and evidence gets a forensics workflow.

Debugging is where agent behavior most visibly splits from senior-engineer behavior. Given a failing test, the agent pattern-matches a plausible cause, patches, re-runs, and repeats. It's a slot-machine loop: cheap per pull, unbounded total cost. A senior engineer instead treats the error as an artifact worth reading — what does this trace actually say, what was the execution path that produced it, what does the timing of this log line rule out?

Two skills in our directory score at the top of everything debugging-adjacent, and they're both built on the second posture.

Parse the error, then reconstruct the path

debugging-wizard — 9.3 is one of the highest-scoring skills in the entire directory, and its evaluation summary says exactly why: it doesn't contain "debugging tips." It contains an evidence workflow.

The skill's first move is error forensics in the literal sense — destructure the message, the stack trace, and the error class before touching any code. Which frame is yours, which is library, which is the boundary where a bad value crossed? Its second move is execution-flow tracing: reconstruct what the program actually did between the entry point and the failure, not what the code appears to say it does. Only after both does it form a hypothesis.

That ordering — parse, reconstruct, then hypothesize — is precisely the discipline the guess-and-patch loop lacks. The slot machine never builds a model of the failure; it samples fixes against it. debugging-wizard scores 9.3 because it forces the model to accumulate evidence before it spends tokens on candidate fixes. In our scoring, skills that reorder "understanding before action" this explicitly almost always pay for it.

Logging is the part you write before the bug

The companion insight lives in monitoring-expert — 9.2, a skill nominally about production monitoring that's secretly about the same discipline applied earlier: structured logging.

Unstructured logs — free text, timestamps, vibes — are evidence you can't interrogate. The moment you need to filter by request ID, or group by error class, or count occurrences across a deployment boundary, prose fails you. Structured logs with consistent fields turn "something failed around then" into a queryable record. monitoring-expert enforces field conventions and severity semantics, and its 9.2 reflects something our evaluators reward rarely: a skill that changes the ground truth available to future debugging sessions, not just the current one.

It's the same discipline that earns cli-developer its 9.3 — machine-readable output as a contract with whatever consumes it next. A tool that reports failure as an exit code and a JSON line, and a log that records failure as structured fields, are the same idea wearing different interfaces: output built to be interrogated by a machine. Debugging skills live downstream of that contract.

Together the two skills describe a lifecycle. You can't do good error forensics on a system that emitted bad evidence. The forensics skill consumes what the logging skill produces. They're one discipline, split across the moment of failure.

Why this matters more for agents than for humans

A human engineer debugging on intuition will eventually notice their mental model is wrong — the feedback is their own confusion. An agent in the guess-and-patch loop notices nothing: every failed fix looks like progress ("one more hypothesis eliminated!"), so the loop can run for dozens of iterations while feeling productive.

Forensics-style skills are the structural fix. They force an intermediate artifact — a reconstruction of the execution path — that either matches the error or doesn't, before any patch is attempted. That's a verifiable intermediate state, and verifiable intermediate states are how you turn an unbounded search into a bounded one.

The scores aren't a coincidence. debugging-wizard at 9.3 didn't get there by knowing more about bugs; it got there by refusing to let the agent guess until the evidence was on the table.

Read the trace. Reconstruct the path. Then, and only then, form a hypothesis. It's the same advice humans get — the difference is that agents actually need it written down.