ECC ツール コスト監査

ユーザーが 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 を赤旗再帰パスとして扱う。ただし、そうでないことが証明されている場合を除く
• 以下の3つを明確に区別する：
  • リポジトリ側消費の根本原因
  • 顧客向け請求への影響
  • バックログ追跡に含める必要があるプロダクトまたは認可ギャップ

ワークフロー

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 内部でのみ使用量を計費する場合、並行フロント通過を真の競合状態として扱う

有料モデルリーク

• モデル選択、階層分岐、プロバイダルーティングを確認する
• 有料キーが存在する場合、無料またはアクセス制限ユーザーが有料分析器にアクセスできるかどうかを検証する

リトライ消費

• リトライループ、重複キュータスク、決定論的失敗リトライを確認する
• 同じ一時的でないエラーが反復的に分析リソースを消費できる場合、品質改善前にこれを修正する

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、ブランチプッシュ、またはコメントでトリガーされた実行がアプリ所有ブランチで発生する場合、アプリは自身の出力を再帰的に分析できます。

5. 永続化安全前に高コスト操作を実行

システムがトークンを消費してから PR 作成、ファイル更新、またはブランチ競合で失敗する可能性がある場合、これは価値を生成せずにコストを消費しています。

よくある落とし穴

• 最初から広くリポジトリを閲覧しないこと。webhook → キュー → worker パスを最初に確立する
• 顧客請求推論とコードベース製品事実を混在させないこと
• 最高消費パスが制御されるまで、低価値の品質問題を修正しないこと
• 狭い検証ステップを再実行する前に、消費問題が修正されたと主張しないこと
• ユーザーが要求しない限り、プッシュまたはデプロイしないこと
• 無関係なリポジトリローカル変更が進行中の場合、これらに触れないこと

検証

• 根本原因は正確なファイルパスとコード領域を参照する必要がある
• 修正はコード整潔性ではなく、消費影響に基づいてソートされている
• 検証コマンド名を示す
• 最終状態はローカル変更、検証、プッシュ、デプロイを区別する