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：修正にワーカー、ルーター、または課金パスの回帰テストカバレッジが必要な場合
使用するタイミング
- ユーザーが ECC Tools の消費速度、PRの再帰、過剰なPR作成、使用制限のバイパス、またはプレミアムモデル漏洩に言及した場合
- タスクが関連する
ECC-Toolsリポジトリ内にあり、Webhookハンドラ、キューワーカー、使用予約、PR作成ロジック、または有料ゲートの強制に依存している場合 - 顧客レポートで、アプリがPRを作りすぎた、誤って課金した、または有用な結果を生成せずにコードを分析したと報告された場合
スコープガードレール
everything-claude-codeではなく、関連するECC-Toolsリポジトリ内で作業する- ユーザーが明確に修正を依頼しない限り、読み取り専用で開始する
- 分析消費をトレースしている間、関連のない課金、チェックアウト、またはUIフローを変更しない
- アプリが生成したブランチとアプリが生成したPRは、証明されるまで赤旗の再帰パスとして扱う
- 以下の3つを明示的に分離する：
- リポジトリ側の消費根本原因
- 顧客向けの課金影響
- バックログフォローアップが必要なプロダクトまたはエンタイトルメントのギャップ
ワークフロー
1. リポジトリのスコープを固定
- 関連する
ECC-Toolsリポジトリに切り替える - 最初にブランチとローカルの差分を確認する
- 監査対象の正確な表面を特定する：
- Webhookルーター
- キュープロデューサー
- キューコンシューマー
- PR作成パス
- 使用予約 / 課金パス
- モデルルーティングパス
2. 理論化する前にイングレスをトレース
- 最初に
src/index.*またはメインエントリポイントを検査する - 修正を提案する前に、すべてのエンキューパスをマッピングする
- どのGitHubイベントが同じキュータイプを共有しているか確認する
- push、pull_request、synchronize、comment、または手動再実行イベントが同じ高コストパスに収束できるか確認する
3. ワーカーと副作用をトレース
- 分析を処理するキューコンシューマーまたはスケジュールされたワーカーを検査する
- キューに入れられた分析が常に以下で終了するか確認する：
- PR作成
- ブランチ作成
- ファイル更新
- プレミアムモデル呼び出し
- 使用量の増加
- 分析がトークンを消費し、出力が永続化される前に失敗する可能性がある場合、それを「出力破損を伴う消費」として分類する
4. 高シグナル消費パスを監査する
PRの多重化
- PRヘルパーとブランチ命名規則を検査する
- 重複排除、同期イベント処理、既存PRの再利用を確認する
- アプリが生成したブランチが再び分析に入る可能性がある場合、それを優先度0の再帰リスクとして扱う
クォータバイパス
- クォータがチェックされる場所と、使用量が予約または増加される場所を検査する
- クォータがエンキュー前にチェックされるが、使用量がワーカー内でのみ課金される場合、同時フロントドア通過を実際の競合状態として扱う
プレミアムモデル漏洩
- モデル選択、ティア分岐、プロバイダールーティングを検査する
- 無料または制限付きユーザーが、プレミアムキーが存在する場合にプレミアムアナライザーに到達できるか検証する
リトライ消費
- リトライループ、重複キュージョブ、決定論的な失敗再実行を検査する
- 同じ非一時的エラーが分析を繰り返し消費する可能性がある場合、品質向上の前にそれを修正する
5. 消費順に修正する
ユーザーがコード変更を依頼した場合、以下の順序で修正を優先する：
- 自動PRの多重化を停止する
- クォータバイパスを停止する
- プレミアム漏洩を停止する
- 重複ジョブのファンアウトと無意味なリトライを停止する
- 再実行/更新の安全ギャップを閉じる
同じ根本原因が明確に複数のファイルにまたがっていない限り、1〜3つの直接修正にパスを制限する。
6. 最小の証明ステップで検証する
- 変更したパスをカバーする、対象を絞ったテストまたは統合スライスのみを再実行する
- 消費パスが現在以下の状態であるか検証する：
- ブロックされた
- 重複排除された
- より安価な分析にダウングレードされた
- または早期に拒否された
- 最終ステータスを正確に述べる：
- ローカルで変更済み
- ローカルで検証済み
- プッシュ済み
- デプロイ済み
- まだブロック中
高シグナル障害パターン
1. すべてのトリガーに対して1つのキュータイプ
プッシュ、PR同期、手動監査のすべてが同じジョブをエンキューし、ワーカーが常にPRを作成する場合、分析はPRスパムと等しくなります。
2. エンキュー後の使用予約
使用量がフロントドアでチェックされるが、ワーカー内でのみ増加する場合、同時リクエストはすべてゲートを通過し、クォータを超える可能性があります。
3. プレミアムパス上の無料ティア
無料のキューに入れられたジョブが、キーが存在する場合にAnthropicまたは別のプレミアムプロバイダーにルーティングされる可能性がある場合、ユーザーがプレミアム結果を決して見なくても、実際の支出漏洩です。
4. アプリが生成したブランチがWebhookに再進入する
pull_request.synchronize、ブランチプッシュ、またはコメントトリガー実行がアプリ所有のブランチで発生する場合、アプリは自身の出力を再帰的に分析できます。
5. 永続性の安全性の前の高コスト作業
システムがトークンを消費し、PR作成、ファイル更新、またはブランチ競合で失敗する可能性がある場合、価値を出荷せずにコストを燃焼しています。
落とし穴
- 広範なリポジトリ探索から始めないでください。最初に Webhook -> キュー -> ワーカーの順に確定してください
- 顧客請求の推論と、コードに基づく製品の真実を混在させないでください
- 最も高い消費パスが封じ込められる前に、低価値の品質問題を修正しないでください
- 狭い証明ステップが再実行されるまで、消費が修正されたと主張しないでください
- ユーザーが依頼しない限り、プッシュまたはデプロイしないでください
- 進行中のリポジトリローカルの変更がすでにある場合、それに触れないでください
検証
- 根本原因は正確なファイルパスとコード領域を引用する
- 修正はコードのきれいさではなく、消費影響で順序付けられる
- 証明コマンドは名前付きである
- 最終ステータスは、ローカル変更、検証、プッシュ、デプロイを区別する