xieshuai0817-hub/LanceSkill

Zweiachsige Überprüfung des Diffs zwischen HEAD und einem vom Benutzer angegebenen festgelegten Punkt:

• Standards – entspricht der Code den dokumentierten Codierungsstandards dieses Repos?
• Spec – setzt der Code das ursprüngliche Issue / PRD / Spezifikation korrekt um?

Beide Achsen laufen als parallele Sub-Agenten, damit sie sich nicht gegenseitig im Kontext stören. Anschließend fasst diese Fähigkeit ihre Ergebnisse zusammen.

Der Issue-Tracker sollte bereitgestellt worden sein – führe /setup-matt-pocock-skills aus, falls docs/agents/issue-tracker.md fehlt.

Ablauf

1. Festlegung des Bezugspunkts

Was auch immer der Benutzer als festgelegten Punkt angegeben hat – ein Commit-SHA, Branchname, Tag, main, HEAD~5 usw. Falls kein Punkt genannt wurde, frage danach.

Erfasse den Diff-Befehl einmal: git diff <festgelegter-punkt>...HEAD (Drei-Punkte, sodass der Vergleich gegen die Merge-Base erfolgt). Notiere auch die Liste der Commits über git log <festgelegter-punkt>..HEAD --oneline.

Bevor du weitermachst, bestätige, dass der festgelegte Punkt aufgelöst werden kann (git rev-parse <festgelegter-punkt>) und der Diff nicht leer ist. Ein ungültiger Ref oder leerer Diff sollte hier scheitern – nicht innerhalb der beiden parallelen Sub-Agenten.

2. Identifiziere die Spezifikationsquelle

Suche nach der ursprünglichen Spezifikation in dieser Reihenfolge:

