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 gongyijie85/mattpocock-skills-dsh-zh --skill diagnosing-bugs-zhgit clone --depth 1 https://github.com/gongyijie85/mattpocock-skills-dsh-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/gongyijie85/mattpocock-skills-dsh-zh/diagnosing-bugs-zh)<a href="https://agentmods.dev/skills/gongyijie85/mattpocock-skills-dsh-zh/diagnosing-bugs-zh"><img src="https://agentmods.dev/badge/skills/gongyijie85/mattpocock-skills-dsh-zh/diagnosing-bugs-zh/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/gongyijie85/mattpocock-skills-dsh-zh/diagnosing-bugs-zh"><img src="https://agentmods.dev/badge/skills/gongyijie85/mattpocock-skills-dsh-zh/diagnosing-bugs-zh.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.00048 | $0.02517 |
| Opus 5 | $0.00024 | $0.01259 |
| Sonnet 5 | $0.00010 | $0.00503 |
| Haiku 4.5 | $0.00005 | $0.00252 |
Grade A, and why
diagnosing-bugs-zh 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 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.
Makes network callslowCapability
Not a fault in itself. Listed so you know the mod talks to something, and to what.
当回路**紧致**且**能变红(red-capable)**时,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.
Diagnosing Bugs
针对棘手 bug 的纪律。只有在明确有理有据时才跳过某些 phase。
探索 codebase 时,阅读 CONTEXT.md(如果存在)以获得相关模块清晰的 mental model(心智模型),并检查你正在接触区域的 ADR。
Redact(脱敏)
本 skill 要求你展示命令、输出和捕获的产物。先对每个 secret 脱敏 — 用 <REDACTED> 代替。针对 env vars 构建回路,这样凭据留在环境中,而不是留在你展示的内容里。捕获的产物带有 auth headers:只引用携带信号的几行。
如果脱敏后的输出不足以诊断 bug,直说并询问用户。
Phase 1 — 构建反馈回路
这才是本 skill 的核心。 其他一切都是机械性的。如果你有一个针对该 bug 的紧致通过/失败信号 — 一个能在_这个_ bug 上变红的信号 — 你就会找到原因;bisection(二分)、假设检验和 instrumentation 都只是在消费它。如果你没有这样的信号,再怎么盯着代码看也救不了你。
在这里投入不成比例的努力。要激进。要有创造力。拒绝放弃。
构建反馈回路的方法 — 大致按这个顺序尝试
- 失败的测试 — 在任何能触达 bug 的 seam 上 — unit、integration、e2e。
- Curl / HTTP 脚本 — 针对运行中的 dev server。
- CLI 调用 — 用 fixture 输入,把 stdout 与已知良好的快照做 diff。
- 无头浏览器脚本(Playwright / Puppeteer)— 驱动 UI,在 DOM/console/network 上做断言。
- 重放捕获的 trace。 把真实的网络请求 / payload / 事件日志保存到磁盘;在隔离环境中通过代码路径重放它。
- 一次性 harness。 启动系统的一个最小子集(一个 service,依赖用 mock),用一次函数调用触发 bug 代码路径。
- Property / fuzz 回路。 如果 bug 是 "sometimes wrong output(偶尔输出错误)",运行 1000 个随机输入,寻找失败模式。
- Bisection harness。 如果 bug 出现在两个已知状态(commit、数据集、版本)之间,把 "boot at state X, check, repeat(在状态 X 启动、检查、重复)" 自动化,这样你就可以对它
git bisect run。 - 差分回路(Differential loop)。 让同一输入分别通过旧版本和新版本(或两种配置),对输出做 diff。
- HITL bash 脚本。 最后的手段。如果必须由人来点击,用
scripts/hitl-loop.template.sh驱动_他们_,这样回路仍然是有结构的。捕获的输出反馈给你。
构建出正确的反馈回路,bug 就修好了 90%。
收紧回路
把回路当作产品来对待。一旦你有了_一条_回路,就收紧它:
- 我能让它更快吗?(缓存 setup、跳过无关的初始化、缩小测试范围。)
- 我能让信号更锐利吗?(对具体症状做断言,而不是 "didn't crash(没崩溃)"。)
- 我能让它更确定吗?(固定时间、给 RNG 播种、隔离文件系统、冻结网络。)
一个 30 秒的 flaky 回路和没有回路相比几乎毫无优势;一个 2 秒的确定性回路才是紧致的 — 那是调试的超能力。
非确定性 bug
目标不是干净的 repro(复现),而是更高的复现率。把触发器循环 100 次、并行化、加压、收窄时间窗口、注入 sleep。50% 概率 flake 的 bug 是可调试的;1% 的不是 — 不断提高复现率,直到它可调试。
当你确实无法构建回路时
停下来,明确说明。列出你尝试过的东西。向用户请求:(a) 访问能复现它的环境,(b) 一份脱敏的捕获产物(HAR 文件、日志转储、core dump、带时间戳的屏幕录制),或 (c) 添加临时生产 instrumentation 的许可。不要在没有回路的情况下继续假设。
完成标准 — 一条能变红的紧致回路
当回路紧致且能变红(red-capable)时,Phase 1 就完成了:你能说出一条命令 — 一个脚本路径、一次测试调用、一条 curl — 而且你已经至少运行过一次(展示这条调用及其输出,已脱敏),并且它:
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 · 139 lines · 48 tokens per session scan A 463f152a0273
diagnosing-bugs-zh is a skill published in the GitHub repository gongyijie85/mattpocock-skills-dsh-zh (5 stars, last pushed yesterday), licensed MIT. It adds 48 tokens to every session and 2,517 once invoked, about $0.0002 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-11.
Other skills, from other repositories
dsh-troubleshoot
A troubleshooting guide for DeepSeek Harness, including its process, configuration, plugins, tools, skills, and model connections.
error-handling
A set of rules for deciding how software should report failures and what information error messages should contain.
ask-good-questions
Guidance for asking technical questions and reporting bugs so another developer can reproduce and answer them. It covers versions, environment details, minimal reproduction steps, expected and actual results, errors, and attempted fixes.
debug-systematically
A structured method for finding the underlying cause of a software problem. It moves from reproducing the problem, to locating the responsible code, to testing a specific explanation, and then to fixing it with a regression test.
perf-optimize
A performance-improvement guide that requires measuring real behaviour before changing code. It explains how to identify bottlenecks, test one change at a time, and check that the change did not break anything.
dsh-hooks-authoring
Instructions for writing and debugging dsh-hooks-plugin scripts, which run during tool or session events such as before a tool call or after it finishes. These scripts return JSON decisions such as allowing, asking about, or denying an action.