trace

Trace Skill

Verwende diesen Skill für mehrdeutige, kausale, evidenzintensive Fragen, bei denen es darum geht zu erklären, warum ein beobachtetes Ergebnis eingetreten ist – nicht darum, sofort in die Korrektur oder Neuschreibung von Code einzusteigen.

Dies ist die Orchestrierungsschicht über dem integrierten tracer-Agenten. Das Ziel ist es, Tracing wie eine wiederverwendbare OMC-Bahn zu gestalten: Beobachtung neu formulieren, konkurrierende Erklärungen generieren, parallel Evidenzen sammeln, die Erklärungen bewerten und die nächste Sonde vorschlagen, die die Unsicherheit am schnellsten beseitigt.

Gute Anwendungsfälle

Verwende /oh-my-claudecode:trace, wenn das Problem:

• mehrdeutig
• kausal
• evidenzintensiv
• am besten durch parallele Untersuchung konkurrierender Erklärungen zu beantworten ist

Beispiele:

• Laufzeitfehler und Regressionen
• Performance / Latenz / Ressourcenverhalten
• Architektur / Prä-Mortem / Post-Mortem-Analyse
• wissenschaftliche oder experimentelle Ergebnisrückverfolgung
• Konfigurations- / Routing- / Orchestrierungsverhalten-Erklärung
• „bei dieser Ausgabe, verfolge die wahrscheinlichen Ursachen zurück“

Kern-Tracing-Vertrag

Behalte immer diese Unterscheidungen bei:

1. Beobachtung – was tatsächlich beobachtet wurde
2. Hypothesen – konkurrierende Erklärungen
3. Evidenzen dafür – was jede Erklärung stützt
4. Evidenzen dagegen / Lücken – was ihr widerspricht oder noch fehlt
5. Derzeit beste Erklärung – die derzeit führende Erklärung
6. Kritische Unbekannte – die fehlende Tatsache, die die Top-Erklärungen trennt
7. Diskriminierende Sonde – der wertvollste nächste Schritt zur Beseitigung der Unsicherheit

Vermeide Folgendes:

• eine generische „Repariere es“-Codierungsschleife
• eine generische Debugger-Zusammenfassung
• eine rohe Ausgabe von Worker-Ergebnissen
• vorgetäuschte Sicherheit, wenn die Evidenz unvollständig ist

Evidenzstärke-Hierarchie

Behandle Evidenzen als gestuft, nicht als flach.

Von stärkster zu schwächster:

1. Kontrollierte Reproduktionen / direkte Experimente / eindeutig diskriminierende Artefakte
2. Primärquellen-Artefakte mit enger Herkunft (Trace-Ereignisse, Logs, Metriken, Benchmark-Ausgaben, Konfigurationen, Git-Historie, datei:zeile-Verhalten)
3. Mehrere unabhängige Quellen, die zur selben Erklärung konvergieren
4. Einzelquellen-Codepfad- oder Verhaltensschlussfolgerung
5. Schwache situative Hinweise (Timing, Benennung, Stapelreihenfolge, Ähnlichkeit mit früheren Fehlern)
6. Intuition / Analogie / Spekulation

Stufe Hypothesen explizit herab, die hauptsächlich auf niedrigeren Stufen beruhen, wenn stärkere widersprüchliche Evidenzen existieren.

Starke Falsifikations-/Widerlegungsregeln

Jeder ernsthafte /trace-Durchlauf muss versuchen, seine eigene favorisierte Erklärung zu falsifizieren.

Für jede Top-Hypothese:

• sammle Evidenzen dafür
• sammle Evidenzen dagegen
• gib an, welche charakteristische Vorhersage sie macht
• gib an, welche Beobachtung schwer mit ihr zu vereinbaren wäre
• identifiziere die günstigste Sonde, die sie von der nächstbesten Alternative unterscheiden würde

Stufe eine Hypothese herab, wenn:

• direkte Evidenzen ihr widersprechen
• sie nur durch Hinzufügen neuer ungeprüfter Annahmen überlebt
• sie im Vergleich zu Rivalen keine charakteristische Vorhersage macht
• eine stärkere Alternative dieselben Fakten mit weniger Annahmen erklärt
• ihre Unterstützung hauptsächlich situativ ist, während der Rivale stärkere Evidenzstufen hat

Team-Modus-Orchestrierungsform

Verwende Claude-eigenen Team-Modus für /trace.

Der Lead sollte:

1. Das beobachtete Ergebnis oder die „Warum“-Frage präzise neu formulieren
2. Das Tracing-Ziel extrahieren
3. Mehrere bewusst unterschiedliche Kandidatenhypothesen generieren
4. Standardmäßig 3 Tracer-Lanes im Team-Modus starten
5. Einem Tracer-Worker pro Lane zuweisen
6. Jeden Tracer-Worker anweisen, Evidenzen für und gegen seine Lane zu sammeln
7. Eine Widerlegungsrunde zwischen der führenden Hypothese und dem stärksten verbleibenden Alternative durchführen
8. Erkennen, ob sich die Top-Lanes wirklich unterscheiden oder tatsächlich zur selben Grundursache konvergieren
9. Ergebnisse in einer Ranglisten-Synthese mit expliziter kritischer Unbekannter und diskriminierender Sonde zusammenführen

Wichtig: Worker sollten bewusst unterschiedliche Erklärungen verfolgen, nicht dieselbe Erklärung parallel.

Standard-Hypothesen-Lanes für v1

Sofern der Prompt keine bessere Aufteilung nahelegt, verwende diese 3 Standard-Lanes:

1. Code-Pfad / Implementierungsursache
2. Konfigurations- / Umgebungs- / Orchestrierungsursache
3. Mess- / Artefakt- / Annahmendiskrepanz-Ursache — umfasst Verifikationsmethoden-Mängel, nicht nur Systemfehler. Beispiele: Die Verifikationsabfrage verwendet einen einzelnen Dimensionsschlüssel über verschiedene Entitäten, Mandanten, Ströme oder Gruppen hinweg; die Vergleichsfilterform entspricht nicht dem Schema-Korn; oder der Katalog- oder Spaltenname wurde ohne Aufzählung als portabel über Laufzeiten hinweg angenommen. Dies beinhaltet Multi-Entitäts-Prämisse/Schlüsselannahme-Diskrepanzen.

Für Lane 3 erfordern entitätsübergreifende Diskrepanzen eine Prämissenprüfung vor der Eskalation: Entitätsdimensionen aufzählen und prüfen, ob ein Nullzeilen- oder Diskrepanzergebnis von der Anwendung eines Schlüssels über mehrere Entitäten herrührt und nicht von einem Systemfehler; das Ergebnis könnte ein Verifikationsmethodik-Mangel sein.

Diese Standardeinstellungen sind bewusst breit gefasst, damit der erste Schnitt über Fehler-, Performance-, Architektur- und Experiment-Tracing hinweg funktioniert.

Verbindliche Querprüfungs-Linsen

Nach dem ersten Evidenzdurchlauf setze die Führenden mit diesen Linsen unter Druck, wenn relevant:

• Systemlinse – Warteschlangen, Wiederholungen, Gegendruck, Rückkopplungsschleifen, Upstream-/Downstream-Abhängigkeiten, Grenzfehler, Koordinationseffekte
• Prä-Mortem-Linse – nimm an, die aktuell beste Erklärung sei unvollständig oder falsch; welcher Fehlermodus würde den Trace später in Verlegenheit bringen?
• Wissenschaftslinse – Kontrollen, Confounder, Messfehler, alternative Variablen, falsifizierbare Vorhersagen

Diese Linsen sind kein Füllstoff. Verwende sie, wenn sie eine übersehene Erklärung, versteckte Abhängigkeit oder schwache Schlussfolgerung aufdecken können.

Worker-Vertrag

Jeder Worker sollte ein tracer-Lane-Besitzer sein, kein generischer Ausführer.

Jeder Worker muss:

• genau eine Hypothesen-Lane besitzen
• seine Lane-Hypothese explizit neu formulieren
• Evidenzen für die Lane sammeln
• Evidenzen gegen die Lane sammeln
• die Evidenzstärke hinter seinem Fall bewerten
• auf fehlende Evidenzen, fehlgeschlagene Vorhersagen und verbleibende Unsicherheit hinweisen
• die kritische Unbekannte für die Lane benennen
• die beste Lane-spezifische diskriminierende Sonde empfehlen
• vermeiden, in Implementierung zu verfallen, es sei denn, es wurde explizit dazu aufgefordert

Nützliche Evidenzquellen sind:

• relevanter Code, Tests, Konfigurationen, Dokumentationen, Logs, Ausgaben und Benchmark-Artefakte
• vorhandene Trace-Artefakte über trace_timeline
• vorhandene aggregierte Trace-Evidenzen über trace_summary

Empfohlene Worker-Rückgabestruktur:

1. Lane
2. Hypothese
3. Evidenzen dafür
4. Evidenzen dagegen / Lücken
5. Evidenzstärke
6. Kritische Unbekannte
7. Beste diskriminierende Sonde
8. Vertrauen

Leader-Synthese-Vertrag

Die endgültige /trace-Antwort sollte synthetisieren, nicht nur aneinanderreihen.

Zurückgeben:

