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.
```
No worries! Here's the full prompt if you need it: https://sharetext.io/g6ibuxa5 (you'll probably need to update it, as there're specific things I wanted it to take into account)
Ultimately my point is to define small contexts grounding agents in tasks you expect them to do. Trying to define guidelines for everything will not work = telling it that it shouldn't delete prod AND that it's architect AND that it should review code using this and this principle AND milliard other things that you expect from yourself.