ECC Tools 成本审计
当用户怀疑 ECC Tools GitHub App 消耗过高、过度创建 PR、绕过使用限制或将免费用户路由到高级分析路径时，使用此技能。
这是一个针对兄弟仓库 ECC-Tools 的专注运维工作流。它不是通用的计费技能，也不是仓库范围的代码审查。
技能栈
在相关时，将以下 ECC 原生技能引入工作流：
autonomous-loops用于跨 Webhook、队列、计费和重试的有界多步审计agentic-engineering用于将请求路径追溯为离散、可证明的单元customer-billing-ops用于清晰分离仓库行为与客户影响计算search-first在发明辅助工具或重新实现仓库本地工具之前使用security-review当涉及身份验证、使用门控、权限或密钥时使用verification-loop用于证明重试安全性和精确的修复后状态tdd-workflow当修复需要在 worker、路由器或计费路径中添加回归测试覆盖时使用
何时使用
- 用户提到 ECC Tools 的消耗速率、PR 递归、过度创建的 PR、使用限制绕过或高级模型泄露
- 任务位于兄弟仓库
ECC-Tools中，并依赖于 Webhook 处理器、队列 worker、使用量预留、PR 创建逻辑或付费门控实施 - 客户报告称应用创建了过多 PR、计费错误或分析了代码但未产生可用结果
范围护栏
- 在兄弟仓库
ECC-Tools中工作，而不是在everything-claude-code中 - 从只读开始，除非用户明确要求修复
- 在追踪分析消耗时，不要修改无关的计费、结算或 UI 流程
- 将应用生成的分支和应用生成的 PR 视为红色标志递归路径，直到被证明并非如此
- 明确分离三件事：
- 仓库侧消耗根源
- 面向客户的计费影响
- 需要纳入后续迭代的产品或权限缺口
工作流程
1. 冻结仓库范围
- 切换到兄弟仓库
ECC-Tools - 首先检查分支和本地差异
- 确定审计的确切表面：
- Webhook 路由器
- 队列生产者
- 队列消费者
- PR 创建路径
- 使用量预留/计费路径
- 模型路由路径
2. 在理论化之前追踪入口
- 首先检查
src/index.*或主入口点 - 在建议修复之前，映射每个入队路径
- 确认哪些 GitHub 事件共享相同的队列类型
- 确认 push、pull_request、synchronize、comment 或手动重跑事件是否可以汇聚到同一个昂贵路径上
3. 追踪 worker 和副作用
- 检查处理分析的队列消费者或计划调度 worker
- 确认一个排队分析是否总是以以下方式结束：
- PR 创建
- 分支创建
- 文件更新
- 高级模型调用
- 使用量递增
- 如果分析可以消耗令牌然后在输出持久化之前失败，则将其归类为“输出断裂的消耗”
4. 审计高信号消耗路径
PR 倍增
- 检查 PR 辅助函数和分支命名
- 检查去重、synchronize 事件处理和现有 PR 重用
- 如果应用生成的分支可以重新进入分析，则将其视为优先级 0 的递归风险
配额绕过
- 检查配额在哪里被检查，与使用量在哪里被预留或递增进行比较
- 如果配额在入队之前被检查，但使用量仅在 worker 内部被计费，则将并发的正面入口视为真实的竞态条件
高级模型泄露
- 检查模型选择、层级分支和提供商路由
- 当高级 API 密钥存在时，验证免费或有上限的用户是否仍能命中高级分析器
重试消耗
- 检查重试循环、重复队列作业和确定性失败重跑
- 如果同一个非瞬时错误可以重复消耗分析资源，请先修复此问题，然后再进行质量改进
5. 按消耗顺序修复
如果用户要求代码更改，按以下顺序确定修复优先级：
- 阻止自动 PR 倍增
- 阻止配额绕过
- 阻止高级模型泄露
- 阻止重复作业扇出和无意义的重试
- 关闭重跑/更新安全缺口
除非同一个根本原因明确跨越多个文件，否则将本次修复限定在一到三个直接修复范围内。
6. 用最小的验证步骤进行验证
- 仅重新运行覆盖已更改路径的目标测试或集成片段
- 验证消耗路径现在是否：
- 被阻塞
- 被去重
- 降级为更便宜的分析
- 或被提前拒绝
- 精确陈述最终状态：
- 本地已更改
- 本地已验证
- 已推送
- 已部署
- 仍被阻塞
高信号失败模式
1. 所有触发器共享一个队列类型
如果推送、PR 同步和手动审计都入队相同的作业，并且 worker 总是创建一个 PR，那么分析就等于 PR 垃圾邮件。
2. 入队后使用量预留
如果使用量在“前门”被检查，但仅在 worker 中递增，那么并发请求可能全部通过门控并超过配额。
3. 免费层级走高级路径
如果排队的免费作业在存在 API 密钥时仍然可以路由到 Anthropic 或其他高级提供商，那么即使从未向用户展示高级结果，这也是真实的资金泄露。
4. 应用生成的分支重新进入 Webhook
如果 pull_request.synchronize、分支推送或评论触发的运行在应用拥有的分支上触发，应用可以递归分析其自身输出。
5. 在持久化安全保障之前进行昂贵工作
如果系统可以在 PR 创建、文件更新或分支冲突之前消耗令牌然后失败，那么它就是在燃烧成本而不交付价值。
陷阱
- 不要一开始就进行广泛的仓库漫游；先确定 Webhook -> 队列 -> Worker 的顺序
- 不要将客户计费推断与基于代码的产品事实混为一谈
- 在最高消耗路径得到遏制之前，不要修复价值较低的质量问题
- 在重新运行狭窄的证明步骤之前，不要声称消耗问题已修复
- 除非用户要求，否则不要推送或部署
- 如果无关的仓库本地更改正在进行中，请不要触碰它们
验证
- 根本原因应引用确切的文件路径和代码区域
- 修复应按消耗影响排序，而非代码整洁度
- 证明命令应被命名
- 最终状态应区分本地更改、验证、推送和部署