Clowder AI is a self-hosted workspace where AI agents from different model families work together as a persistent team, retaining identities, shared evidence, and memory across tasks. It is for people who want to coordinate multiple AI agents without repeatedly rebuilding their context.
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 zts212653/clowder-ai --skill debugginggit clone --depth 1 https://github.com/zts212653/clowder-aiWrote 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/zts212653/clowder-ai/debugging)<a href="https://agentmods.dev/skills/zts212653/clowder-ai/debugging"><img src="https://agentmods.dev/badge/skills/zts212653/clowder-ai/debugging/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/zts212653/clowder-ai/debugging"><img src="https://agentmods.dev/badge/skills/zts212653/clowder-ai/debugging.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.00080 | $0.01593 |
| Opus 5.5 | $0.00032 | $0.00637 |
| Sonnet 5.5 | $0.00016 | $0.00319 |
| Haiku 4.5 | $0.00008 | $0.00159 |
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 1mo 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 — 91 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Debugging（系统性调试）
家里的真实教训是猜根因、反复补症状，以及无证据把问题归咎于 runtime 没更新。诊断要回答发生了什么、为什么、修复是否有效；方法与记录格式可以按现场选择。
必须做到
- 明确预期与实际差异，拿到复现、错误输出或其他能定位问题的观察证据；不能稳定复现时，说明已知条件和剩余缺口。
- 根因判断有能区分候选解释的证据。可以提出假设和小实验，但不能把猜测说成已查明，也不能只凭一次偶然成功宣称修复。
- 修复针对已查到的机制。按
tdd保留可信 RED → GREEN：已有精准失败检查可复用；缺少行为保护时补回归测试。相关回归检查与影响面匹配。 - 无法稳定自动化复现时，保留可复核的手工步骤、观察结果与限制；验证未完成就如实报告。
- 诊断、修复与验证信息留在可追溯的 issue、PR、thread 或 bug report。已有记录足够时不用再抄一份。
- 实例、权限和数据隔离仍服从家规；方法选择不改变实际运行边界。
下面的方法和模板是可选参考，可以直接使用、改造或替换。无需按模型资格决定能否换方法；自检看诊断与结果是否有依据，不检查模板是否填满。
Runtime 状态断言：先核实对象
声称“没更新 / 没编译 / 没重启 / 还是旧代码”时，必须有对应运行证据。怀疑验证对象、版本或配置错配时，先核对实际实例，再归因。
- 未合入改动的验证使用当前 feature worktree；已合入改动按 Alpha 通道验收。
3003/3004默认是 runtime，不能冒充开发实例。 - 仓库 HEAD、进程启动时间、日志行数各自只是线索，不能单独证明进程已加载目标构建。结合构建/版本标识、实例日志与目标行为确认。
- 纯函数失败、明确堆栈等已经提供有效诊断路径时，可以沿证据调查，不为填表先查无关 API PID。尚未做版本核验，不妨碍说明其他已经查实的现象。
来源：2026-04-05 runtime 状态误判教训；边界见 ../.cat-cafe-shared-refs/shared-rules.md §12、§16a。
可选参考：实例取证
需要排除错实例时，可从这些线索入手。端口与路径从实际启动配置取得，不套用默认值：
实例：目标 URL / API 端口 / worktree
进程：监听 PID 与启动时间
构建：实际加载的版本或构建标识，是否包含目标变更
行为：本次请求对应的日志、输出或复现结果
可用 lsof -nP -iTCP:<实际端口> -sTCP:LISTEN、ps -p <PID> -o lstart= 和目标仓库的 Git 信息协助核对；这些命令不代替构建与行为证据。
可选参考：四阶段调查
需要组织调查时，可以按下面的顺序起步，也可以根据新证据返回、合并步骤或换方法。
- 根因调查：读完整错误和堆栈、复现条件、最近改动；多组件问题从输入/输出边界追踪状态，找出最早偏离的位置。
- 模式对比：找同仓可工作的路径，读相关实现，比较与失败路径的关键差异。
- 假设实验：写下候选原因及依据，选择能区分解释的小实验，一次尽量只改变一个因素；结果不支持就更新假设。
- 修复验证：确认 RED 真实覆盖问题，实现修复，复验同一信号与受影响路径；出现新症状时回查机制。
相关历史可以用 search_evidence 查询；已知精确代码位置则直接 Read/Grep。搜索服务当前诊断，不是每次开工固定多轮。
反复失败时
多次修复没有新证据、同一状态对象反复暴露缺边，或修一处坏一处时，应停下检查当前假设、共享状态和契约。次数是警报，不是“架构有问题”的证明。
排除修复未加载、复现条件变化等解释后，若确实缺状态契约，回 writing-plans 补清生命周期与不变量；需要不同视角时找合适伙伴。价值取舍、权限或跨猫僵局才按决策漏斗交给 operator。
可选参考：诊断胶囊与报告
八栏诊断胶囊可帮助整理复杂调查。小问题可以只记“现象 → 证据 → 假设/根因 → 修复 → 验证”，也可以直接引用已有 PR/issue。
需要独立 bug report 时可放在 docs/bug-report/<bug-name>/bug-report.md，保留来源、复现、根因、修复和验证；无需先写工作表、再重复写一份报告。
常见误区
| 误区 | 正确做法 |
|---|---|
| 猜“旧 runtime”就建议重启 | 查真实实例与加载证据，重启仍走原授权边界 |
| 胶囊填满就认为根因已知 | 判断依据来自复现与区分实验 |
| 同时改多处后碰巧绿了 | 缩小变量，确认哪个机制解释了问题 |
| 已有精准 RED 仍另造同义测试 | 复用已有信号，补它未覆盖的行为风险 |
| 三次失败就断言需要重构 | 先检查竞争解释与状态契约，不用次数代替根因 |
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.
- 1mo ago Changed · -126 lines · +2 tokens per session 49bcb4b1fa35
- 1mo ago First seen · 217 lines · 78 tokens per session scan A 7291c4399259
debugging is a skill published in the GitHub repository zts212653/clowder-ai (3,471 stars, last pushed today), licensed MIT. It adds 80 tokens to every session and 1,593 once invoked, about $0.0003 per session on Opus 5.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
debug-optimize-lcp
Guides debugging and optimizing Largest Contentful Paint (LCP) using Chrome DevTools MCP tools. Use this skill whenever the user asks about LCP performance, slow page loads, Core Web Vitals optimization, or wants to understand why their page's main content takes too long to appear. Also use when the user mentions…
systematic-debugging
Use when debugging a failing test, build error, or runtime issue that isn't immediately obvious. Guides a 4-phase root cause analysis instead of random fix attempts.
log-error-digest
Analyze log files to troubleshoot errors, identify peak error periods, and produce error clustering, frequency statistics, and time distribution reports. Supports JSON, syslog, and Nginx formats with automatic detection. Use when a user uploads a .log file and asks to analyze errors, find patterns, debug issues, or…
deck-retro
Run a fully local agent-deck retrospective over the user's own transcripts, Recall index and logs. Use when a user wants to find recurring failures or take their own finding from investigation through synthetic reproduction, a user-filed issue, a test-first fix and contributor PR handoff. Also use for weekly usage…
incident-response-incident-response
Coordinate production incident triage, mitigation, investigation, recovery, and follow-up. Use when responding to outages or other incidents that require structured operational coordination.
cwv-optimizer
Diagnose and fix Core Web Vitals issues on AEM Edge Delivery Services pages. Goes deeper than generic CWV advice by understanding EDS-specific performance patterns including the 100KB LCP budget, E-L-D loading phases, block rendering behavior, and third-party script impact. Produces specific fixes for LCP, CLS, and…