ECC Tools 成本审计
当用户怀疑 ECC Tools GitHub App 成本燃烧、过度创建 PR、绕过使用限制或将免费用户路由到高级分析路径时，请使用此技能。
这是一个针对兄弟仓库 ECC-Tools 的聚焦操作工作流。它不是通用计费技能，也不是全仓库代码审查过程。
技能栈
相关时可将以下 ECC 原生技能拉入工作流：
autonomous-loops用于跨越 webhooks、队列、计费和重试的有界多步审计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 - 首先检查分支和本地 diff
- 确定审计的精确表面：
- webhook 路由器
- 队列生产者
- 队列消费者
- PR 创建路径
- 使用预留/计费路径
- 模型路由路径
2. 在理论化之前追踪入口
- 首先检查
src/index.*或主入口点 - 在提出修复之前映射每个入队路径
- 确认哪些 GitHub 事件共享同一队列类型
- 确认 push、pull_request、synchronize、comment 或手动重新运行事件是否会汇聚到同一昂贵路径
3. 追踪 worker 和副作用
- 检查处理分析的队列消费者或定时调度 worker
- 确认排队的分析是否总是以以下之一结束：
- PR 创建
- 分支创建
- 文件更新
- 高级模型调用
- 使用量递增
- 如果分析可能消耗 token 然后在输出被持久化前失败，将其归类为“有破损输出的燃烧”
4. 审计高信号燃烧路径
PR 倍增
- 检查 PR 辅助工具和分支命名
- 检查去重、同步事件处理和现有 PR 复用
- 如果应用生成的分支可能重新进入分析，将其视为优先级为 0 的递归风险
额度绕过
- 检查额度在何处被检查，与使用量被预留或递增的位置
- 如果在入队前检查额度但在 worker 内部才收取使用费，将并发的前门通行视为真实的竞态条件
高级模型泄露
- 检查模型选择、层级分支和提供商路由
- 验证当存在高级密钥时，免费或受限用户是否仍能命中高级分析器
重试燃烧
- 检查重试循环、重复的队列任务和确定性失败重新运行
- 如果相同的非临时错误可能重复消耗分析资源，在质量改进之前先修复此问题
5. 按燃烧顺序修复
如果用户要求代码更改，按此顺序优先修复：
- 停止自动 PR 倍增
- 停止额度绕过
- 停止高级模型泄露
- 停止重复任务扇出和无意义重试
- 关闭重新运行/更新安全缺口
将传递限制为一个到三个直接修复，除非同一根因明显跨多个文件。
6. 以最小的验证步骤验证
- 仅重新运行覆盖更改路径的目标测试或集成切片
- 验证燃烧路径现在是否：
- 被阻止
- 被去重
- 降级为更便宜的分析
- 或提前被拒绝
- 精确说明最终状态：
- 已在本地更改
- 已在本地验证
- 已推送
- 已部署
- 仍被阻止
高信号故障模式
1. 所有触发器的单一队列类型
如果推送、PR 同步和手动审计都将相同任务入队，并且 worker 总是创建 PR，那么分析等于 PR 垃圾信息。
2. 入队后使用预留
如果在前门检查使用量但仅在 worker 中递增，并发请求都可以通过关卡并超过额度。
3. 免费层级在高级路径上
如果免费队列任务在密钥存在时仍可路由到 Anthropic 或其他高级提供商，即使从未看到高级结果，这也是实际的支出泄露。
4. 应用生成的分支重新进入 webhook
如果 pull_request.synchronize、分支推送或评论触发的运行在应用拥有的分支上触发，应用可以递归分析其自身输出。
5. 持久化安全之前的昂贵工作
如果系统可能消耗 token 然后在 PR 创建、文件更新或分支冲突上失败，则是燃烧成本却没有交付价值。
陷阱
- 不要从广泛的仓库漫游开始；先确定 webhook -> 队列 -> worker 的链路
- 不要将客户计费推断与基于代码的产品实情混合
- 在最高燃烧路径被遏制之前，不要修复较低价值的质量问题
- 不要声称燃烧已修复，直到运行了狭窄的验证步骤
- 除非用户要求，否则不要推送或部署
- 如果已有本地更改正在进行，不要触碰无关的仓库本地更改
验证
- 根因引用确切的文件路径和代码区域
- 修复按燃烧影响排序，而非代码整洁度
- 命名验证命令
- 最终状态区分本地更改、验证、推送和部署