Brians-brain/claude-skills

Die Kommunikation mit dem Benutzer sowie der Bericht erfolgen in traditionellem Chinesisch.

Führe eine zweiachsige Überprüfung des Diffs zwischen HEAD und dem vom Benutzer angegebenen Fixpunkt durch:

• Standards: Hält der Code die dokumentierten Schreibkonventionen dieses Repositorys ein?
• Spezifikation: Setzt der Code das ursprüngliche Issue/die ursprüngliche Spezifikation korrekt um?

Beide Achsen werden mit parallelen Unter-Agents ausgeführt, damit sie sich gegenseitig nicht beeinflussen. Anschließend fasst dieser Skill ihre Erkenntnisse zusammen.

Der Issue-Tracker sollte bereits zur Verfügung stehen. Wenn nicht, teile dem Benutzer mit, dass er zuerst /setup-matt-pocock-skills ausführen soll.

Ablauf

1. Fixpunkt bestimmen

Der Benutzer gibt den Fixpunkt an (Commit-SHA, Branchname, Tag, main, HEAD~5 usw.). Wenn er keinen angibt, frage nach.

Halte den Diff-Befehl fest: git diff <fixed-point>...HEAD (Drei Punkte, also Vergleich mit der Merge-Basis). Notiere gleichzeitig die Commit-Liste mit git log <fixed-point>..HEAD --oneline.

Stelle vor dem Fortfahren sicher, dass der Fixpunkt aufgelöst werden kann (git rev-parse <fixed-point>) und der Diff nicht leer ist. Fehlerhafte Referenzen oder ein leerer Diff sollten hier fehlschlagen, nicht in den beiden parallelen Unter-Agents.

2. Spec-Quelle finden

Suche in folgender Reihenfolge nach der ursprünglichen Spezifikation:

