ecc-tools-cost-audit

ECC Tools Kostenprüfung (Cost Audit)

Verwenden Sie diesen Skill, wenn der Benutzer vermutet, dass die ECC Tools GitHub App Kosten verursacht, übermäßig viele PRs erstellt, Nutzungslimits umgeht oder kostenlose Benutzer in Premium-Analysepfade lenkt.

Dies ist ein spezialisierter Workflow für das Schwester-Repository ECC-Tools. Es handelt sich nicht um einen generischen Abrechnungsskill und nicht um eine repositoryweite Code-Review-Runde.

Skill-Stack

Ziehen Sie bei Bedarf diese ECC-eigenen Skills in den Workflow ein:

• autonomous-loops für begrenzte mehrstufige Audits, die Webhooks, Queues, Abrechnung und Wiederholungen umfassen
• agentic-engineering für die Rückverfolgung des Anforderungspfads in diskrete, nachweisbare Einheiten
• customer-billing-ops wenn Repository-Verhalten und kundenbezogene Kostenberechnung sauber getrennt werden müssen
• search-first bevor Sie Hilfsfunktionen erfinden oder repositoriespezifische Dienstprogramme neu implementieren
• security-review wenn Authentifizierung, Nutzungsgates, Berechtigungen oder Secrets betroffen sind
• verification-loop für den Nachweis der Wiedersicherheit und des exakten Zustands nach der Behebung
• tdd-workflow wenn die Behebung eine Regressionstests im Worker, Router oder in den Abrechnungspfaden benötigt

Wann verwenden

• Der Benutzer erwähnt ECC Tools Kostenrate, PR-Rekursion, übermäßig erstellte PRs, Nutzungslimit-Umgehung oder Premium-Modell-Leckage
• Die Aufgabe befindet sich im Schwester-Repository ECC-Tools und hängt von Webhook-Handlern, Queue-Workern, Nutzungsreservierung, PR-Erstellungslogik oder der Durchsetzung von Zahlungsgates ab
• Ein Kundenbericht besagt, dass die App zu viele PRs erstellt, falsch abgerechnet oder Code analysiert hat, ohne ein nutzbares Ergebnis zu liefern

Scope-Begrenzungen

• Arbeiten Sie im Schwester-Repository ECC-Tools, nicht in everything-claude-code
• Beginnen Sie nur lesend, es sei denn, der Benutzer hat explizit nach einer Behebung gefragt
• Mutieren Sie während der Analyse der Kostenverursachung keine nicht zusammenhängenden Abrechnungs-, Checkout- oder UI-Abläufe
• Behandeln Sie App-generierte Branches und App-generierte PRs als Warnsignale für Rekursionspfade, bis das Gegenteil bewiesen ist
• Trennen Sie explizit drei Dinge:
  • Kostenursache auf Repository-Seite
  • Kundenwirksame Abrechnungsauswirkung
  • Produkt- oder Berechtigungslücken, die eine Nachverfolgung im Backlog erfordern

Workflow

1. Repository-Scope festlegen

• Wechseln Sie in das Schwester-Repository ECC-Tools
• Überprüfen Sie zuerst Branch und lokale Änderungen (Diff)
• Identifizieren Sie die genaue zu prüfende Oberfläche:
  • Webhook-Router
  • Queue-Producer
  • Queue-Consumer
  • PR-Erstellungspfad
  • Nutzungsreservierung / Abrechnungspfad
  • Modell-Routing-Pfad

2. Eingang verfolgen, bevor Sie Theorien aufstellen

• Untersuchen Sie zuerst src/index.* oder den Haupteinstiegspunkt
• Kartieren Sie jeden Enqueue-Pfad, bevor Sie eine Lösung vorschlagen
• Bestätigen Sie, welche GitHub-Ereignisse denselben Queue-Typ verwenden
• Bestätigen Sie, ob Push-, pull_request-, synchronize-, Kommentar- oder manuelle Wiederholungsereignisse auf demselben teuren Pfad zusammenlaufen können

3. Worker und Seiteneffekte verfolgen

• Untersuchen Sie den Queue-Consumer oder den geplanten Worker, der die Analyse durchführt
• Bestätigen Sie, ob eine in die Queue eingereihte Analyse immer endet mit:
  • PR-Erstellung
  • Branch-Erstellung
  • Dateiaktualisierungen
  • Premium-Modell-Aufrufen
  • Nutzungszuwächsen
• Wenn die Analyse Tokens verbrauchen und dann fehlschlagen kann, bevor die Ausgabe gespeichert wird, klassifizieren Sie dies als "Burn mit defekter Ausgabe"

4. Hochsignal-Kostenpfade prüfen

PR-Multiplikation

• Untersuchen Sie PR-Hilfsfunktionen und Branch-Namensgebung
• Überprüfen Sie Deduplizierung, synchronize-Ereignisbehandlung und Wiederverwendung vorhandener PRs
• Wenn App-generierte Branches erneut in die Analyse eingehen können, behandeln Sie dies als ein Rekursionsrisiko mit Priorität 0

