Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add skills/camilooscargbaptista/cto-toolkit/systematic-debuggingnpx skills add camilooscargbaptista/cto-toolkit --skill systematic-debugginggit clone --depth 1 https://github.com/camilooscargbaptista/cto-toolkitWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/camilooscargbaptista/cto-toolkit/systematic-debugging)<a href="https://agentmods.dev/skills/camilooscargbaptista/cto-toolkit/systematic-debugging"><img src="https://agentmods.dev/badge/skills/camilooscargbaptista/cto-toolkit/systematic-debugging.svg" alt="Measured on agentmods" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00136 | $0.01988 |
| Opus 5 | $0.00068 | $0.00994 |
| Sonnet 5 | $0.00027 | $0.00398 |
| Haiku 4.5 | $0.00014 | $0.00199 |
Grade A, and why
systematic-debugging scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 4d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 258 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Systematic Debugging Methodology
You are a senior engineer helping debug issues methodically. The biggest debugging mistake is jumping to conclusions — resist the urge to guess and instead follow a structured process. Every bug is logical; the code is doing exactly what it was told to do.
The Scientific Debugging Method
1. OBSERVE → Gather symptoms and data
2. HYPOTHESIZE → Form a testable theory
3. PREDICT → What would be true if the hypothesis is correct?
4. TEST → Run an experiment to confirm or refute
5. CONCLUDE → Either fix it or form a new hypothesis
Never skip steps. The most common debugging failure is jumping from OBSERVE to a fix without testing the hypothesis.
Step 1: Observe — Gather Information
Before touching code, answer these questions:
What is the expected behavior?
- What should happen according to the spec/user story?
- Did this ever work? When did it stop?
What is the actual behavior?
- Exact error message (not paraphrased)
- Stack trace (full, not truncated)
- HTTP status code, response body
- Console output, log entries
What are the conditions?
- Reproducible or intermittent?
- Steps to reproduce (minimal set)
- Which environment? (local, staging, production)
- Which users/accounts/data affected?
- What changed recently? (deploy, config, dependency update)
Collect evidence:
# Recent changes
git log --oneline -20
git log --since="3 days ago" --oneline
# Recent deploys
# (check your CI/CD system)
# Relevant logs
# Tail application logs, filter by error level
# Check for correlation: timestamp of first occurrence vs deploys
# System state
# CPU, memory, disk, network
# Database connections, queue depth
# Cache hit rates
Step 2: Hypothesize — Form Theories
List possible causes ranked by likelihood. Consider:
Common bug categories:
- State bug — Variable has unexpected value at some point
- Timing bug — Race condition, async ordering, timeout
- Data bug — Corrupt input, encoding issue, null/undefined
- Integration bug — API contract mismatch, version incompatibility
- Configuration bug — Wrong env var, missing secret, feature flag
- Resource bug — Memory leak, connection pool exhaustion, disk full
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 4d ago First seen · 258 lines · 136 tokens per session scan A d76408788a7e
systematic-debugging is a skill published in the GitHub repository camilooscargbaptista/cto-toolkit (7 stars, last pushed 5mo ago), licensed MIT. It adds 136 tokens to every session and 1,988 once invoked, about $0.0007 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other skills, from other repositories
systematic-debugging
4-phase root cause debugging: understand bugs before fixing.
performance-audit
Full-stack performance health check across 12 dimensions. Rendering, bundles, assets, API/network, algorithms, memory, database, caching, Web Vitals, backend runtime, concurrency, and framework-specific pathologies. Evidence-based Impact Models with confidence tiers and a prioritized optimization roadmap. Switches…
self-improving-agent
Log learnings, errors, and corrections to .learnings/ for continuous improvement. Use when: (1) A command or operation fails unexpectedly, (2) User corrects the agent, (3) A knowledge gap is identified, (4) A better approach is found. Captures corrections, insights, errors, and feature requests; promotes broadly…
docs-refresh
Full documentation hygiene pass: memory, CLAUDE.md, lessons, references, guides. Audit freshness, delete stale, update outdated, compress index.
scale-canary
Performance complexity and resource allocation canary — checks for O(N^2) loops, database N+1 query patterns, memory leaks (unbounded collections), and blocking calls in main event loop. Triggers on keywords: "/scale-canary", "scale-canary", "performance audit", "scale audit". Use when writing loops over growing data…
scratchpad
Persistent iteration memory — prevents Groundhog Day loops by recording what was tried, what failed, and what to try next.