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 devcxl/mattpocock-skills-zh --skill diagnosing-bugsgit clone --depth 1 https://github.com/devcxl/mattpocock-skills-zhWrote 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/devcxl/mattpocock-skills-zh/diagnosing-bugs)<a href="https://agentmods.dev/skills/devcxl/mattpocock-skills-zh/diagnosing-bugs"><img src="https://agentmods.dev/badge/skills/devcxl/mattpocock-skills-zh/diagnosing-bugs/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/devcxl/mattpocock-skills-zh/diagnosing-bugs"><img src="https://agentmods.dev/badge/skills/devcxl/mattpocock-skills-zh/diagnosing-bugs.svg" alt="Reviewed on agentmods" width="80" height="20"></a>- NVIDIA SkillSpector pass
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.00050 | $0.02431 |
| Opus 5 | $0.00025 | $0.01215 |
| Sonnet 5 | $0.00010 | $0.00486 |
| Haiku 4.5 | $0.00005 | $0.00243 |
Grade A, and why
diagnosing-bugs 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 12d 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.
Phase 1 完成的标志是循环**紧凑**且**能变红**：你能点出**一条命令**（脚本路径、一次测试调用、一条 curl），并**至少已经实际跑过一次**（给出调用与已脱敏的输出），并且它满足： How it starts
The opening of the file, as written. The whole thing — 139 lines — stays where its author put it; the contents beside it link to each section on GitHub.
诊断 Bug
针对棘手 bug 的一条纪律：只有显式说明正当理由时才能跳过某个阶段。
在探索代码库时，读取 CONTEXT.md（如果存在）以获得相关模块的清晰心智模型，并查看你所触及区域的 ADR。
脱敏
本技能会让你展示命令、输出和捕获的产物。先脱敏所有秘密：用 <REDACTED> 替换。针对环境变量构建循环，这样凭证留在环境中而不是出现在你展示的内容里。捕获的产物可能携带认证头：只引用携带信号的若干行。
如果脱敏后的输出不足以诊断 bug，要明确说明，并请用户提供更多材料。
Phase 1：构建反馈循环
这才是这个技能本身。 其它一切都只是机械动作。如果你对这个 bug 有一条紧密的通过/失败信号（一条会针对_这个_ bug 变红的信号），你就能找到根因；二分、假设检验、插桩都只是这条信号的消费者。如果你没有这条信号，盯着代码看到天荒地老也救不了你。
在这一步投入不成比例的精力。要激进。要有创意。绝不放弃。
构建反馈循环的若干方式（大致按此顺序）
- 失败测试：在能触及 bug 的任何 seam 上写——unit、integration、e2e。
- Curl / HTTP 脚本：针对正在运行的 dev server。
- CLI 调用：使用固定输入，把 stdout 与已知正常快照做 diff。
- 无头浏览器脚本（Playwright / Puppeteer）：驱动 UI 并断言 DOM/console/network。
- 重放已捕获的 trace。 把真实的网络请求 / payload / 事件日志落盘，单独通过代码路径重放。
- 一次性 harness。 拉起系统最小子集（一个服务、mock 掉依赖），用一次函数调用就能触发 bug 代码路径。
- 属性 / fuzz 循环。 如果 bug 是"有时输出不对"，跑 1000 个随机输入，观察失败模式。
- 二分 harness。 如果 bug 出现在两个已知状态（commit、数据集、版本）之间，自动化"以状态 X 启动、检查、重复"，便于
git bisect run。 - 差分循环。 把同一输入分别跑过老版本和新版本（或两种配置），对比输出。
- HITL bash 脚本。 最后的手段。如果必须由人来点击，就用
scripts/hitl-loop.template.sh来驱动_他们_，这样循环仍是结构化的。捕获到的输出再反馈给你。
把反馈循环做对了，bug 已经解决了 90%。
收紧循环
把循环当作产品。一旦你有了_一条_循环，就收紧它：
- 能不能让它更快？（缓存初始化、跳过无关 init、缩小测试范围。）
- 能不能让信号更尖锐？（针对具体症状做断言，而不是"没有崩溃"。）
- 能不能让它更确定？（固定时间、播种 RNG、隔离文件系统、冻结网络。）
30 秒的 flaky 循环只比没有循环强一点点；2 秒、确定性的循环才是真正紧凑的——是调试的超能力。
非确定性 bug
目标不是干净的复现，而是更高的复现率。把触发条件循环跑 100 轮，并行化、增加压力、收紧时窗、注入 sleep。一个 50% 复现率的 flaky bug 是可调试的；1% 不行，所以持续把复现率抬到可调试为止。
当你真的建不出循环时
停下来，并明确说出来。列出你尝试过的所有办法。请用户提供：(a) 能复现该 bug 的环境的访问权限，(b) 一份脱敏后的捕获产物（HAR 文件、日志 dump、core dump、带时间戳的录屏），或 (c) 允许你在生产环境加临时插桩的授权。不要在没有循环的情况下进入空谈理论。
完成判据：一条紧凑、能变红的循环
Phase 1 完成的标志是循环紧凑且能变红：你能点出一条命令（脚本路径、一次测试调用、一条 curl），并至少已经实际跑过一次（给出调用与已脱敏的输出），并且它满足：
- 能变红（Red-capable）：驱动真正的 bug 代码路径，并对用户描述的精确症状做断言——所以它能对这个 bug 变红，而修复后变绿。不是"不报错"；它必须能_抓住这个具体 bug_。
- 确定性：每次跑都得到同样的判定（flaky bug：按上文固定到高复现率）。
- 快速：秒级，不是分钟级。
- Agent 可跑：你可以在无人值守时跑；只有通过
scripts/hitl-loop.template.sh时才在环里放一个人。
What ships with it
2 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.
- 12d ago First seen · 139 lines · 50 tokens per session scan A b6002a15a56b
diagnosing-bugs is a skill published in the GitHub repository devcxl/mattpocock-skills-zh (343 stars, last pushed 7d ago), licensed MIT. It adds 50 tokens to every session and 2,431 once invoked, about $0.0003 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-08-30.
Other skills, from other repositories
systematic-debugging
A step-by-step method for finding the underlying cause of technical problems before changing code. It covers reading errors, reproducing failures, checking recent changes, and tracing data across system components.
dsh-debug-session
A troubleshooting guide for DSH startup failures, inactive plugins, and broken sessions. It describes collecting logs, narrowing down causes, backing up configuration, and rolling back changes.
fix-ci-until-green
Drive a failing GitHub Actions run to green in as few CI runs as possible, with a bounded fix-critique-commit-push-recheck loop that batches every evidenced fix into each push. Use when the user supplies a GitHub Actions run URL or run ID and wants the failure fixed, or asks to "make CI green", "fix the failing…
systematic-debugging
A step-by-step debugging guide for finding the real cause of software bugs before changing code.
pair-programming
AI-assisted pair programming with multiple modes (driver/navigator/switch), real-time verification, quality monitoring, and comprehensive testing. Supports TDD, debugging, refactoring, and learning sessions. Features automatic role switching, continuous code review, security scanning, and performance optimization with…
worker-benchmarks
Run comprehensive worker-system benchmarks and performance analysis. Use when benchmarking worker throughput/latency, comparing worker configurations, or diagnosing worker performance.