debug-mantra
Four-mantra debugging discipline — reproduce, trace the fail path, falsify the hypothesis, cross-reference every breadcrumb. Recite the mantra block verbatim at the start of any debugging session, then apply the four steps in order before proposing any fix. Trigger on /debug-mantra and proactively whenever debugging starts — user reports a bug, says something is broken/throwing/failing, asks to debug/diagnose/investigate an issue, or pastes a stack trace or error log.
Оригинален текст · няма потвърден превод на българскиПърво прочетете инструкцията.
Файлът се зарежда от посочения източник само по ваше действие. Можете да го прочетете тук, да го копирате или да го запазите като .md.
GitHub хранилище- Звезди на репото
- 3196
- Лиценз
- Не е посочен. Проверете в репозитория.
- Последна проверка на записа
- 22.09.2026 г.
Добавете в своя инструмент.
Командата отваря избора на skills от репозитория. Прочетете файла и условията на автора преди изпълнение.
npx skills add thananon/9arm-skillsСтраницата копира текст. Не инсталира и не изпълнява нищо на устройството ви.
Откъс от SKILL.md
Началото на файла на автора, без превод.
Debug Mantra
Four-step discipline for any debug session. Recite verbatim, then apply in order.
Recite this — verbatim, as the first thing in your first response
Mantra:
- First is reproducibility. Can the issue be reproduced reliably?
- Know the fail path. Debugger first; then source trace + knob enumeration; then in-code instrumentation.
- Question your hypothesis. What would disprove it?
- Every run is a breadcrumb. Cross-reference all of them.
Then begin work.
1. Reproduce reliably
Build a runnable repro before anything else.
- Reliable repro → capture the exact steps, inputs, and environment as a runnable artifact: failing test, curl script, CLI invocation, replay harness.
- Flaky repro → the bug is not yet debuggable. Raise the rate first: loop the trigger, parallelise, add stress, narrow timing windows, inject sleeps. 50% flake is debuggable; 1% is not.
- No repro at all → stop. Say so explicitly. Ask the user for env access, captured artifacts (HAR, log dump, core), or permission to instrument. Do not proceed to hypothesise.
Target: a fast (1–5 s), deterministic pass/fail signal. Pin time, seed the RNG, freeze network, isolate filesystem.
2. Know the fail path
Once reproducible, find where the code breaks and what stops it from breaking. The differential narrows the search. Try in this order — escalate only when the prior tactic fails.
- Attach a debugger. If the env supports it, attach and step to the failure site. One breakpoint beats ten logs. Do this before turning any knobs.
- Source trace + knob enumeration. If no debugger (or it can't reach the bug), trace the code path end-to-end and list every knob that can influence the outcome:
- config flags, env vars, feature toggles
- branch conditions, input shape
- timing, concurrency, build options Each knob is a candidate axis to flip in the differential. Flip one at a time.
- In-code instrumentation. If outside knobs can't move the failure, go inside:
printf/ log statements at the suspected fail site, dump the relevant internal state. Tag every probe with a unique prefix (e.g.[DBG-a4f2]) so cleanup is a single grep. Let the trace show where reality diverges from your model.
3. Falsify the hypothesis
When a candidate root cause surfaces, scrutinise it before testing it.