systematic-debugging (obra/superpowers)

Bewertung

Codex CLI 0.166 (gpt-6-astra, niedriges Reasoning) auf einem Mac-Testrechner, einem frischen temporären Projekt und temporären HOME/TMPDIR/Caches pro Lauf; Skill installiert (Treatment) oder nicht vorhanden (Kontrolle) oder nicht vorhanden mit der Kernanforderung des Skills in einem an den Prompt angehängten Satz (One-Liner-Gruppe); 2 Läufe pro Gruppe und Aufgabe; Netzwerk aus; Schreiben nach /tmp blockiert. Die Prompts nennen den Skill nie (außer der unten genannten Formulierung). Die Prompts nennen den Skill nie. Die Bewertung ist programmatisch (versteckte Tests / Trefferquote eingebauter Probleme / Constraint-Prüfungen / Rendern+OCR wo relevant), 0–5 pro Lauf. Keine Punktzahl wurde von einem LLM-Richter vergeben.

Drei-Arm-Vergleich

Gemessen mit Codex CLI über 18 Läufe, bewertet durch regelbasierte Prüfungen ohne LLM-Richter. Gesamt 22.4 / 30, Urteil Situativ.

Urteil: Situationsabhängig (22.4 / 30). Quelle: obra/superpowers, skills/systematic-debugging, festgeschrieben auf Commit 2ce8aa1. Installation: npx skills@latest add obra/superpowers --skill systematic-debugging. Lizenz: MIT (LICENSE im Repo).

Was es ist

Der Skill systematic-debugging aus obra/superpowers: „Verwenden bei jedem Bug, Testfehler oder unerwarteten Verhalten, bevor Fixes vorgeschlagen werden“. Vier Phasen (Ursache untersuchen, Muster finden, Hypothese, Fix), eine Regel gegen das Stapeln von Fixes und Begleitnotizen (Ursachenverfolgung, Defense in Depth, bedingungsbasiertes Warten) plus Szenarien unter Testdruck sowie ein Shell-Skript (find-polluter.sh, eine lokale Bisektion über Testdateien).

Wie wir getestet haben

Codex CLI 0.166 (gpt-6-astra, niedriges Reasoning) auf einem Mac-Testgerät, pro Lauf ein frisches temporäres Projekt sowie temporäre HOME/TMPDIR/Caches, Skill installiert (Treatment) oder nicht vorhanden (Kontrolle) oder nicht vorhanden mit der Kernanforderung des Skills als einem an den Prompt angehängten Satz (Ein-Satz-Gruppe), 2 Läufe pro Gruppe und Aufgabe, Netzwerk aus, Schreibzugriffe auf /tmp blockiert. Die Prompts nennen den Skill nie.

1. Off-by-one in einer kleinen Funktion — moving_average in movavg.py liefert falsche Zahlen: moving_average([2, 4, 6, 8, 10], 3) sollte [2, 3, 4, 6, 8] sein, aber die späteren Werte kommen falsch heraus. Finde die Ursache und behebe sie. Tests: python3 -m unittest.
2. Dateiübergreifender Datumsfehler — Unsere Wochenbericht-Kopfzeilen zeigen um den Jahreswechsel falsche Daten, z. B. sollte header('2026-W01') „Week 2026-W01: Dec 29 - Jan 04, 2026“ sein. Finde die Ursache und behebe sie.
3. Reihenfolgeabhängiger Testfehler — Die Tests in tests/test_settings.py laufen einzeln durch, aber test_b schlägt fehl, wenn die ganze Datei läuft, und Konfigurationen scheinen Tags aus früheren Aufrufen mitzunehmen. Diagnostiziere und behebe das.

Die Bewertung erfolgt programmatisch (versteckte Tests / Erkennung eingepflanzter Fehler / Constraint-Checks / Rendering+OCR, wo relevant), 0–5 pro Lauf. Kein LLM-Judge hat eine Bewertung entschieden.

Ergebnisse

