systematic-debugging — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited systematic-debugging (Agent Skill) and scored it 100/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 0 flagged
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
Never skip to fixing. Understand the cause first. A fix applied without understanding the root cause is a coin flip — it may mask the symptom while leaving the disease.
Follow skills/progress-tracking/SKILL.md: when this procedure has two or more steps, seed one todo item per step before starting and mark each complete as you go.Gather evidence before forming any theories. The goal is to build a factual picture of what is happening.
trace is the geography; the last frame before your code is where to look.
your fix. Document the exact reproduction steps.
error messages are a pattern. Gather logs, stack traces, test output, and runtime state.
narrows the search space dramatically.
just before? Check git log, deployment history, and dependency updates.
runs is not "flaky" — it is reporting a real condition (timing, ordering, resource contention, hidden global state) that most invocations don't hit. The conditions that make a test intermittent are frequently the conditions that make the product intermittently misbehave in production. Record the failure rate (e.g., 3/30 runs), the variance across environments (local vs CI), what is concurrent/asynchronous/stateful in the path, and any shared state (/tmp, env vars, singletons, DB rows).
Do not hypothesize during OBSERVE. Just collect.
Form theories that explain ALL the observed evidence. A hypothesis that explains only some observations is incomplete.
creates confirmation bias. List at least two plausible explanations.
before code. Environment before logic.
AND why related functionality still works.
else should be true? What should be false? These predictions become your tests.
Validate or eliminate hypotheses through targeted experiments. Test by elimination, not confirmation.
hypothesis regardless of the outcome. A test that can only confirm is subject to confirmation bias.
impossible to attribute the result.
and what actually happened — even for negative results.
do not revisit it unless new evidence emerges.
reason from first principles about which of 40 commits broke it — git bisect is faster and more reliable. Each step discriminates half the commit range. The same logic applies to config changes, dependency versions, and feature-flag rollouts.
Identify the root cause and design the fix.
is null." The root cause is "this function is called before initialization completes." Fix the root cause. To drill from the proximate cause down to the root, use the Root Cause Analysis (5 Whys) technique below.
must succeed after the fix. No other behavior should change.
missing null check), search for the same pattern elsewhere in the codebase.
benefit from knowing what was investigated and ruled out.
#### Root Cause Analysis (5 Whys)
To get from a proximate cause to a root cause, drill the causal chain. Take the proximate cause and ask "why?" — the answer is the next link. Ask "why?" of that link, and so on, until the chain bottoms out at a cause you can change.
repeatedly: "the variable is null" → why? → "the loader returned early" → why? → "the config flag was unset" → why? → "the flag defaults to off in this environment." Each "why?" turns a symptom into the next, deeper cause.
fact gathered in Phase 1 (a log line, a stack frame, a git change) — never a plausible-sounding guess. If you cannot point to evidence for a link, you have left the chain; go back to OBSERVE and collect more, do not invent the link.
contributing answers, drill each branch separately. The root is reached only when every branch bottoms out at a cause you can change.
your control to fix and one more "why?" would leave that control (e.g. a third-party default, a platform constraint, a human decision). Do not keep asking past that boundary — that is how you end up blaming the universe.
when you reach a controllable cause; do not manufacture five questions to hit a number. Five is the technique's name, not its quota.
Going too far blames a person instead of a process, or blames the universe — fix the process the person operated, not the person. Fabricating a chain without evidence (see "Anchor every link" above) invents a root that isn't real. Single-track tunnel vision ignores a branch that also contributed.
the deepest controllable cause — not at any proximate link above it. The test-driven-bug-fix mutation check (revert one line, confirm the test goes red) verifies the fix landed at the root and not on a symptom.
answers outside your control — never reaching a cause you can change — stop drilling and hand off to ## Escalation Rules below rather than looping.
If three hypotheses have been tested and eliminated, the investigation scope is too narrow. Expand:
Escalate when you have exhausted reasonable investigation:
When escalating, provide:
Never escalate with "I don't know what's wrong." Always escalate with "Here is what I've ruled out, and here is where I think the answer lies."
~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.