1. Issue-Referenzen in Commit-Nachrichten (#123, Closes #45, GitLab !67 usw.), über den im Tracker-Dokument beschriebenen Ablauf.
2. Einen vom Benutzer als Parameter übergebenen Pfad.
3. Eine Spec-Datei in docs/, specs/ oder .scratch/, die zum Branchnamen oder Feature passt.
4. Wenn nichts gefunden wird, frage den Benutzer, wo die Spezifikation ist. Sagt er, es gibt keine, überspringt der Spec-Unter-Agent und meldet „Keine Spezifikation verfügbar“.

3. Standards-Quelle finden

Durchsuche das Repository nach allen Dateien, die Regeln für die Code-Gestaltung enthalten. Wenn CODING_STANDARDS.md oder CONTRIBUTING.md existieren, müssen diese unbedingt einbezogen werden. Bei Python-Projekten beachte auch die Konfiguration von Lintern/Formatern (ruff, black, mypy usw.) in pyproject.toml, aber überspringe Regeln, die bereits durch die Tools erzwungen werden.

Zusätzlich zu den im Repository dokumentierten Inhalten führt die Standards-Achse stets den untenstehenden Basis-Set von Code-Smells mit: eine feste Menge von Fowlers Code-Smells (Kapitel 3 von „Refactoring“), die auch dann gelten, wenn das Repository nichts dokumentiert hat. Zwei Regeln schränken ein:

• Repository vorrangig. Die dokumentierten Konventionen des Repositorys haben immer Vorrang; wenn sie etwas billigen, das der Basis-Set markieren würde, dann markiere diesen Code-Smell nicht.
• Immer Beurteilungssache. Jeder Code-Smell ist eine mit einem Label versehene Faustregel („Könnte Feature Envy sein“), niemals eine harte Verletzung. Überspringe wie bei allen anderen Regeln hier, was bereits durch Tools erzwungen wird.

Jeder Code-Smell ist formuliert als „Was es ist → Wie man es behebt“; lege ihn gegen den Diff:

• Mysteriöser Name (Mysterious Name): Der Name einer Funktion, Variable oder eines Typs verrät nicht, was sie/es tut oder enthält. → Umbenennen; wenn kein ehrlicher Name einfällt, ist das Design selbst vage.
• Doppelter Code (Duplicated Code): Dieselbe logische Form tritt in mehr als einem Block oder einer Datei dieser Änderung auf. → Extrahiere die gemeinsame Form und rufe sie von beiden Seiten auf.
• Feature Envy: Eine Methode greift mehr auf Daten eines anderen Objekts zu als auf eigene. → Verschiebe die Methode zu den Daten, die sie begehrt.
• Datenklumpen (Data Clumps): Dieselben Felder oder Parameter treten immer gemeinsam auf (ein Typ, der geboren werden will). → Verpacke sie in einen Typ und übergib diesen.
• Primitive Obsession: Ein primitiver Typ oder String repräsentiert ein Domänenkonzept, das einen eigenen Typ verdient (z. B. str für eine Teilenummer, float für Betrag und Währung). → Gib diesem Konzept einen eigenen kleinen Typ (z. B. dataclass).
• Wiederholte Bedingungen (Repeated Switches): Dieselbe match-/if-Kette für denselben Typ taucht in dieser Änderung mehrfach auf. → Verwende Polymorphismus oder eine von beiden Stellen gemeinsam genutzte Nachschlagetabelle.
• Schrotschuss-Operation (Shotgun Surgery): Eine logische Änderung zwingt zu verstreuten Anpassungen in vielen Dateien des Diffs. → Konzentriere Dinge, die sich gemeinsam ändern, in einem Modul.
• Divergenter Wandel (Divergent Change): Eine Datei oder ein Modul wird aus mehreren unabhängigen Gründen geändert. → Trenne es, sodass jedes Modul sich nur aus einem Grund ändert.
• Spekulative Allgemeinheit (Speculative Generality): Abstraktionen, Parameter oder Hooks, die für nicht spezifizierte Anforderungen hinzugefügt wurden. → Lösche sie; inline zurück, bis echte Anforderungen auftauchen.
• Nachrichtenketten (Message Chains): Lange a.b().c().d()-Navigation, die der Aufrufer nicht vornehmen sollte. → Verstecke den Durchlauf hinter einer Methode des ersten Objekts.
• Mittelsmann (Middle Man): Eine Klasse oder Funktion, die hauptsächlich nur delegiert. → Entferne sie und rufe das eigentliche Ziel direkt auf.
• Verweigertes Vermächtnis (Refused Bequest): Eine Unterklasse oder ein Implementierer ignoriert oder überschreibt den Großteil dessen, was sie/er erbt. → Gib Vererbung auf, verwende Komposition.

4. Parallele Ausgabe der zwei Unter-Agents

Gib gleichzeitig zwei Unter-Agent-Aufrufe aus (im Vordergrund) und fasse die zurückgegebenen Berichte zusammen.

Prompt für den Standards-Unter-Agent sollte enthalten:

• Den vollständigen Diff-Befehl und die Commit-Liste.
• Die Liste der in Schritt 3 gefundenen Quellen für Standards, plus den vollständigen Basis-Set von Code-Smells aus Schritt 3 (der Unter-Agent hat keinen anderen Weg, ihn zu erhalten).
• Aufgabenbeschreibung: „Berichte in traditionellem Chinesisch und kennzeichne Datei/Block an relevanter Stelle: (a) Jede Stelle, an der der Diff gegen dokumentierte Konventionen verstößt: zitiere die Konvention (Datei + Regel); und (b) jeden von dir gefundenen Basis-Code-Smell: nenne den Namen und verweise auf den Block. Unterscheide harte Verstöße von Beurteilungssachen: Verstöße gegen dokumentierte Konventionen können hart sein, aber Basis-Code-Smells sind immer Beurteilungssache, und dokumentierte Konventionen des Repositorys haben Vorrang vor dem Basis-Set. Überspringe, was bereits durch Tools erzwungen wird. Maximal 400 Wörter.“

Prompt für den Spec-Unter-Agent sollte enthalten:

• Den Diff-Befehl und die Commit-Liste.
• Den Pfad zur Spezifikation oder den bereits abgerufenen Inhalt.
• Aufgabenbeschreibung: „Berichte in traditionellem Chinesisch: (a) Anforderungen, die die Spezifikation verlangt, die aber fehlen oder nur teilweise umgesetzt wurden; (b) Verhalten im Diff, das nicht angefordert wurde (Scope Creep); (c) Anforderungen, die zwar implementiert zu sein scheinen, aber falsch umgesetzt wurden. Verweise bei jedem Befund auf den entsprechenden Text der Spezifikation. Maximal 400 Wörter.“

Wenn keine Spezifikation vorhanden ist, überspringe den Spec-Unter-Agent und vermerke dies im endgültigen Bericht.

5. Zusammenführung

Setze die beiden Berichte unter die Überschriften ## Standards und ## Spec, entweder originalgetreu oder leicht redigiert. Fasse die Befunde nicht zusammen und sortiere sie nicht neu, da die beiden Achsen bewusst getrennt sind (siehe „Warum zwei Achsen“).

Fasse abschließend in einer Zeile zusammen: die Gesamtzahl der Befunde pro Achse sowie das schwerwiegendste Problem innerhalb jeder Achse (falls vorhanden). Wähle nicht achsenübergreifend einen einzelnen Gewinner: Genau das soll die Trennung der Achsen verhindern.

Warum zwei Achsen

Eine Änderung kann die eine Achse bestehen, die andere aber nicht:

• Hält alle Standards ein, implementiert aber das Falsche → Standards bestanden, Spec nicht bestanden.
• Setzt exakt das um, was das Issue verlangt, verletzt aber die Projektkonventionen → Spec bestanden, Standards nicht bestanden.

Die getrennte Berichterstattung verhindert, dass eine Achse die andere überdeckt.