1. Issue-Referenzen in den Commit-Nachrichten (#123, Closes #45, GitLab !67 usw.) – rufe diese über den Workflow in docs/agents/issue-tracker.md ab.
2. Ein Pfad, den der Benutzer als Argument übergeben hat.
3. Eine PRD-/Spezifikationsdatei unter docs/, specs/ oder .scratch/, die dem Branchnamen oder Feature entspricht.
4. Falls nichts gefunden wird, frage den Benutzer, wo die Spezifikation ist. Sagt der Benutzer, dass es keine gibt, überspringt der Spec-Sub-Agent und meldet „keine Spezifikation verfügbar“.

3. Identifiziere die Standards-Quellen

Alles im Repo, das dokumentiert, wie Code geschrieben werden soll, z. B. CODING_STANDARDS.md oder CONTRIBUTING.md.

Zusätzlich zu dem, was das Repo dokumentiert, führt die Standards-Achse immer die folgende Basisliste von Code-Gerüchen mit – eine feste Menge von Fowler-Code-Gerüchen (Refactoring, Kap. 3), die auch dann gilt, wenn das Repo nichts dokumentiert. Zwei Regeln binden sie:

• Das Repo überschreibt. Ein dokumentierter Repo-Standard hat immer Vorrang; wo er etwas befürwortet, das die Basisliste beanstanden würde, unterdrücke den Geruch.
• Immer eine Ermessensentscheidung. Jeder Geruch ist eine beschriftete Heuristik („mögliche Feature Envy“), nie eine harte Verletzung – und wie bei jedem Standard hier: überspringe alles, was Werkzeuge ohnehin durchsetzen.

Jeder Geruch beschreibt was es ist → wie zu beheben; gleiche ihn mit dem Diff ab:

• Mysterious Name – eine Funktion, Variable oder ein Typ, dessen Name nicht verrät, was es tut oder enthält. → umbenennen; wenn kein ehrlicher Name einfällt, ist das Design fragwürdig.
• Duplicated Code – dieselbe Logikstruktur erscheint in mehr als einem Hunk oder mehreren Dateien innerhalb der Änderung. → die gemeinsame Struktur extrahieren, von beiden Stellen aufrufen.
• Feature Envy – eine Methode, die häufiger auf Daten eines anderen Objekts zugreift als auf eigene. → die Methode auf das Objekt verschieben, das sie beneidet.
• Data Clumps – dieselben wenigen Felder oder Parameter treten immer zusammen auf (ein Typ, der geboren werden will). → sie in einen Typ bündeln, diesen übergeben.
• Primitive Obsession – ein primitiver Typ oder String steht für ein Fachkonzept, das einen eigenen Typ verdient. → dem Konzept einen eigenen kleinen Typ geben.
• Repeated Switches – dasselbe switch/if-Konstrukt über denselben Typ taucht innerhalb der Änderung mehrfach auf. → durch Polymorphie ersetzen, oder eine Map, die beide Stellen gemeinsam nutzen.
• Shotgun Surgery – eine logische Änderung zwingt zu verstreuten Anpassungen in vielen Dateien im Diff. → die zusammengehörigen Änderungen in ein Modul sammeln.
• Divergent Change – eine Datei oder ein Modul wird aus mehreren, nicht zusammenhängenden Gründen bearbeitet. → aufteilen, sodass jedes Modul aus einem Grund geändert wird.
• Speculative Generality – Abstraktion, Parameter oder Hooks für Anforderungen, die die Spezifikation nicht vorsieht. → löschen; zurück inlinieren, bis ein echter Bedarf entsteht.
• Message Chains – lange a.b().c().d()-Navigation, von der der Aufrufer nicht abhängen sollte. → den Durchlauf hinter einer Methode des ersten Objekts verstecken.
• Middle Man – eine Klasse oder Funktion, die meist nur delegiert. → sie entfernen, direkt das eigentliche Ziel aufrufen.
• Refused Bequest – eine Unterklasse oder Implementierung, die den Großteil des Geerbten ignoriert oder überschreibt. → die Vererbung aufgeben, Komposition verwenden.

4. Starte beide Sub-Agenten parallel

Sende eine einzige Nachricht mit zwei Agent-Werkzeugaufrufen. Verwende für beide den general-purpose-Subagent.

Standards-Sub-Agent-Anweisung – füge hinzu:

• Den vollständigen Diff-Befehl und die Commit-Liste.
• Die Liste der in Schritt 3 gefundenen Standard-Quelldateien, plus die Basisliste von Gerüchen aus Schritt 3 vollständig eingefügt – der Sub-Agent hat keinen anderen Zugriff darauf.
• Die Anweisung: „Berichte – pro Datei/Hunk, wo relevant – (a) jede Stelle, an der der Diff einen dokumentierten Standard verletzt: zitiere den Standard (Datei + Regel); und (b) jeden Basis-Geruch, den du siehst: benenne ihn und zitiere den Hunk. Unterscheide harte Verletzungen von Ermessensentscheidungen – Verstöße gegen dokumentierte Standards können hart sein, Basis-Gerüche sind jedoch immer Ermessensentscheidungen, und ein dokumentierter Repo-Standard überschreibt die Basis. Überspringe alles, was Werkzeuge ohnehin durchsetzen. Unter 400 Wörtern.“

Spec-Sub-Agent-Anweisung – füge hinzu:

• Den Diff-Befehl und die Commit-Liste.
• Den Pfad oder die abgerufenen Inhalte der Spezifikation.
• Die Anweisung: „Berichte: (a) Anforderungen der Spezifikation, die fehlen oder unvollständig sind; (b) Verhalten im Diff, das nicht gefordert war (Scope Creep); (c) Anforderungen, die implementiert aussehen, aber die Implementierung falsch wirkt. Zitiere für jeden Befund die Spezifikationszeile. Unter 400 Wörtern.“

Falls 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 Ergebnisse nicht zusammen oder bewerte sie neu – die beiden Achsen sind bewusst getrennt (siehe Warum zwei Achsen).

Beende mit einer einzeiligen Zusammenfassung: Gesamtanzahl 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 eine Achse bestehen und an der anderen scheitern:

• Code, der jedem Standard folgt, aber das Falsche implementiert → Standards bestanden, Spec nicht bestanden.
• Code, der exakt das tut, was das Issue verlangt, aber die Projektkonventionen bricht → Spec bestanden, Standards nicht bestanden.

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