Quota-Umgehung

• Untersuchen Sie, wo die Quote geprüft wird, im Vergleich zu wo die Nutzung reserviert oder erhöht wird
• Wenn die Quote vor dem Enqueue geprüft wird, die Nutzung aber nur im Worker berechnet wird, behandeln Sie gleichzeitige Passagen durch die vordere Tür als echten Race Condition

Premium-Modell-Leckage

• Untersuchen Sie die Modellauswahl, die Verzweigung nach Tarifen und das Provider-Routing
• Verifizieren Sie, ob kostenlose oder gedeckelte Benutzer immer noch Premium-Analysatoren erreichen können, wenn Premium-Schlüssel vorhanden sind

Wiederholungsbedingter Kostenverbrauch

• Untersuchen Sie Wiederholungsschleifen, doppelte Queue-Jobs und deterministische Fehlerwiederholungen
• Wenn derselbe nicht-temporäre Fehler wiederholt Analysen verbrauchen kann, beheben Sie dies vor Qualitätsverbesserungen

5. Nach Kostenpriorität beheben

Wenn der Benutzer Codeänderungen wünscht, priorisieren Sie die Behebungen in dieser Reihenfolge:

1. Stoppen der automatischen PR-Multiplikation
2. Stoppen der Quota-Umgehung
3. Stoppen der Premium-Leckage
4. Stoppen der doppelten Job-Verzweigung und unnötiger Wiederholungen
5. Schließen von Sicherheitslücken bei Wiederholungen/Aktualisierungen

Halten Sie den Durchlauf auf ein bis drei direkte Behebungen begrenzt, es sei denn, dieselbe Ursache erstreckt sich eindeutig auf mehrere Dateien.

6. Mit den kleinsten Nachweisschritten verifizieren

• Führen Sie nur die gezielten Tests oder Integrationsausschnitte erneut aus, die den geänderten Pfad abdecken
• Verifizieren Sie, ob der Kostenpfad jetzt:
  • blockiert
  • dedupliziert
  • auf eine günstigere Analyse herabgestuft
  • oder frühzeitig abgewiesen wird
• Geben Sie den endgültigen Status genau an:
  • lokal geändert
  • lokal verifiziert
  • gepusht
  • deployed
  • noch blockiert

Hochsignal-Fehlermuster

1. Ein Queue-Typ für alle Auslöser

Wenn Pushes, PR-Synchronisationen und manuelle Audits alle denselben Job in die Queue einreihen und der Worker immer einen PR erstellt, dann ist Analyse gleich PR-Spam.

2. Nutzungsreservierung nach dem Enqueue

Wenn die Nutzung an der vorderen Tür geprüft wird, aber nur im Worker erhöht wird, können gleichzeitige Anforderungen alle das Gate passieren und das Kontingent überschreiten.

3. Kostenlose Tarife auf Premium-Pfaden

Wenn kostenlose Queue-Jobs bei vorhandenen Schlüsseln immer noch in Anthropic oder einen anderen Premium-Anbieter routen können, liegt eine echte Ausgaben-Leckage vor, selbst wenn der Benutzer das Premium-Ergebnis nie sieht.

4. App-generierte Branches treten erneut in den Webhook ein

Wenn pull_request.synchronize, Branch-Pushes oder kommentargetriggerte Ausführungen auf App-eigenen Branches feuern, kann die App ihre eigene Ausgabe rekursiv analysieren.

5. Teure Arbeit vor Sicherung der Dauerhaftigkeit

Wenn das System Tokens verbrauchen und dann bei PR-Erstellung, Dateiaktualisierung oder Branch-Kollision fehlschlagen kann, verbraucht es Kosten, ohne Wert zu liefern.

Fallstricke

• Beginnen Sie nicht mit breitem Repository-Streifzug; klären Sie zuerst Webhook -> Queue -> Worker
• Vermischen Sie nicht kundenbezogene Abrechnungslogik mit durch Code gestützter Produktwahrheit
• Beheben Sie nicht zuerst minderwertige Qualitätsprobleme, bevor der teuerste Pfad eingedämmt ist
• Behalten Sie nicht, dass der Kostenverbrauch behoben ist, bis der enge Nachweisschritt erneut durchgeführt wurde
• Pushen oder deployen Sie nicht, es sei denn, der Benutzer hat darum gebeten
• Berühren Sie keine nicht zusammenhängenden repositoriespezifischen Änderungen, wenn diese bereits in Arbeit sind

Verifikation

• Ursachen zitieren exakte Dateipfade und Codebereiche
• Behebungen sind nach Kostenauswirkungen geordnet, nicht nach Code-Sauberkeit
• Nachweisbefehle sind benannt
• Endgültiger Status unterscheidet zwischen lokaler Änderung, Verifikation, Push und Deployment