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/lion-1209/coderio/debuggingnpx skills add Lion-1209/coderio --skill debugginggit clone --depth 1 https://github.com/Lion-1209/coderioWhat 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.00024 | $0.02597 |
| Opus 5 | $0.00012 | $0.01299 |
| Sonnet 5 | $0.00005 | $0.00519 |
| Haiku 4.5 | $0.00002 | $0.00260 |
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.
Copies of this mod
1 near-identical copy found in the catalogue:
- debugging — 100% identical, 0 lines differ
How it starts
The opening of the file, as written. The whole thing — 117 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Debugging
概述
用科学方法定位 bug 的根因，而不是凭直觉乱改碰运气。核心：调试是观察 → 假设 → 设计实验验证 → 缩小范围 → 定位根因的循环，每一步都有依据。改到"不报错"不算修好——那可能只是把症状盖住了，根因还在。
何时使用
- 遇到报错/崩溃/行为异常，要定位原因
- bug 不稳定复现，不知触发条件
- 调试卡住、改了好几处都不行
- 看了代码"没发现问题"，但程序确实有问题
不该用：行为符合预期的"不是 bug"（先确认是不是 bug，别把功能当 bug 调）；环境/部署问题（先排查是不是代码外原因）。
与相邻 skill 的边界：debugging 管定位根因（调查：复现、假设、二分、读堆栈），verify-and-fix 管修复与验证（改对：修病因不症状、防回归）。两者接力——debugging 找出"问题是什么、在哪"，verify-and-fix 接手"怎么改对、怎么确认修好"。debugging 的终点（定位的根因）就是 verify-and-fix 的起点。
当 bug 报告太模糊时（"页面打不开""功能不工作"却没给报错/复现步骤），先回到 clarifying-questions 的思路——要可观察的现象（报错信息、触发操作、环境、是所有情况还是特定情况）再分析。没有现象的调试就是盲猜。
核心内容
第一原则：先看报错，别跳过它直接猜
报错信息（异常类型、消息、堆栈、行号）往往直接包含根因线索，是调试最便宜的情报。最常见、最浪费的错法是不看报错就凭直觉改——明明堆栈第 3 行写着 Cannot read 'id' of undefined at line 42，却跳过它去猜"是不是网络问题""是不是缓存"。
读报错的顺序：
- 异常类型 + 消息：发生了什么（TypeError？NullPointer？超时？）
- 第一个你自己代码的堆栈帧：在哪发生的（行号 + 函数）——注意是"你的代码"，不是框架/库内部的帧
- 触发上下文：什么操作/数据触发的
读堆栈的技巧：堆栈常被框架/异步包装得很难读，几个技巧帮你找到真正的根因帧：
- 跳过框架帧：堆栈顶部往往是一堆框架内部代码（React 调度、Express 中间件、ORM 反射），真正的根因在第一个属于你项目源码的帧——往下翻找到你认识的文件名/行号。
- 异步代码的堆栈可能不连续：
async/await、Promise、回调、事件循环的堆栈经常断开（一个错误在 setTimeout 里抛，堆栈却看不到触发它的代码）。现代运行时有--async-stack-traces或类似的异步堆栈支持，开启它；否则要在触发处手动打日志补全调用链。 - 错误被转发后原始堆栈会丢：如果错误被 catch 又重新抛（尤其改了消息或包了新异常），原始堆栈可能藏在
error.cause或originalError里——别只看最外层，挖嵌套的 cause 链。
养成习惯：遇到 bug，第一件事是完整读一遍报错，而不是打开编辑器开始改。读不懂报错时，先查懂它（搜异常类型、读文档），别跳过。
先复现，再调试
不能稳定复现的 bug 几乎无法调试——你改了不知道有没有效，因为"不报错"可能是修好了，也可能是这次没触发。调试前先建立可复现：
- 找到触发 bug 的最小条件：什么输入、什么操作顺序、什么状态组合下必现？
- 最小化：剥离无关因素，直到只剩"做 X 就必崩"。最小复现让你能反复试验、验证修复。
不稳定复现的 bug（偶发）尤其要先攻克复现——它通常意味着有隐含条件没找到（并发时序、特定数据、资源竞争、时间相关）。找这个条件本身就是定位根因的关键。
反例：bug 偶发，你直接多加几个 try/catch 把可能出错的地方包起来"这样就不崩了"——错误被吞了看不见，但触发条件和根因一行没动，换个场景又炸，而且现在连报错都没了，更难查。
科学方法：假设 → 实验 → 验证
定位根因靠假设驱动，不是碰运气：
- 观察：报错是什么、何时发生、复现条件。
- 假设："我猜根因是 X"——基于观察和代码理解提出具体、可证伪的假设（不是"大概是哪里有问题"）。
- 设计实验：如果是 X 导致的，那应该观察到 Y（可验证的预测）。
- 验证：跑实验，看 Y 是否成立。成立 → 假设支持，继续深入；不成立 → 排除这个假设，换下一个。
- 缩小范围：每次实验排除一部分可能性，把根因锁定在更小的范围。
What ships with it
1 file 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 · 117 lines · 24 tokens per session scan A 90bbc8ef8746
debugging is a skill published in the GitHub repository Lion-1209/coderio (9 stars, last pushed 4d ago), licensed MIT. It adds 24 tokens to every session and 2,597 once invoked, about $0.0001 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
blog-writer
Peri 项目博客写作风格指南。当用户说"写博客"、"写文章"、"出稿"、 "按风格写"、"博客"时触发。也适用于用户丢过来素材说"帮我写篇博客"的场景。 覆盖项目介绍、技术复盘、架构讨论、性能优化、架构设计等类型。.
auto-devflow
Use when starting an issue, bugfix, feature, or refactor that benefits from an adaptive development workflow. Select lite, normal, pro, max, or ultra from task complexity and risk, then use only the coordination, review, and verification phases that the task actually needs.
langfuse
Interact with Langfuse and access its documentation. Use when needing to (1) query or modify Langfuse data programmatically via the CLI — traces, prompts, datasets, scores, sessions, and any other API resource, (2) look up Langfuse documentation, concepts, integration guides, or SDK usage, or (3) understand how any…
self-build
Builds isolated npm capability packages that operate on real project code and connects them to Peri through MCP/MCPP and MetaHarness. Use when adding tools, resources, remote skills or agents, creating a Bun/Node.js stdio server, linking .mcp.json, or changing the active prompt and middleware set.
project-maturity
对任意项目进行全面的成熟度评估扫描。当用户说"检查项目成熟度"、"项目评估"、 "maturity assessment"、"代码质量扫描"、"项目健康度"、"项目体检"、 "scan project maturity"、"项目有多成熟"时触发。适用场景：接手新项目前的摸底、 发布前的质量审查、技术尽调、团队内部代码健康度盘点。.
auto-issue-fixer
Issue 全生命周期管理——从创建到归档。当用户描述技术问题、提 bug、"帮我记录"、 "修一下 X issue"、"验证一下"、"归档 issue"时立即触发。单入口自动分发， 替代旧 issue-create/fix-issue/issue-verify/issue-archive 四个技能。 即使用户没有用"issue"这个词，只要在描述值得追踪的技术问题就应触发。.