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/tslateman/duet/debuggingnpx skills add tslateman/duet --skill debugginggit clone --depth 1 https://github.com/tslateman/duetWhat 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.00048 | $0.01359 |
| Opus 5 | $0.00024 | $0.00679 |
| Sonnet 5 | $0.00010 | $0.00272 |
| Haiku 4.5 | $0.00005 | $0.00136 |
Grade A, and why
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 yesterday.
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 — 142 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Systematic Debugging
Overview
Apply the scientific method to software failures. Observe before theorizing. Form hypotheses, design experiments, narrow the cause. Refuse to jump to fixes until the cause is isolated.
The Scientific Debugging Loop
- Observe, What exactly happens? What did you expect?
- Hypothesize, What could cause this specific discrepancy?
- Predict, If the hypothesis is true, what else must be true?
- Test, Design the smallest experiment that confirms or refutes
- Conclude, Update understanding, repeat from step 2 if refuted
Never skip from Observe to Fix. The loop exists because human intuition about bug causes is wrong more often than right.
Build the Loop First
For a hard bug, this is the skill, everything else is mechanical. Before you hypothesize, build a tight, red-capable feedback loop: one command that drives the actual bug path and goes red on this bug, green once fixed. With it, bisection, hypothesis-testing, and instrumentation all just consume it. Without it, no amount of staring at code will save you. Spend disproportionate effort here, be aggressive, be creative, refuse to give up. See references/feedback-loops.md for the ten ways to construct one, how to tighten it, and what to do with non-deterministic bugs.
Completion criterion, a loop that goes red. Do not proceed to hypotheses until you can name one command you have already run at least once (paste the invocation and its output) that is:
- Red-capable, drives the real bug path and asserts the user's exact symptom; not "runs without erroring"
- Deterministic, same verdict every run (flaky bugs: a pinned, high reproduction rate)
- Fast, seconds, not minutes
- Agent-runnable, runs unattended
If you catch yourself reading code to build a theory before this command exists, stop, jumping straight to a hypothesis is the exact failure this guards against. Then minimise: shrink the repro to the smallest scenario that still goes red, cutting one element at a time, so Phase 3's hypothesis space is small and the result becomes a clean regression test.
What ships with it
3 files beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
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.
- yesterday First seen · 142 lines · 48 tokens per session scan A ee3f167962d0
debugging is a skill published in the GitHub repository tslateman/duet (1 stars, last pushed 4d ago), licensed MIT. It adds 48 tokens to every session and 1,359 once invoked, about $0.0002 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
html-ppt-hermes-cyber-terminal
OpenDesign + BYOK: choosing and wiring your own model, hands-on — cost, quality, and the routing decision. Built as a decision-grade AI literacy deck for engineers, IT, applied-AI teams.
verify-security
安全校验关卡。自动扫描代码安全漏洞，检测危险模式，确保安全决策有文档记录。当用户提到安全扫描、漏洞检测、安全审计、代码安全、OWASP、注入检测、敏感信息泄露时使用。在新建模块、安全相关变更、攻防任务、重构完成时自动触发。.
development
开发语言能力索引。Python、Go、Rust、TypeScript、Java、C++、Shell。当用户提到编程、开发、代码、语言时路由到此。.
post-build-flow
Handles workflow verification and setup after build-workflow succeeds, or when the message contains workflow-verification-follow-up or workflow-setup-required. Load after direct builds, when verificationReadiness requires action, or on orchestrator verify/setup follow-up turns.
n8n:human-like-code-review
Reviews a GitHub pull request like a thoughtful human reviewer and writes the feedback to a markdown file. Prioritizes context, architecture fit, solution complexity, bugs, security edge cases, and missing tests. Use when given a PR URL to review, or when the user says /human-like-code-review.
n8n:create-pr
Creates GitHub pull requests with properly formatted titles that pass the check-pr-title CI validation. Use when creating PRs, submitting changes for review, or when the user says /pr or asks to create a pull request.