debugging

Name: debugging
Author: sordi-ai

17stars3forks

How to install debugging?

sordi-ai/skill-everything/debugging

$npx -y skills add sordi-ai/skill-everything --skill debugging

Installs into the current project.

Summary

Apply when diagnosing a bug, reproducing a failure, or performing root cause analysis. Covers systematic isolation, binary search, logging strategy, and hypothesis-driven investigation.

Files · 1

View on GitHub

SKILL.md

1	# Sub-Skill: Debugging
2
3	Purpose: Systematic techniques for reproducing failures, isolating variables, and finding root causes without guessing. Complements `skills/tdd/SKILL.md` — a failing test is the best reproduction case.
4
5	---
6
7	## Rules
8
9	### Reproduction
10
11	1. Reproduce before fixing. Before changing any code, confirm you can trigger the failure on demand. A fix applied to an unreproduced bug is a guess, not a solution. Reference: ERR-2026-018
12	2. Capture the minimal reproduction. Reduce the failing scenario to the smallest input, fewest dependencies, and shortest code path that still exhibits the symptom. Smaller reproductions expose the cause faster and prevent regression.
13	3. Write the reproduction as a test. Encode the reproduction case as an automated test before touching production code. This locks in the failure signal and prevents silent regression. See `skills/tdd/SKILL.md`.
14
15	### Isolation
16
17	4. Change one variable at a time. Never modify multiple suspects simultaneously. Each change must be independently observable so you know which variable caused the change in behaviour.
18	5. Use binary search on the call stack. When the failure source is unknown, bisect: confirm the bug is present at the midpoint of the execution path, then recurse into the half that contains it. Avoid reading every line top-to-bottom.
19	6. Prefer structured logging over print-debugging. Add log statements at decision boundaries with structured key-value pairs (not free-form strings). Structured output is grep-able, diffable, and removable without side effects.
20
21	### Hypothesis and Root Cause
22
23	7. State a falsifiable hypothesis before each experiment. Write down: "I believe X causes Y because Z. If I change X, Y should disappear." Run the experiment. If the hypothesis is wrong, update your model before the next experiment.
24	8. Distinguish symptom from cause. The error message or stack trace is the symptom. The root cause is the incorrect assumption, missing guard, or wrong state that produced it. Never stop at the symptom — trace back to the decision that allowed the bad state to exist.
25	9. Do not fix symptoms in isolation. Patching the symptom without addressing the root cause produces a second bug that hides the first. Ensure the fix makes the root cause impossible, not just the observed symptom unlikely.
26
27	### Verification
28
29	10. Verify the fix with the reproduction test. After applying the fix, confirm the reproduction test now passes and no previously passing tests regressed. A fix that breaks other tests has introduced a new bug.
30	11. Ensure the fix is observable. After merging, confirm the symptom is gone in the target environment using the same signal (log line, metric, test) that first revealed the bug. Never declare a bug fixed without an observable confirmation.
31
32	---
33
34	## See also
35
36	- `skills/tdd/SKILL.md` — write the reproduction as a failing test first
37	- `skills/code-quality/SKILL.md` — narrow exception catches to avoid masking bugs (ERR-2026-016)
38	- `skills/error-log/SKILL.md` — errors that motivated rules in this skill
39
40	---
41
42	## Notes
43
44	- Binary search applies to time too. Use `git bisect` to find the commit that introduced a regression; do not read the full diff manually.
45	- Logging is temporary. Remove or gate debug log statements behind a flag before merging. Permanent debug noise degrades signal quality for the next investigation.

People who liked this also viewed

6 picks

Type

