Zwei-Achsen-Überprüfung des Diffs zwischen HEAD und einem vom Benutzer angegebenen Fixpunkt:
- Standards – entspricht der Code den dokumentierten Codierungsstandards des Repos?
- Spezifikation – setzt der Code das ursprüngliche Issue / PRD / die Spezifikation korrekt um?
Beide Achsen laufen als parallele Sub-Agenten, um sich gegenseitig nicht zu beeinflussen, danach fasst diese Fähigkeit ihre Ergebnisse zusammen.
Der Issue-Tracker sollte dir zur Verfügung gestellt worden sein – führe /setup-matt-pocock-skills aus, falls docs/agents/issue-tracker.md fehlt.
Ablauf
1. Fixpunkt festlegen
Was auch immer der Benutzer als Fixpunkt angibt – einen Commit-SHA, Branch-Namen, Tag, main, HEAD~5 usw. Wenn er keinen angibt, frage danach.
Erfasse den Diff-Befehl einmal: git diff <fixpunkt>...HEAD (Drei-Punkte, sodass der Vergleich gegen die Merge-Base erfolgt). Notiere auch die Liste der Commits über git log <fixpunkt>..HEAD --oneline.
Bevor du fortfährst, bestätige, dass der Fixpunkt aufgelöst werden kann (git rev-parse <fixpunkt>) und der Diff nicht leer ist. Ein ungültiger Ref oder ein leerer Diff sollten hier scheitern – nicht innerhalb der beiden parallelen Sub-Agenten.
2. Spezifikationsquelle identifizieren
Suche nach der ursprünglichen Spezifikation, in dieser Reihenfolge:
- Issue-Referenzen in den Commit-Nachrichten (
#123,Closes #45, GitLab!67usw.) – rufe sie über den Workflow indocs/agents/issue-tracker.mdab. - Ein vom Benutzer als Argument übergebener Pfad.
- Eine PRD/Spezifikationsdatei unter
docs/,specs/oder.scratch/, die dem Branch-Namen oder Feature entspricht. - Wenn nichts gefunden wird, frage den Benutzer, wo die Spezifikation ist. Sagt er, es gibt keine, überspringt der Spec-Sub-Agent und meldet „keine Spezifikation verfügbar".
3. Standards-Quellen identifizieren
Alles im Repo, das dokumentiert, wie Code geschrieben sein sollte, wie z. B. CODING_STANDARDS.md oder CONTRIBUTING.md.
4. Beide Sub-Agenten parallel starten
Sende eine einzelne Nachricht mit zwei Agent-Tool-Aufrufen. Verwende den general-purpose-Subagenten für beide.
Standards-Sub-Agent-Prompt – füge hinzu:
- Den vollständigen Diff-Befehl und die Commit-Liste.
- Die Liste der in Schritt 3 gefundenen Standards-Quelldateien.
- Die Aufgabenstellung: „Bericht – pro Datei/Hunk, wo relevant – jede Stelle, an der der Diff eine dokumentierte Regel verletzt. Zitiere die Regel (Datei + Regeltext). Unterscheide harte Verstöße von Ermessensentscheidungen. Überspringe Regelungen, die durch Tooling durchgesetzt werden. Unter 400 Wörtern."
Spec-Sub-Agent-Prompt – füge hinzu:
- Den Diff-Befehl und die Commit-Liste.
- Den Pfad oder den abgerufenen Inhalt der Spezifikation.
- Die Aufgabenstellung: „Bericht: (a) Anforderungen, die die Spezifikation verlangt hat, aber fehlen oder unvollständig sind; (b) Verhalten im Diff, das nicht verlangt wurde (Scope Creep); (c) Anforderungen, die umgesetzt aussehen, aber die Umsetzung falsch wirkt. Zitiere die Spezifikationszeile für jeden Befund. Unter 400 Wörtern."
Wenn die Spezifikation fehlt, überspringe den Spec-Sub-Agenten und vermerke dies im Abschlussbericht.
5. Zusammenführen
Präsentiere die beiden Berichte unter den Überschriften ## Standards und ## Spec, wörtlich oder leicht bereinigt. Fasse die Befunde nicht zusammen oder bewerte sie neu – die beiden Achsen sind bewusst getrennt (siehe Warum zwei Achsen).
Ende mit einer einzeiligen Zusammenfassung: Gesamtzahl der Befunde pro Achse und das schwerwiegendste Problem innerhalb jeder Achse (falls vorhanden). Wähle keinen einzelnen Gewinner über die Achsen hinweg – das ist die Neubewertung, die die Trennung verhindern soll.
Warum zwei Achsen
Eine Änderung kann die eine Achse bestehen und die andere nicht bestehen:
- Code, der jedem Standard folgt, aber das Falsche implementiert → Standards bestanden, Spezifikation nicht bestanden.
- Code, der genau das tut, was das Issue verlangt, aber die Projektkonventionen bricht → Spezifikation bestanden, Standards nicht bestanden.
Die getrennte Berichterstattung verhindert, dass eine Achse die andere überdeckt.