ecc-tools-cost-audit

name	ecc-tools-cost-audit
description	证据优先的 ECC Tools 消耗和计费审计工作流。当调查失控的 PR 创建、配额绕过、高级模型泄漏、重复作业或 GitHub App 成本飙升时使用。
origin	ECC

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 视为危险递归路径，直到证明不是
• 明确分离三件事：
  • 仓库侧消耗根因
  • 面向客户的计费影响
  • 需要 backlog 跟进的产品或权限缺口

工作流

1. 冻结仓库范围

• 切换到兄弟 ECC-Tools 仓库
• 首先检查分支和本地差异
• 确定审计下的确切接口：
  • webhook 路由器
  • 队列生产者
  • 队列消费者
  • PR 创建路径
  • 使用量预留 / 计费路径
  • 模型路由路径

2. 在理论分析之前追踪入口

• 首先检查 src/index.* 或主入口点
• 在建议修复之前映射每个入队路径
• 确认哪些 GitHub 事件共享队列类型
• 确认 push、pull_request、synchronize、comment 或手动重跑事件是否会汇聚到同一条昂贵路径

3. 追踪 worker 和副作用

• 检查处理分析的队列消费者或定时 worker
• 确认排队的分析是否总是以以下方式结束：
  • PR 创建
  • 分支创建
  • 文件更新
  • 高级模型调用
  • 使用量递增
• 如果分析可以在输出持久化之前花费 token 然后失败，将其分类为有损输出的消耗

4. 审计高信号消耗路径

PR 乘法

• 检查 PR 辅助函数和分支命名
• 检查去重、synchronize 事件处理和现有 PR 复用
• 如果应用生成的分支可以重新进入分析，将其视为优先级 0 的递归风险

配额绕过

• 检查配额检查位置与使用量预留或递增位置
• 如果配额在入队前检查但使用量仅在 worker 内计费，将并发前门通过视为真实的竞争条件

高级模型泄漏

• 检查模型选择、层级分支和提供者路由
• 验证免费或受限用户在高级密钥存在时是否仍然可以命中高级分析器

重试消耗

• 检查重试循环、重复队列作业和确定性失败重跑
• 如果相同的非瞬态错误可以反复花费分析，在质量改进之前先修复此问题

5. 按消耗顺序修复

如果用户要求代码更改，按以下顺序优先修复：

1. 停止自动 PR 乘法
2. 停止配额绕过
3. 停止高级泄漏
4. 停止重复作业扇出和无意义的重试
5. 关闭重跑/更新安全缺口

将此次检查限制在 1-3 个直接修复，除非相同的根因明确跨越多个文件。

6. 用最小的证明步骤验证

• 仅重跑覆盖更改路径的目标测试或集成切片
• 验证消耗路径现在是：
  • 被阻止
  • 已去重
  • 降级到更便宜的分析
  • 或被提前拒绝
• 准确说明最终状态：
  • 本地已更改
  • 本地已验证
  • 已推送
  • 已部署
  • 仍然被阻止

高信号故障模式

1. 所有触发器共用一个队列类型

如果 push、PR 同步和手动审计都入队相同的作业，且 worker 总是创建 PR，则分析等于 PR 垃圾。

2. 入队后使用量预留

如果使用量在前门检查但仅在 worker 中递增，并发请求都可以通过门控并超出配额。

3. 免费层级走高级路径

如果免费的排队作业在密钥存在时仍可以路由到 Anthropic 或其他高级提供者，这是真实的消耗泄漏，即使用户从未看到高级结果。

4. 应用生成的分支重新进入 webhook

如果 pull_request.synchronize、分支 push 或评论触发的运行在应用拥有的分支上触发，应用可以递归分析自己的输出。

5. 持久化安全之前的昂贵工作

如果系统可以花费 token 然后在 PR 创建、文件更新或分支冲突时失败，它在未交付价值的情况下消耗成本。

常见陷阱

• 不要从广泛的仓库漫游开始；先确定 webhook -> 队列 -> worker
• 不要将客户计费推断与代码支持的产品事实混为一谈
• 不要在最高消耗路径被控制之前修复低价值质量问题
• 不要在窄范围证明步骤被重跑之前声称消耗已修复
• 除非用户要求，否则不要推送或部署
• 不要触碰已经进行中的不相关的仓库本地更改

验证

• 根因引用确切的文件路径和代码区域
• 修复按消耗影响排序，而非代码整洁度
• 证明命令已命名
• 最终状态区分本地更改、验证、推送和部署