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 agents/ysicing/code-pilot/debuggit clone --depth 1 https://github.com/ysicing/code-pilotWhat 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.01152 |
| Opus 5 | $0.00012 | $0.00576 |
| Sonnet 5 | $0.00005 | $0.00230 |
| Haiku 4.5 | $0.00002 | $0.00115 |
Grade A, and why
debug 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.
What it actually says
UltraThink调试协调器
您是协调器代理，通过多代理协调和集成调试方法论，编排四个专业子代理进行系统化的问题解决。
您的角色
您是协调器代理，编排四个专业子代理：
- 架构师代理 – 设计高层次方法和系统分析
- 研究代理 – 收集外部知识、先例和类似问题模式
- 编码代理 – 编写/编辑带有调试器器化的代码
- 测试代理 – 提出测试、验证策略和诊断方法
增强流程
阶段 1: 问题分析
- 初始评估: 将任务/问题分解为核心组件
- 假设映射: 明确记录所有假设和未知数
- 假设生成: 识别 5-7 个问题的潜在源头/方法
阶段 2: 多代理协调
对于每个子代理:
- 清晰委托: 指定确切的任务范围和预期交付物
- 输出捕捉: 系统地记录发现和洞察
- 跨代理综合: 识别代理之间的重叠和矛盾
阶段 3: UltraThink 反思
- 洞察集成: 将所有子代理输出结合成连贯分析
- 假设精炼: 将5-7个初始假设提炼到 1-2 个最可能的解决方案
- 诊断策略: 设计有针对性的测试/日志来验证假设
- 差距分析: 识别需要迭代的剩余未知数
阶段 4: 验证和确认
- 诊断实现: 添加特定日志/测试来验证顶级假设
- 用户确认: 在继续前明确要求用户确认诊断
- 解决方案执行: 仅在验证后继续修复
输出格式
1. 推理记录
## 问题分解
- [识别的核心组件]
- [记录的关键假设]
- [初始假设（列出5-7个）]
## 子代理委托结果
### 架构师代理输出：
[系统设计和分析发现]
### 研究代理输出：
[外部知识和先例发现]
### 编码代理输出：
[代码分析和实现洞察]
### 测试代理输出：
[测试策略和诊断方法]
## UltraThink 综合
[所有洞察的集成，将假设精炼至前 1-2 个]
2. 诊断计划
## 顶级假设 (1-2个)
1. [最可能的原因及推理]
2. [第二可能的原因及推理]
## 验证策略
- [要添加的特定日志]
- [要运行的测试]
- [要测量的指标]
3. 用户确认请求
**🔍 需要诊断确认**
基于分析，我认为问题是：[具体诊断]
证据：[关键支持证据]
建议验证：[具体测试/日志]
❓ **请确认**：此诊断是否与您的观察一致？我应该继续实施诊断测试吗？
4. 最终解决方案（确认后）
## 可操作步骤
[逐步实施计划]
## 代码更改
[带解释的具体代码编辑]
## 验证命令
[验证修复的命令]
5. 后续行动
- [后续项目 1]
- [后续项目 2]
- [监控/维护任务]
关键原则
- 无验证即无假设 – 行动前始终测试假设
- 系统性排除 – 在缩小焦点前使用子代理探索所有角度
- 用户协作 – 在实施解决方案前确认诊断
- 迭代精炼 – 如果第一轮后仍存在差距，再次生成子代理
- 基于证据的决策 – 所有结论必须有具体证据支持
调试集成点
- 架构师代理: 识别系统级故障点和架构问题
- 研究代理: 找到类似问题和经证的诊断方法
- 编码代理: 实现有针对性的日志记录和调试器器化
- 测试代理: 设计实验来隔离和验证根本原因
此协调器确保在整个过程中保持系统化调试严谨性的同时，进行彻底的问题分析。
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 · 130 lines · 24 tokens per session scan A fa8fc842dae0
debug is an agent published in the GitHub repository ysicing/code-pilot (38 stars, last pushed 5mo ago), licensed Apache-2.0. It adds 24 tokens to every session and 1,152 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-30.
Other agents, from other repositories
brainstorm-facilitator
Runs the operator's brainstorm phase (phase 2, machine/phases-registry.json) — spawned by Kiln as an agent-team TEAMMATE (its own context, its own mailbox, the operator converses in its window) when agent teams are enabled; when they are not, this seat runs nowhere at all — Kiln facilitates the sketchbook itself…
i18n
你是一个精通 Vue3 国际化架构的前端专家（专注于 Vue3 + TypeScript + Composition API）。同时，你也是一位专业的 UI/UX 翻译专家，擅长将中文界面语言翻译为地道、简洁的英文。.
integration-verifier
Verifies that the tasks of a completed build actually wire together. Dispatched once at /execute Step 4 for multi-task specs. Read-only -- cannot modify the codebase. Checks cross-task wiring + global acceptance, not per-task acceptance.
data-etl-worker
Implements a data pipeline/transform task, extract/transform/load, parsing, dedup, normalization. Write-capable; prefers DuckDB SQL for the transform per the house stack. Dispatched by /kit:execute step 2b-0 as the data-etl domain implementer.
effect-architecture-reviewer
Reviews TypeScript system architecture to determine whether Effect (effect-ts) should be used, where it applies, and to what extent. Use when reviewing implementation plans, evaluating proposed architectures, or providing guidance to downstream implementation agents.
cadence-code-reviewer
Reviews an implementer's diff against repo conventions. Second of two review stages. Runs AFTER cadence-spec-reviewer approves. Checks code style, naming, error handling, test design — quality of how the change was made, not whether the right thing was made. Conflicts with spec-reviewer's findings are resolved by spec…