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/zts212653/clowder-ai/debuggingnpx skills add zts212653/clowder-ai --skill debugginggit clone --depth 1 https://github.com/zts212653/clowder-aiWhat 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.00078 | $0.02701 |
| Opus 5 | $0.00039 | $0.01350 |
| Sonnet 5 | $0.00016 | $0.00540 |
| Haiku 4.5 | $0.00008 | $0.00270 |
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 2d 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.
How it starts
The opening of the file, as written. The whole thing — 217 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Debugging（系统性调试）
随机尝试修复浪费时间，症状修复掩盖真正问题。
遇到 bug 先搜（F102 记忆系统）：search_evidence("{error关键词}") 看看历史上有没有类似的坑。
铁律：没有根因分析，不能提出修复方案。
核心知识
Runtime Preflight Gate（运行时异常硬门禁）
如果 bug 涉及 runtime 行为（前端显示异常、API 返回错误、猫猫行为异常、stream 错误等），在进入 Phase 1 之前必须先完成三件套验证：
手动三件套（按顺序执行，收集 7 个字段）：
# 1. 找到 API 监听进程（绑端口，不用 grep 猜）
export API_PORT="${API_SERVER_PORT:-3004}"
lsof -iTCP:"$API_PORT" -sTCP:LISTEN -P -n 2>/dev/null | awk 'NR>1{print "PORT="ENVIRON["API_PORT"], "PID="$2}'
# 2. 进程启动时间
ps -p <PID> -o lstart=
# 3. Runtime worktree HEAD vs 目标 commit
git -C <runtime-worktree> log --oneline -1 # HEAD=
TARGET_COMMIT=<你预期的commit>
# 判断进程是否在 commit 之后启动：比较 commit 时间 vs 进程启动时间
# 4. 当前 PID 在最新日志中的行数
grep -c "<PID>" <最新日志文件路径> # LOG_EVIDENCE=
收集到的 7 个字段：
PORT=3004 ← 默认 API 端口（3003=前端），只取 LISTEN PID
PID=53507 ← 精确到监听进程（排除浏览器等客户端连接）
START_TIME=... ← 进程启动时间
HEAD=abc1234 ... ← runtime worktree HEAD
TARGET_COMMIT=f78c984 ← 你预期的 commit
PROCESS_AFTER_TARGET=yes/no ← 进程是否在 commit 之后启动
LOG_EVIDENCE=... ← 当前 PID 在最新日志中的行数
这 7 行没拿到之前，唯一允许说的话是"我还没查完"。
以下断言必须附带 preflight 输出，否则禁止说出：
- "runtime 没更新" / "代码没编译" / "没重启" / "还是旧代码"
为什么这是硬门禁：启动脚本会自动拉代码并编译。"没更新"本来就不太可能发生。在没有证据的情况下说"没更新" = 把自己的 bug 甩锅给operator。这不是懒，是推卸责任。
来源：operator多次纠正（2026-04-05 定为 P0），Maine Coon协助定位根因 + 方案审查。
4 阶段流水线
每个阶段必须完成才能进入下一个。
Phase 1 — 根因调查（提出任何修复前必须完成）
- 仔细读错误信息：不要略过 stack trace，记录行号/文件路径/错误码
- 稳定复现：能稳定触发吗？不能复现 → 收集更多数据，不要猜
- 检查最近变更：git diff、新依赖、配置变更、环境差异
- 多组件系统：加诊断桩收集证据
对每个组件边界：记录进入的数据、记录输出的数据、验证状态传播 先跑一次收集"哪里断了"的证据，再分析，再深入那个组件 - 数据流逆向追踪：错误值从哪里来？谁传了这个错误值？一直往上追到源头，在源头修，不在症状处修（完整技术见
root-cause-tracing.md）
Phase 2 — 模式分析
- 在同一代码库找可以工作的类似代码
- 对照参考实现完整地读（不要略读）
- 逐项列出工作代码和问题代码的差异，不要假设"这个不重要"
Phase 3 — 假设验证
- 明确写下："我认为根因是 X，因为 Y"
- 做最小可能的变更验证假设（一次一个变量）
- 通过了 → Phase 4；没过 → 提出新假设，不要在上面叠加更多修复
Phase 4 — 实现修复
- 先写失败测试复现 bug（参见
tddskill） - 实现针对根因的单一修复
- 验证测试通过、无回归
- 如果修复无效 → 回 Phase 1，带着新信息重新分析
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.
- 2d ago First seen · 217 lines · 78 tokens per session scan A 7291c4399259
debugging is a skill published in the GitHub repository zts212653/clowder-ai (2,854 stars, last pushed yesterday), licensed MIT. It adds 78 tokens to every session and 2,701 once invoked, about $0.0004 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-30.
Other skills, from other repositories
systematic-debugging
Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes.
brainstorming
You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation.
chat-pet-sprite-creation
Use when creating or changing VS Code chat pet sprite art, sprite sheets, state animations, eye treatments, Stable/Insiders variants, or pet transitions under src/vs/workbench/contrib/chat/browser/widget/media/chatPet.
cpu-profile-analysis
Analyze V8/Chrome CPU profiles (.cpuprofile) and DevTools trace files (Trace-.json). Use when: profiling performance, investigating slow functions, comparing code paths, finding bottlenecks, analyzing timeToRequest, understanding call trees from sampling profiler data, analyzing layout/paint/rendering, investigating…
agent-host-chat-contributions
Build and review cross-cutting agent-host chat behavior through lifecycle contributions. Use when adding turn lifecycle side effects, prompt or context injection, restored-history transformation, protocol-action observation, or when reviewing changes that add code to AgentSideEffects or AgentService.
auto-perf-optimize
Run agent-driven VS Code performance or memory investigations. Use when asked to launch Code OSS, automate a VS Code scenario, run the Chat memory smoke runner, capture renderer heap snapshots, take workflow screenshots, compare run summaries, or drive a repeatable scenario before heap-snapshot analysis.