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/yinqd3/workbuddy-skills/systematic-debuggingnpx skills add yinqd3/workbuddy-skills --skill systematic-debugginggit clone --depth 1 https://github.com/yinqd3/workbuddy-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/yinqd3/workbuddy-skills/systematic-debugging)<a href="https://agentmods.dev/skills/yinqd3/workbuddy-skills/systematic-debugging"><img src="https://agentmods.dev/badge/skills/yinqd3/workbuddy-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.00064 | $0.00877 |
| Opus 5 | $0.00032 | $0.00439 |
| Sonnet 5 | $0.00013 | $0.00175 |
| Haiku 4.5 | $0.00006 | $0.00088 |
Grade A, and why
systematic-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 5d 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.
What it actually says
系统化调试
核心原则
总是先找到根因再尝试修复。 症状修复 = 失败。随机修复浪费时间并制造新 bug。
铁律
没有根因调查 = 没有修复
没完成阶段 1，不能提修复方案。
何时使用
任何技术问题：
- 测试失败
- 生产 Bug
- 意外行为
- 性能问题
- 构建失败
- 集成问题
尤其在以下情况必须使用：
- 时间紧迫时（紧急情况最容易想猜）
- "就改一下"看起来很明显
- 已经试过多次修复
- 上次修复没起作用
- 你不完全理解这个问题
四阶段调试法
必须完成每个阶段再进入下个阶段。
阶段 1：根因调查
在尝试任何修复之前：
-
仔细读错误信息
- 不要跳过错误或警告
- 完整读堆栈跟踪
- 注意行号、文件路径、错误码
-
稳定复现
- 能可靠触发吗？
- 精确步骤是什么？
- 每次都发生吗？
- 如果不能复现 → 收集更多数据，不要猜
-
检查最近的变更
- 什么改变可能导致这个？
git diff、最近的提交- 新依赖、配置变更
- 环境差异
-
多组件系统的证据收集
在每个组件边界: - 记录什么数据进入 - 记录什么数据出来 - 验证配置/环境传播 跑一次看哪里断了，然后再深入那层 -
追踪数据流
- 错误值的起源在哪里？
- 谁用错误值调用了这个？
- 向上追踪调用栈直到找到源头
- 在源头修复，不在症状处修复
阶段 2：模式分析
找到模式再修复：
- 在代码库中找类似的工作示例
- 完整对照参考——不要略读
- 列出工作与失败之间的每个差异
- 理解所有依赖和假设
阶段 3：假设+检验
- 形成一个清晰的假设："我认为 X 是根因，因为 Y"
- 明确写下来
- 设计最小测试来证明/否定它
- 跑测试
- 如果被否定 → 形成新假设，重复
- 如果被证明 → 进入修复
阶段 4：修复+验证
- 在根因处修复，不在症状处
- 写一个能捕获这个 bug 的测试
- 验证修复有效
- 验证无回归（全量测试套件）
- 清晰提交信息，解释根因
反模式
- "试试这个" — 没有根因的随机修复
- "大概是 X" — 没有证据的猜测
- "快速补丁" — 症状修复，根因还在
- 一次改多个东西 — 无法知道哪个起效
- 跳过复现 — 调试一个不能稳定触发的问题
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.
- 5d ago First seen · 110 lines · 64 tokens per session scan A f104819d820f
systematic-debugging is a skill published in the GitHub repository yinqd3/workbuddy-skills (6 stars, last pushed 3mo ago), licensed MIT. It adds 64 tokens to every session and 877 once invoked, about $0.0003 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
results-report
This skill should be used when the user asks to "write an experiment report", "summarize experimental results", "do experiment retrospection", "write a results report", "写实验总结报告", "写实验复盘", or mentions turning completed experiment artifacts into a structured, decision-oriented research report. It assumes strict…
research-brainstorm-from-kb
Explores and structures research ideas into obsidian-vault/ideas/ notes using the local paper knowledge base and frontier techniques. Use when the user provides research questions or ideas and wants decomposed candidate directions, related-work analysis based primarily on obsidian-vault/analysis, and cross-domain…
domain-fork
Migrates BITE's architecture to a new professional domain (e.g. frontend development, accounting, journalism). Interactive session with the user to map research concepts to domain equivalents, then generates a complete set of adapted skills and folder structure. Explicit trigger only.
papers-batch-analyze
Batch-analyzes papers from a user-provided CSV or obsidian-vault/paperlist.csv by splitting the list into safe per-batch CSVs, spawning parallel worker agents, writing analysis notes under obsidian-vault/analysis/, and refreshing obsidian-vault/index/ after all completed batches. Use when the user asks to analyze many…
papers-collect-from-github-repo
Collects paper candidates from any GitHub repository README or docs — awesome lists, survey companion repos, lab paper lists, conference accepted-paper repos, benchmark leaderboards, etc. Agent fetches the README (or specified doc), analyzes its format, writes a one-off parser, and outputs rows aligned with…
code-context-paper-retrieval
Retrieves code-context-relevant papers from the local knowledge base in two modes (brief/deep), using obsidian-vault/analysis/ as the primary retrieval source and obsidian-vault/paperPDFs/ for optional deeper reading. obsidian-vault/index/ is optional and mainly serves statistics, Obsidian navigation, and backlink…