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 floomhq/moto --skill debuggit clone --depth 1 https://github.com/floomhq/motoWrote 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/floomhq/moto/debug)<a href="https://agentmods.dev/skills/floomhq/moto/debug"><img src="https://agentmods.dev/badge/skills/floomhq/moto/debug/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/floomhq/moto/debug"><img src="https://agentmods.dev/badge/skills/floomhq/moto/debug.svg" alt="Reviewed on agentmods" width="80" 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.00066 | $0.00819 |
| Opus 5.5 | $0.00026 | $0.00328 |
| Sonnet 5.5 | $0.00013 | $0.00164 |
| Haiku 4.5 | $0.00007 | $0.00082 |
Grade A, and why
debug 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 1mo 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 — 111 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Debug Skill
Principle: Root Cause, Not Quick Fix
The goal is to find WHY something is broken, not to patch the symptom. A quick fix that doesn't address the root cause will resurface.
Step 1: Understand the failure
Collect the full picture:
- What is the exact error message? (copy verbatim, don't paraphrase)
- What was the expected behavior?
- What is the actual behavior?
- When did it start failing? (after which change?)
- Does it fail consistently or intermittently?
- What environment? (local / staging / prod, OS, Node/Python version)
Step 2: Read the error carefully
Before touching any code:
- Read the FULL stack trace, not just the first line
- Note the file and line number where it originated
- Note any "caused by" or nested exceptions
- Check if there are warning messages before the error
Step 3: Form a hypothesis
Based on the error, form a hypothesis about what's wrong. Common categories:
- Data issue: null/undefined where not expected, wrong type, out of range
- Logic issue: wrong condition, off-by-one, state mutation
- Dependency issue: wrong version, missing module, API change
- Environment issue: missing env var, wrong config, permission denied
- Timing issue: race condition, async/await missing, order of operations
- Network issue: timeout, DNS, CORS, SSL
Step 4: Verify the hypothesis
Verify, don't assume. For each hypothesis:
# Add targeted logging to confirm
console.log('DEBUG:', variableName, typeof variableName);
# Check values at the point of failure
# Read the actual code at the error location
# Check the data flowing in
Step 5: Find the root cause
Trace backwards from the failure:
- Where does the error originate?
- What called that code?
- What data was passed?
- Where was that data set?
- Is the data wrong, or is the code wrong?
Use git log and git blame to understand when and why code was written a certain way.
Step 6: Fix and verify
Once root cause is confirmed:
- Make the minimal fix
- Verify the original error is gone
- Check no new errors were introduced
- Add a test to prevent regression
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.
- 1mo ago First seen · 111 lines · 66 tokens per session scan A 710eaa2d9444
debug is a skill published in the GitHub repository floomhq/moto (32 stars, last pushed 4mo ago), licensed MIT. It adds 66 tokens to every session and 819 once invoked, about $0.0003 per session on Opus 5.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-30.
Other skills, from other repositories
eval-hooks
Audit Claude Code and Codex hooks for validity, safety, and correctness across settings.json, hooks.json, config.toml, plugin, and skill or agent frontmatter hooks. Resolves each command, checks event names, handler types, matchers, exit-code and JSON decision strategy, and timeouts against each host's documented…
check-cache-bugs
Audit Claude Code setup for cache bugs (CC#40524): sentinel, --resume/--continue, attribution header + ArkNill B3/B4/B5.
sandbox-unblock
Diagnostic protocol to run before reporting a sandbox blocker or asking for a configuration change. Eleven checks that eliminate false positives, then a report template the person holding the settings can act on. On one measured day, six of eight reported blockers turned out to be false, all from the same handful of…
investigate
Systematic root-cause debugging: find the cause before writing any fix.
qa
Systematic QA testing of a web application: diff-aware, tiered, with fix-and-verify loop.
optimize
Analyze and suggest performance improvements for code, queries, or systems.