Root cause debugging
no-cape keeps the knowledge and drops the cape.
npx -y skills add yuchi-chang/no-cape --skill root-cause-debuggingAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
- 2 stars2 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Use when encountering a bug, test failure, regression, flaky test, or unexpected behavior — before proposing or applying any fix
SKILL.md
1.9 KB, as published. Nobody here has run it
Root-Cause Debugging
No fix until you can state the root cause and point to the evidence for it. Fixing symptoms wastes time and breeds new bugs.
Investigate first
- Read the complete error message and stack trace — they often contain the answer.
- Reproduce reliably. If you can't reproduce, gather more data instead of guessing.
- Check what changed: recent commits, dependency updates, config, environment.
- Trace bad values upstream to where they originate. Fix at the source, not where it crashed.
Multi-component systems (API → service → DB, CI → build → deploy)
Don't guess which layer is broken. Add logging at each component boundary (what enters, what exits, whether env/config propagates), run once, and read the evidence to locate the failing layer. Then investigate only that layer.
Hypothesis discipline
- One hypothesis at a time: "I think X is the cause because Y."
- Test it with the smallest possible change. Never stack multiple fixes in one attempt.
- Failed? Form a new hypothesis from the new evidence — don't pile another fix on top.
Stop rules
- 3 failed fixes → stop. Especially when each fix reveals a new problem somewhere else — that pattern means the architecture is wrong, not the code. Discuss before attempting fix #4.
- Catch yourself thinking "just try X and see" or "it's probably X, let me fix it" → return to investigation.
Landing the fix
Write a test that reproduces the bug: it must fail before your fix and pass after. If investigation shows the cause is genuinely environmental or timing-dependent, document what you ruled out and add handling (retry/timeout) plus logging — but most "no root cause found" is just incomplete investigation.