ecc-tools-cost-audit

name	ecc-tools-cost-audit
description	エビデンスファーストな ECC Tools の消費と課金の監査ワークフローです。ECC Tools リポジトリでの暴走する PR 作成、クォータバイパス、premium モデルリーク、重複ジョブ、または GitHub App のコストスパイクを調査する場合に使用します。
origin	ECC

ECC Tools Cost Audit

ECC Tools GitHub App がコストを消費している、PR を作りすぎている、使用制限をバイパスしている、または無料ユーザーを premium 分析パスにルーティングしているとユーザーが疑う場合に、このスキルを使用します。

これは兄弟 ECC-Tools リポジトリ向けの焦点を絞ったオペレーターワークフローです。汎用的な課金スキルではなく、リポジトリ全体のコードレビューパスでもありません。

Skill Stack

関連する場合、以下の ECC ネイティブスキルをワークフローに取り込みます:

• webhook、キュー、課金、リトライをまたぐ境界のある多段階監査には autonomous-loops
• リクエストパスを離散的で証明可能な単位にトレースするには agentic-engineering
• リポジトリの挙動とカスタマー影響の計算を明確に分離する必要がある場合は customer-billing-ops
• ヘルパーを発明したりリポジトリローカルのユーティリティを再実装したりする前に search-first
• 認証、使用ゲート、entitlement、またはシークレットが触れられる場合は security-review
• 再実行安全性と修正後の正確な状態を証明するには verification-loop
• 修正が worker、ルーター、または課金パスでのリグレッションカバレッジを必要とする場合は tdd-workflow

使用タイミング

• ユーザーが ECC Tools の消費率、PR 再帰、PR の過剰作成、使用制限バイパス、または premium モデルリークに言及する
• タスクが兄弟 ECC-Tools リポジトリ内にあり、webhook ハンドラ、キューワーカー、使用予約、PR 作成ロジック、または有料ゲート強制に依存する
• カスタマーレポートがアプリが PR を作りすぎた、課金を誤った、または使用可能な結果を生成せずにコードを分析したと述べる

スコープガードレール

• everything-claude-code ではなく、兄弟 ECC-Tools リポジトリで作業する
• ユーザーが修正を明確に要求しない限り、read-only で開始する
• 分析消費をトレースしている間、無関係な課金、チェックアウト、または UI フローを変更しない
• アプリ生成ブランチとアプリ生成 PR を、そうでないことが証明されるまで赤フラグの再帰パスとして扱う
• 3 つのことを明示的に分離する:
  • リポジトリ側の消費の根本原因
  • カスタマー向けの課金影響
  • バックログフォローアップが必要な製品または entitlement のギャップ

ワークフロー

1. リポジトリスコープを固定する

• 兄弟 ECC-Tools リポジトリに切り替え
• まずブランチとローカル diff を確認
• 監査対象の正確なサーフェスを特定:
  • webhook ルーター
  • キュープロデューサー
  • キューコンシューマー
  • PR 作成パス
  • 使用予約 / 課金パス
  • モデルルーティングパス

2. 理論化する前に ingress をトレースする

• まず src/index.* またはメインエントリーポイントを調査
• 修正を提案する前にすべての enqueue パスをマッピング
• どの GitHub イベントが同じキュータイプを共有するか確認
• push、pull_request、synchronize、comment、または手動再実行イベントが同じ高コストパスに収束できるか確認

3. ワーカーとサイドエフェクトをトレースする

• 分析を処理するキューコンシューマーまたはスケジュールされたワーカーを調査
• キューイングされた分析が常に以下で終わるか確認:
  • PR 作成
  • ブランチ作成
  • ファイル更新
  • premium モデル呼び出し
  • 使用インクリメント
• 分析がトークンを消費した後、出力が永続化される前に失敗できる場合、出力壊れ消費として分類

4. 高シグナルの消費パスを監査する

PR 多重化

• PR ヘルパーとブランチ命名を調査
• dedupe、synchronize イベント処理、既存 PR 再利用を確認
• アプリ生成ブランチが分析に再入できる場合、priority-0 再帰リスクとして扱う

クォータバイパス

• どこでクォータがチェックされ、どこで使用が予約またはインクリメントされるかを調査
• クォータが enqueue 前にチェックされるが使用がワーカー内でのみ課金される場合、並行するフロントドアパスを真のレースとして扱う

Premium モデルリーク

• モデル選択、tier ブランチング、プロバイダールーティングを調査
• premium キーが存在する場合、無料またはキャップされたユーザーがまだ premium アナライザーに到達できるか検証

リトライ消費

• リトライループ、重複キュージョブ、決定論的失敗の再実行を調査
• 同じ非一時的エラーが繰り返し分析を消費できる場合、品質改善の前にそれを修正

5. 消費順で修正する

ユーザーがコード変更を要求した場合、以下の順で修正を優先します:

1. 自動 PR 多重化を停止
2. クォータバイパスを停止
3. premium リークを停止
4. 重複ジョブのファンアウトと無意味なリトライを停止
5. 再実行/更新の安全性ギャップを閉じる

同じ根本原因が複数のファイルに明確にまたがる場合を除き、パスを 1 〜 3 の直接的な修正に制限します。

6. 最小の証明ステップで検証する

• 変更されたパスをカバーするターゲットされたテストまたは統合スライスのみを再実行
• 消費パスが今以下のいずれかか検証:
  • ブロックされている
  • deduped
  • より安価な分析にダウングレードされた
  • または早期に拒否された
• 最終ステータスを正確に述べる:
  • ローカルで変更済み
  • ローカルで検証済み
  • push 済み
  • deploy 済み
  • まだブロック中

高シグナル失敗パターン

1. すべてのトリガーに対する 1 つのキュータイプ

push、PR sync、手動監査すべてが同じジョブを enqueue し、ワーカーが常に PR を作成する場合、分析は PR スパムに等しい。

2. Enqueue 後の使用予約

使用がフロントドアでチェックされるがワーカー内でのみインクリメントされる場合、並行リクエストすべてがゲートを通過してクォータを超過できる。

3. Premium パス上の無料 tier

キーが存在する場合に無料のキューイングされたジョブが Anthropic や他の premium プロバイダーにルーティングできる場合、ユーザーが premium 結果を見ない場合でも、それは本物の消費リークである。

4. アプリ生成ブランチが webhook に再入

pull_request.synchronize、ブランチ push、またはコメントトリガー実行がアプリ所有のブランチで発火する場合、アプリは自身の出力を再帰的に分析できる。

5. 永続化安全性前の高コスト作業

システムがトークンを消費した後に PR 作成、ファイル更新、またはブランチ衝突で失敗できる場合、それは価値を出荷せずにコストを消費している。

落とし穴

• 広範なリポジトリ探索で始めない。webhook -> キュー -> worker を先に固める
• カスタマー課金の推測をコードに裏付けられた製品の真実と混ぜない
• 最高消費パスが封じ込められる前に低価値の品質問題を修正しない
• 絞られた証明ステップが再実行されるまで消費が修正されたと主張しない
• ユーザーが要求しない限り push または deploy しない
• 既に進行中の無関係なリポジトリローカル変更に触れない

検証

• 根本原因が正確なファイルパスとコード領域を引用する
• 修正がコードのきれいさではなく消費影響で順序付けられる
• 証明コマンドが名前付けされる
• 最終ステータスがローカル変更、検証、push、deploy を区別する