JuliusBrussee/caveman-evidence-review

Caveman-Evidenz überprüfen

Agieren Sie als schreibgeschützter Operator. Ziehen Sie Schlussfolgerungen aus aktuellen Caveman-Daten, nicht aus Repository-Vermutungen. Starten, genehmigen, abbrechen oder rollen Sie keine Experimente mit diesem Skill zurück.

Harte Regeln

1. Halten Sie diese Kategorien getrennt:
   • gemessene anbieterabgeschlossene Listenpreiskosten;
   • inferred täglicher Spielraum;
   • verified Buchhaltungseinsparungen;
   • Evidenzkosten. Fügen Sie sie nie hinzu oder benennen Sie sie um.
2. Rufen Sie keine Prompt-, Completion-, Tool- oder Artefakt-Payloads ab, es sei denn, der Benutzer fordert explizit eine Payload-Überprüfung an. Metadaten, Spans, Zeitangaben, Modelle, Tokenanzahlen, Status und Optimierer-Zuordnung reichen für die Standardüberprüfung aus.
3. Begrenzen Sie jede Leseaktion auf das durch den Caveman-Kontext ausgewählte Projekt. Geben Sie niemals eine Organisations-ID an.
4. Leere Ergebnisse sind Hinweise auf kein aktuelles Signal, nicht auf Nullkosten oder Nullrisiko.
5. Zitieren Sie Trace-IDs und genaue Zeitfenster. Behaupten Sie keine Ursache allein aus einem Aggregat.

Schritt 1 – Kontext laden

Bevorzugen Sie MCP:

caveman_context {}

CLI-Fallback:

caveman cloud whoami
caveman cloud projects list

Stoppen Sie, wenn Login oder Projektauswahl fehlt. Bitten Sie den Benutzer, caveman login auszuführen oder ein Projekt auszuwählen; raten Sie niemals.

Schritt 2 – Baseline ermitteln

Verwenden Sie caveman_report für:

• overview
• costs
• score
• workflows
• verified_savings

Verwenden Sie dann caveman_plan für den nach Relevanz geordneten täglichen Spielraum. Wenn die Frage eng gefasst ist, überspringen Sie nicht relevante Berichte. Lesen Sie den kürzesten Satz, der sie beantworten kann.

CLI-Fallback:

caveman cloud costs
caveman cloud score
caveman cloud plan --json

Geben Sie das Berichtsfenster und die Basis an, bevor Sie die Richtung interpretieren.

Schritt 3 – Die führende Erklärung mit Traces testen

Verwenden Sie caveman_trace_search. Wählen Sie ein begrenztes Fenster und geschlossene Filter aus: Workflow, Agent, Modell, Anbieter, Fehlercode, Laufzeitmodus, Cache-Status, Optimierungs-ID, Statusklasse, Token-/Kosten-/Latenzgrenzen, Kompression oder Prüfergebnis.

Nützliche Gruppierungen:

• workflow – Aufträge finden, die Kosten oder Fehler verursachen;
• model – Modellmix vergleichen;
• session – Wiederholungs- oder Schleifenverhalten isolieren;
• ungruppiert – genaue Traces identifizieren.

Vergleichen Sie eine verdächtige Kohorte mit einer Kontrollkohorte oder einem früheren begrenzten Zeitfenster. Leiten Sie keine Kausalität aus einem einzigen teuren Trace ab.

CLI-Fallback:

caveman cloud traces search \
  --workflow <slug> \
  --from <RFC3339> \
  --to <RFC3339> \
  --sort total_cost_usd \
  --dir desc \
  --limit 25

Schritt 4 – Repräsentative Traces inspizieren

Rufen Sie caveman_trace_get für eine kleine Anzahl von stark signalgebenden Trace-IDs auf. Inspizieren Sie Anfrage- und Span-Metadaten, Latenz, Status, Tokenanzahlen, Cache-Zustand, angewandte Optimierer und Modellroute. Lassen Sie Payload-Abrufe aus.

CLI-Fallback:

caveman cloud traces show <trace-id> --spans

Schritt 5 – Bericht

Verwenden Sie dieses Format:

## Caveman-Evidenz-Prüfbericht

Umfang: <Projekt> · <von> bis <bis>
Gemessene Kosten: <Wert und Basis>
Bestätigte Einsparungen: <Buchhaltungswert, getrennt gehalten>
Abgeleiteter Spielraum: <Band pro Tag, getrennt gehalten>

Erkenntnisse:
1. <Erkenntnis> — <Aggregatevidenz> — Traces <IDs>
2. <Erkenntnis> — <Aggregatevidenz> — Traces <IDs>

Unbelegt:
- <plausible Erklärung ohne Kontrolle, Trace oder Auswertung>

Nächster schreibgeschützter Check:
- <eine begrenzte Abfrage>

Mögliche Aktion:
- <nur Vorschlag; für schreibgeschützten Lebenszyklus-Review und Sicherheitstor caveman-manage verwenden>

Wenn Daten fehlen, nennen Sie das fehlende Signal und stoppen Sie bei der stärksten unterstützten Aussage. Machen Sie niemals aus einer Katalogsumme eine Rechnung oder aus einem Experimentergebnis bestätigte Einsparungen.