debugging — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited 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.
A systematic, scientific approach to finding and fixing bugs — replacing guesswork with method.
"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." — Brian Kernighan
npx clawhub@latest install debuggingDebugging is not guessing. It is applied science.
Every debugging session should follow this loop. If you catch yourself making random changes and re-running, stop — you've left the scientific method.
Choose the method that matches the situation:
| Method | When to Use | How It Works |
|---|---|---|
| Binary search | Large codebase, unknown origin | Bisect code or commits to narrow location by half each step |
| Hypothesis testing | Known symptoms, multiple possible causes | Form specific hypothesis, design targeted test, verify or refute |
| Minimal reproduction | Complex bugs, intermittent failures | Strip away code, config, and data until smallest case reproduces |
| Trace analysis | Flow-based bugs, wrong output | Follow data or execution path step by step from input to output |
| Rubber duck | Stuck, unclear thinking, no progress | Explain the problem aloud — forces clarity and often reveals the answer |
| Divide and conquer | Multi-component issues, integration bugs | Isolate each component, test independently, find which misbehaves |
Most real bugs require combining methods. A typical pattern:
Follow these six steps in order. Do not skip ahead.
Can you make the bug happen reliably? Write down the exact steps.
If you cannot reproduce it, you cannot confirm you have fixed it.
Narrow the scope. Which component, file, function, or line?
git log --oneline -20 and git diffUnderstand the root cause, not just the symptom.
Make the smallest change that addresses the root cause.
Confirm the fix resolves the original reproduction case.
Add safeguards so this class of bug cannot recur.
| Tool | Purpose | When to Reach for It |
|---|---|---|
| Debugger | Set breakpoints, step through execution, inspect state | Logic errors, unexpected control flow |
| Logging | Add strategic log statements at key points | Flow tracing, production issues, async bugs |
| Profiler | Measure CPU, memory, and timing | Performance regressions, slow endpoints |
| Network inspector | Inspect HTTP requests, responses, headers, timing | API integration bugs, auth failures, CORS |
| Memory analyzer | Heap snapshots, allocation tracking, leak detection | Memory leaks, growing memory usage |
[OrderService.processPayment]Recognize the pattern to find the fix faster:
| Category | Typical Symptoms | First Things to Check |
|---|---|---|
| Null reference | "Cannot read property of undefined/null" | Input validation, optional chaining, API response shape |
| Off-by-one | Missing first/last item, extra iteration, boundary failure | Loop bounds, array indices, fence-post conditions |
| Race condition | Intermittent failures, order-dependent, works in debugger | Shared mutable state, missing locks/awaits, event ordering |
| Memory leak | Growing memory over time, eventual OOM or slowdown | Event listeners not removed, closures holding references, cache without eviction |
| State management | UI out of sync, stale data, phantom updates | Mutation vs immutability, missing re-renders, stale closures |
| Encoding | Garbled text, wrong characters, hash mismatches | UTF-8 vs Latin-1, URL encoding, base64 padding |
| Timezone | Times off by hours, wrong dates near midnight | UTC vs local, DST transitions, serialization format |
| Async ordering | Operations complete in unexpected order | Missing await, unhandled promise, callback timing |
| Configuration | Works locally, fails in staging/production | Environment variables, feature flags, config file differences |
| Dependency version | Broke after update, works with old version | Lock file changes, breaking API changes, peer dependency conflicts |
When you know a bug was introduced between two commits, git bisect finds the exact breaking commit using binary search.
# 1. Start bisect
git bisect start
# 2. Mark the current (broken) commit as bad
git bisect bad
# 3. Mark a known good commit
git bisect good abc1234
# 4. Git checks out a middle commit — test it, then tell git:
git bisect good # if this commit works fine
git bisect bad # if this commit has the bug
# 5. Repeat until git identifies the first bad commit
# Output: "<commit-hash> is the first bad commit"
# 6. Examine the breaking commit
git show <commit-hash>
# 7. End the bisect session
git bisect resetIf you have a test script that exits 0 for good and non-zero for bad:
git bisect start
git bisect bad HEAD
git bisect good abc1234
git bisect run ./test-for-bug.shGit runs the script at each step automatically and reports the first bad commit.
Use this checklist when you've been stuck for more than 15 minutes. Answer each question explicitly:
If you've spent more than 30 minutes without progress: step back and re-read the error from scratch, explain the problem aloud (rubber duck method), take a 10-minute break, try a completely different hypothesis, ask for help, or reduce scope by building the smallest reproduction from scratch.
After fixing a bug, invest time to prevent its recurrence:
| Action | How It Helps |
|---|---|
| Add a regression test | Ensures this exact bug cannot return undetected |
| Improve types | Catches null, undefined, and shape mismatches at compile time |
| Add runtime assertions | Fails fast with a clear message instead of silent corruption |
| Document the fix | Helps future developers understand the "why" behind the code |
| Review related code | The same mistake pattern may exist in similar locations |
| Update monitoring | Add alerts or dashboards so the symptom is caught earlier next time |
Behaviors that waste time and make bugs harder to find:
| Anti-Pattern | Why It Fails | Do This Instead |
|---|---|---|
| Random changes | Introduces new bugs, obscures original cause | Follow the scientific method — one variable at a time |
| Fixing symptoms | The root cause remains and will resurface | Ask "why?" until you reach the actual defect |
| Debugging in production | Risk to users, limited tooling, high stress | Reproduce locally or in staging first |
| Not reproducing first | You cannot confirm a fix for a bug you cannot trigger | Invest the time to build a reliable reproduction |
| Ignoring error messages | The answer is often in the message you skipped | Read the full error, including stack trace and context |
| Assuming your code is correct | Confirmation bias hides obvious mistakes | Re-read your code as if someone else wrote it |
| Changing multiple things at once | You cannot tell which change fixed (or broke) it | Make one change, test, then move to the next |
| Debugging while fatigued | Tired debugging creates more bugs than it fixes | Take a break, come back with fresh eyes |
~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.