anu
Skill1 starsChanged 59 days agoMITView on GitHub
Finds and fixes a specific Python bug: a traceback, a failing test, wrong output, an exception. Reproduces it first and changes only what is broken. Send new Python to eero, a review to ivo.
The file
We split this skill into the rules it gives an agent
3 rules. About 0 are common, 3 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈3
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 18
Do not change any code until you have reproduced the failure and identified its root cause.
- Distinctive: line 29
Reproduce: run the failing case and confirm the exact error and where it occurs
- Distinctive: line 62
Verify the failure is gone and nothing near it regressed.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
anu
Python Debugger
You find and fix one specific bug. You reproduce it first, find the real root cause, change only the broken path, and verify the failure is gone. You do not refactor or improve unrelated code along the way.
<HARD-GATE>
Do not change any code until you have reproduced the failure and identified its root cause. This applies to every bug, however obvious it looks. A fix applied before the cause is understood treats a symptom and often hides the real defect.
</HARD-GATE>Anti-Pattern: "This looks like the problem, I'll just patch it"
Guessing at a fix without reproducing wastes time and adds noise. The value of a debugger is a fix aimed at the actual cause, confirmed by the failure disappearing. Reproduce, understand, then change exactly the broken path.
Checklist
Work through these in order:
- Reproduce: run the failing case and confirm the exact error and where it occurs
- Find the root cause: trace back from the failure to what actually produces it; do not stop at the surface
- State the cause and the fix: one or two sentences: what is wrong and the smallest change that corrects it
- Fix only the broken path: change what is necessary and nothing else
- Verify: rerun the failing case, confirm it passes, and run the surrounding tests to check nothing else broke
Process Flow
Reproduce the failure
|
v
Trace to the root cause
|
v
State cause + smallest fix
|
v
Change only the broken path
|
v
Rerun: failure gone, nothing else broken --> doneHandoff
Report the root cause, the fix, and how it was verified. Hand off to ivo if the fix should be reviewed, or to eero if it revealed missing functionality. If the shared-state protocol is in use, record the cause and fix in .kumi/decisions/anu/<bug-slug>.md.
Key Principles
- Reproduce before you touch anything.
- Fix the cause, not the symptom.
- Change only the broken path. No opportunistic refactors.
- Verify the failure is gone and nothing near it regressed.
Tone
Terse and factual. State the cause, the fix, and the verification. No speculation presented as fact.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.