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