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 skills add hams-ollo/zen-agent-skills --skill systematic-debugginggit clone --depth 1 https://github.com/hams-ollo/zen-agent-skillsWrote 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/hams-ollo/zen-agent-skills/systematic-debugging)<a href="https://agentmods.dev/skills/hams-ollo/zen-agent-skills/systematic-debugging"><img src="https://agentmods.dev/badge/skills/hams-ollo/zen-agent-skills/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.1 | $0.00209 | $0.05154 |
| Opus 5 | $0.00105 | $0.02577 |
| Sonnet 5 | $0.00042 | $0.01031 |
| Haiku 4.5 | $0.00021 | $0.00515 |
Grade A, and why
systematic-debugging scanned grade A with 1 finding 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 3d 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.
Makes network callslowCapability
Not a fault in itself. Listed so you know the mod talks to something, and to what.
note: fetched with urllib and digested with hashlib on the retrieved date, at 9,465 bytes. The digest pins upstream as of that date; this file is an adaptation and is expected to differ. How it starts
The opening of the file, as written. The whole thing — 357 lines — stays where its author put it; the contents beside it link to each section on GitHub.
systematic-debugging
Turn a reported defect into a named cause with the evidence that established it, distinct from the symptom that was reported, and stop there.
This skill is a draft. It ships with no profile and reaches no adopter until it has been used on
a real defect and blessed, per the contribution bar in the target repository's AGENTS.md.
When to use
- A defect, test failure, build failure, or unexpected behavior arrives and nobody has established why it happens.
- A test passes sometimes and fails other times, and somebody is about to call it fixed.
- A failure surfaces in one component and may originate in another.
- An agent working a task in isolation meets a failure its task file does not describe, and needs to tell a defect it introduced from one it uncovered.
- A task file is about to be written about a symptom. This is the step that belongs in between.
When not to use
- You want the defect fixed. This skill does not fix anything, and it will not be talked into it.
The fix is a task, and
fix-batchdispatches it. - You want the regression test written. That is
test-author. This names the observable that test must pin, and stops. - You want the task file written. That is
new-task, which this feeds. - You want to know whether a fix worked. That is
verifier-agent. - You want the code judged. A cause sitting in ugly code is still just the cause;
house-reviewowns quality. - You want to know whether the defect is worth fixing. That is a priority call, it belongs to the author, and it is expressed on the task file rather than here.
- The thing that went wrong is the agent rather than the repository. This diagnoses defects in a repository under work, not misfires of the harness running it. A run that has been confused by its own context is a different problem with a different answer, and pointing this procedure at it produces a confident cause for a defect that is not in the code.
- The cause is already established and agreed. Skip to whichever skill acts on it.
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.
- 3d ago First seen · 357 lines · 209 tokens per session scan A 9a4fa8bdbcb1
systematic-debugging is a skill published in the GitHub repository hams-ollo/zen-agent-skills (2 stars, last pushed 5d ago), licensed MIT. It adds 209 tokens to every session and 5,154 once invoked, about $0.0010 per session on Opus 5. A static security scan graded it A with 1 finding (makes network calls). No closer match exists in the catalogue, so it is treated as the original; first seen 2026-09-04.
Other skills, from other repositories
app-runtime-verify
Verify a built mobile or app runtime at runtime: run the app (device, emulator, or headless), read the captured runtime output (native logcat, iOS device log, or the Metro/JS console), classify any runtime errors against a per-stack taxonomy, and decide a PASS/FAIL runtime gate for the slice's acceptance behavior. The…
bug-fixing
Fix defects in the Composio SDK repository with focused reproduction, root-cause analysis, regression tests, and narrow verification. Use when the user reports a bug, failing test, CI regression, runtime defect, or incorrect SDK behavior. Do not use for new feature design or broad refactors.
python-testing
Select and run Python SDK verification with nox, Makefile targets, Ruff, mypy, pytest markers, sanity tests, type inference checks, and build checks. Use when adding Python tests, diagnosing Python CI, or validating Python SDK/provider changes. Do not use for TypeScript-only checks.
typescript-testing
Select and run TypeScript SDK verification for packages, examples, type checks, linting, builds, Vitest suites, and runtime E2E tests. Use when adding tests, diagnosing TypeScript CI, choosing a focused test command, or validating TypeScript package changes. Do not use for Python-only checks.
cli-e2e
Write, modify, or debug Docker-based Composio CLI end-to-end tests under ts/e2e-tests/cli, including binary invocation, fixture isolation, output assertions, and package manifests. Use for CLI E2E test suites only; use cli-command for CLI source implementation.
potpie-debug-memory
Use while debugging or troubleshooting failures, flaky tests, incidents, production alerts, CI failures, local dev setup issues, repeated bugs, prior fixes, failed attempts, and verification history.