azure-diagnosticsDebug Azure production issues on Azure using AppLens, Azure Monitor, resource health, and safe triage. WHEN: debug production issues, troubleshoot app service, app service high CPU, app service deploySkillsJul 2026472k1.3k
systematic-debuggingUse when encountering any bug, test failure, or unexpected behavior, before proposing fixesSkillsJul 2026197k259k
safe-debugRigor Debug / Rigor Audit skill for deep learning research work. Use when the user pastes a traceback, terminal error, CUDA OOM, checkpoint load failure, shape mismatch, NaN loss symptom, or training SkillsMay 2026161k507
explore-runRigor Improve / Rigor Explore run leaf skill for bounded exploratory evidence in deep learning research repositories. Use when the researcher explicitly authorizes exploratory runs such as small-subseSkillsMay 2026161k507
minimal-run-and-auditRigor Run skill for README-first deep learning repo reproduction. Use when the task is specifically to capture or normalize evidence from the selected smoke test or documented inference or evaluation SkillsMay 2026161k507
insforge-debugUse when diagnosing problems in an InsForge project — reactive failures (SDK error object, HTTP 4xx/5xx, gateway timeout 502/503/504, edge function failure or timeout, login/OAuth/auth errors, RLS denSkillsJul 202618k31

debugging

17stars3forks

View on GitHub

How to install debugging?

sordi-ai/skill-everything/debugging

$npx -y skills add sordi-ai/skill-everything --skill debugging

Installs into the current project.

Summary

Apply when diagnosing a bug, reproducing a failure, or performing root cause analysis. Covers systematic isolation, binary search, logging strategy, and hypothesis-driven investigation.

Files · 1

View on GitHub

SKILL.md

1	# Sub-Skill: Debugging
2
3	Purpose: Systematic techniques for reproducing failures, isolating variables, and finding root causes without guessing. Complements `skills/tdd/SKILL.md` — a failing test is the best reproduction case.
4
5	---
6
7	## Rules
8
9	### Reproduction
10
11	1. Reproduce before fixing. Before changing any code, confirm you can trigger the failure on demand. A fix applied to an unreproduced bug is a guess, not a solution. Reference: ERR-2026-018
12	2. Capture the minimal reproduction. Reduce the failing scenario to the smallest input, fewest dependencies, and shortest code path that still exhibits the symptom. Smaller reproductions expose the cause faster and prevent regression.
13	3. Write the reproduction as a test. Encode the reproduction case as an automated test before touching production code. This locks in the failure signal and prevents silent regression. See `skills/tdd/SKILL.md`.
14
15	### Isolation
16
17	4. Change one variable at a time. Never modify multiple suspects simultaneously. Each change must be independently observable so you know which variable caused the change in behaviour.
18	5. Use binary search on the call stack. When the failure source is unknown, bisect: confirm the bug is present at the midpoint of the execution path, then recurse into the half that contains it. Avoid reading every line top-to-bottom.
19	6. Prefer structured logging over print-debugging. Add log statements at decision boundaries with structured key-value pairs (not free-form strings). Structured output is grep-able, diffable, and removable without side effects.
20
21	### Hypothesis and Root Cause
22
23	7. State a falsifiable hypothesis before each experiment. Write down: "I believe X causes Y because Z. If I change X, Y should disappear." Run the experiment. If the hypothesis is wrong, update your model before the next experiment.
24	8. Distinguish symptom from cause. The error message or stack trace is the symptom. The root cause is the incorrect assumption, missing guard, or wrong state that produced it. Never stop at the symptom — trace back to the decision that allowed the bad state to exist.
25	9. Do not fix symptoms in isolation. Patching the symptom without addressing the root cause produces a second bug that hides the first. Ensure the fix makes the root cause impossible, not just the observed symptom unlikely.
26
27	### Verification
28
29	10. Verify the fix with the reproduction test. After applying the fix, confirm the reproduction test now passes and no previously passing tests regressed. A fix that breaks other tests has introduced a new bug.
30	11. Ensure the fix is observable. After merging, confirm the symptom is gone in the target environment using the same signal (log line, metric, test) that first revealed the bug. Never declare a bug fixed without an observable confirmation.
31
32	---
33
34	## See also
35
36	- `skills/tdd/SKILL.md` — write the reproduction as a failing test first
37	- `skills/code-quality/SKILL.md` — narrow exception catches to avoid masking bugs (ERR-2026-016)
38	- `skills/error-log/SKILL.md` — errors that motivated rules in this skill
39
40	---
41
42	## Notes
43
44	- Binary search applies to time too. Use `git bisect` to find the commit that introduced a regression; do not read the full diff manually.
45	- Logging is temporary. Remove or gate debug log statements behind a flag before merging. Permanent debug noise degrades signal quality for the next investigation.

People who liked this also viewed

6 picks

Type