1. Beobachtetes Ergebnis
2. Rangliste der Hypothesen
3. Evidenzzusammenfassung nach Hypothese
4. Evidenzen dagegen / fehlende Evidenzen
5. Widerlegungsrunde
6. Konvergenz-/Trennungsnotizen
7. Wahrscheinlichste Erklärung
8. Kritische Unbekannte
9. Empfohlende diskriminierende Sonde
10. Zusätzliche Trace-Lanes (optional, nur wenn die Unsicherheit hoch bleibt)

Behalte eine Ranglisten-Kurzauswahl bei, auch wenn eine Erklärung derzeit dominant ist.

Widerlegungsrunde und Konvergenzerkennung

Bevor du den Trace abschließt:

• lass die stärkste nicht führende Lane ihre beste Widerlegung gegen den aktuellen Führenden präsentieren
• zwinge den Führenden, die Widerlegung mit Evidenzen, nicht mit Behauptungen zu beantworten
• wenn die Widerlegung den Führenden materiell schwächt, bewerte die Tabelle neu
• wenn zwei „unterschiedliche“ Hypothesen auf denselben zugrundeliegenden Mechanismus reduziert werden, führe sie zusammen und sage dies explizit
• wenn zwei Hypothesen immer noch unterschiedliche nächste Sonden implizieren, behalte sie getrennt, auch wenn sie ähnlich klingen

Behaupte keine Konvergenz, nur weil mehrere Worker ähnliche Sprache verwenden. Konvergenz erfordert entweder:

• denselben kausalen Grundmechanismus, oder
• unabhängige Evidenzströme, die auf dieselbe Erklärung hinweisen

Explizite Herabstufungsanleitung

Der Lead sollte explizit sagen, warum eine Hypothese herabgestuft wurde:

• durch stärkere Evidenzen widerlegt
• die von ihr vorhergesagte Beobachtung fehlt
• erfordert zusätzliche Ad-hoc-Annahmen
• erklärt weniger Fakten als der Führende
• hat die Widerlegungsrunde verloren
• in eine stärkere übergeordnete Erklärung konvergiert

Dies ist wichtig, weil /trace dem Leser vermitteln sollte, warum eine Erklärung eine andere übertrifft, nicht nur eine endgültige Tabelle präsentieren.

Vorgeschlagenes Lead-Prompt-Skelett

Verwende einen teamorientierten Orchestrierungs-Prompt nach diesem Muster:

1. „Formuliere die Beobachtung genau neu.“
2. „Generiere 3 bewusst unterschiedliche Hypothesen.“
3. „Erstelle eine Tracer-Lane pro Hypothese mit dem Claude-eigenen Team-Modus.“
4. „Sammle für jede Lane Evidenzen für und gegen, bewerte die Evidenzstärke und nenne die kritische Unbekannte plus die beste diskriminierende Sonde.“
5. „Wende bei Bedarf System-, Prä-Mortem- und Wissenschaftslinsen auf die Führenden an.“
6. „Führe eine Widerlegungsrunde zwischen den beiden Top-Erklärungen durch.“
7. „Gib eine Ranglisten-Erklärungstabelle, Konvergenznotizen, die kritische Unbekannte und die einzige beste diskriminierende Sonde zurück.“

Ausgabequalitätsniveau

Gute /trace-Ausgabe ist:

• evidenzgestützt
• prägnant, aber gründlich
• skeptisch gegenüber voreiliger Sicherheit
• explizit über fehlende Evidenzen
• praktisch in Bezug auf die nächste Aktion
• explizit darüber, warum schwächere Erklärungen herabgestuft wurden

Beispielhafte endgültige Syntheseform

Beobachtetes Ergebnis

[Was passiert ist]

Rangliste der Hypothesen

Rang	Hypothese	Vertrauen	Evidenzstärke	Warum sie führt
1	...	Hoch / Mittel / Niedrig	Stark / Mittel / Schwach	...

Evidenzzusammenfassung nach Hypothese

• Hypothese 1: ...
• Hypothese 2: ...
• Hypothese 3: ...

Evidenzen dagegen / fehlende Evidenzen

• Hypothese 1: ...
• Hypothese 2: ...
• Hypothese 3: ...

Widerlegungsrunde

• Beste Widerlegung gegen den Führenden: ...
• Warum der Führende gehalten / versagt hat: ...

Konvergenz-/Trennungsnotizen

• ...

Wahrscheinlichste Erklärung

[Aktuell beste Erklärung]

Kritische Unbekannte

[Einzelne fehlende Tatsache, die Unsicherheit offen hält]

Empfohlende diskriminierende Sonde

[Einzelne nächste Sonde]

Zusätzliche Trace-Lanes

[Nur wenn die Unsicherheit hoch bleibt]