I have a skill for exactly such case! Here's an excerpt :)

``` --- name: evidence-debugging description: > Use when debugging any failing test or bug, investigating unexpected behavior, or tracing the cause of a reported defect. ---

# Debugging Discipline

## When to Use

- A test is failing and you need to understand why - Behavior is unexpected and the cause is unknown - The user asks you to debug or investigate a defect - You need to verify what a value actually is at runtime

*When NOT to use:* proactive code exploration without a specific failure to investigate.

## STOP — Do This Before Anything Else

Before reading code, before forming a hypothesis, before typing anything — answer these:

1. *Do I have actual output from a running system?* - No → instrument, run, save to file, read. Do not proceed until you have real output. - Yes → read it. Do not re-run.

2. *Am I about to explain what the issue "probably is" or "must be"?* - Yes → stop. That is deduction without evidence. It is a violation. Instrument instead.

3. *Am I about to touch passing code?* - Yes → stop. Only instrument the failing scope.

If you find yourself already reasoning about likely causes — you are already violating Rule 1. Stop. Go back to step 1. ```