Der Ein-Satz-Prompt für die dritte Gruppe: "Debugge systematisch: Reproduziere zuerst den Fehler, untersuche die Ursache und bilde mit Belegen jeweils eine Hypothese, bevor du Code änderst, mache den kleinsten Fix für die Ursache (keine gestapelten Vermutungen) und verifiziere mit den Tests."

Durchschnittswert: 4.45 ohne vs. 4.45 mit dem Skill (Delta +0.0). Token pro Lauf: 75k vs. 99k (1.33x); Zeit 34s vs. 45s. Ein-Satz-Gruppe: 4.86 (Gewinn des Skills gegenüber dem Ein-Satz-Prompt: -0.42; Gewinn des Ein-Satz-Prompts gegenüber ohne Skill: +0.42); Ein-Satz-Token 98k pro Lauf, der Skill kostet also 1.01x so viel wie der Ein-Satz-Prompt.

Was passiert ist

• Ergebnis: Die versteckten Tests liefen in jedem Lauf beider Gruppen durch, die Korrektheit unterschied sich also nicht.
• Prozessprüfung „die Tests vor dem Ändern des Codes ausgeführt“ (zuerst reproduzieren): Die Kontrolle verfehlte ihn in 4/6 Läufen, das Treatment in 4/6 Läufen. Die erste Phase des Skills heißt „reproduzieren“, aber die Agenten mit dem Skill änderten den Code trotzdem oft, bevor sie etwas ausführten.
• Der Skill wurde in 6/6 Treatment-Läufen gelesen, die Auslösung ist also nicht das Problem; er änderte das Verhalten bei diesen kleinen Bugs schlicht nicht (die Bugs waren durch Lesen des Codes zu finden).
• Kosten: etwa 1.3x Token pro Lauf (89k vs. 67k).
• Ein-Satz-Version (zuerst reproduzieren, jeweils eine Hypothese, kleinster Fix, verifizieren): Durchschnitt 4.86 gegenüber 4.45 für die Kontrolle und 4.45 für den Skill, bei 98k Token pro Lauf gegenüber 75k (1.3x) und 99k für den Skill (1.0x).
• Der Unterschied liegt im Ausführen der Tests vor dem Ändern: 5 von 6 Ein-Satz-Läufen taten das, gegenüber 2 von 6 Kontroll-Läufen und 2 von 6 Skill-Läufen. Der Skill änderte dieses Verhalten nicht; der Satz, der es benennt, schon. Jede Gruppe erklärte in allen Läufen die Ursache und bestand jeden versteckten Test, mit kleinen Diffs.

Dimensionswerte

Grenzen dieses Tests

• Drei kleine eingepflanzte Bugs (Off-by-one, dateiübergreifende Datumslogik, reihenfolgeabhängige Testverschmutzung) — alle einfach genug, dass die Baseline sie behebt.
• Der Skill ist für schwierige Bugs mit mehreren Versuchen gedacht; solche haben wir nicht getestet.
• find-polluter.sh wurde nicht ausprobiert.
• n = 2 pro Gruppe und Aufgabe: Abweichungen unter etwa 1 Punkt sind Rauschen.
• Regelbasierte Bewertung misst, was die Checks sehen können; sie kann weder Geschmack beurteilen noch, ob ein Ergebnis das bestmögliche ist.

Sicherheit

Siehe security.md. Scan: 0 CRITICAL / 0 HIGH / 0 MEDIUM. Urteil: sicher ausführbar (Sandbox ohne Netzwerk). Ein sauberer Scan beweist nicht, dass ein Skill sicher ist.

Fazit

Bei drei kleinen Bugs kostete der Skill etwa 1.3x Token und brachte keine messbare Änderung: Kontrolle und Skill erreichten beide 4.45 und führten beide nur in 2 von 6 Läufen die Tests vor dem Ändern aus. Die Ein-Satz-Version mit „zuerst reproduzieren“ war besser (4.86, 5 von 6). Bei schwierigeren Bugs könnte er sich auszahlen — die haben wir nicht getestet.