Da wir Claude zunehmend anspruchsvollere Aufgaben übertragen, wird es immer wichtiger, dass er seine eigene Arbeit überprüfen kann.
Je mehr Claude sich selbst überprüfen kann:
- desto eigenständiger kann er an langlaufenden Aufgaben arbeiten
- desto besser ist die Qualität des Endergebnisses
- desto weniger Hin und Her ist nötig, um ans Ziel zu kommen
Wenn die Überprüfungen von dir abhängen, werden Coding-Sessions zu einem rundenbasierten Spiel, und das geht verloren, was Agents nützlich macht: Autonomie.
Die gute Nachricht: Claude überprüft sich bereits selbst anhand deterministischer Signale wie Typfehler, Lint-Fehler, fehlschlagende Tests und Laufzeitfehler. Und mit besseren Modellen wird das nur noch besser.
Was Claude nicht immer ableiten kann, sind die manuellen Checks, die du nach seiner Antwort durchführst – und später, bevor du Code in die Produktion einspielst.
Je mehr dieser Checks du kodifizieren kannst, desto näher kommt Claudes erste Antwort an das Endergebnis, das du im Kopf hattest.
Du verbringst weniger Zeit mit Beaufsichtigen, und Claude kann weiterarbeiten, während du an etwas anderem arbeitest.
Schreibe deine Prozesse auf
Ein guter Anfang ist, die Best-Practices-Version dessen aufzuschreiben, was du oder dein Team bereits tun.
Für das Frontend sind das normalerweise: Dev-Server starten, Browser öffnen, Konsole auf Fehler prüfen, wie ein Benutzer durchklicken und auf Dinge wie Layout-Verschiebungen oder langsame Navigationen achten.
Jede Domäne hat ihre eigene Version. Für jeden dieser Schritte gibt es wahrscheinlich ein Tool, das Claude zur Überprüfung nutzen kann:
Kodifiziere deinen Prozess als Fähigkeit (Skill)
Sobald der Prozess klar ist, kodifiziere so viel wie möglich davon als Skill. Installiere das Plugin \skill-creator\ und bitte Claude, dich zu interviewen:
1/skill-creator Erstelle einen Skill zur End-to-End-Überprüfung von Frontend-Änderungen. Frage mich zu meinem Arbeitsablauf aus.
Wenn du Schwierigkeiten hast, deinen Prozess in Worte zu fassen, bitte Claude zuerst um die Best Practices der Domäne und lass dir zeigen, wie ein End-to-End-Prüfablauf aussehen könnte.
Geschmack und Urteilsvermögen sind schwer zu kodifizieren, aber viele Checks haben Kriterien, an denen Claude messen kann: ein Performance-Budget, eine Barrierefreiheits-Checkliste, Design-System-Regeln, gute vs. schlechte Beispiele.
Ein Frontend-Skill könnte zum Beispiel Anweisungen enthalten, einen Performance-Trace über das Chrome DevTools MCP oder den Agent browser zu erfassen.
1---2name: frontend-verify3description: Überprüfe Frontend-Änderungen in einem Browser. Führe diesen Skill immer dann aus, wenn eine UI-Änderung (Seite, Komponente, Typografie, CSS-Stil) vorgenommen wurde.4---56# Frontend-Überprüfung78- Führe eine zweistufige Überprüfung in einem echten Browser durch.9- Behebe Probleme und überprüfe erneut, bevor du dem Benutzer antwortest.1011## Schritt 1 – Überprüfe, ob die Änderung wie erwartet funktioniert12131. Öffne die URL in einem Browser:14 - In der Claude Code Desktop-App verwende die eingebettete Vorschau.15 - In der CLI verwende das Chrome DevTools MCP.162. Interagiere mit dem neuen Element und bestätige, dass es wie erwartet gerendert wird und funktioniert.1718## Schritt 2 – Überprüfe, ob die Änderung ein Mobile-Audit besteht19201. Öffne die URL über das Chrome DevTools MCP in einer neuen Seite.212. Führe einen Performance-Trace durch und prüfe die Core Web Vitals.
Andere Checks sind eher qualitativ als Bestehen/Durchfallen, z. B. der Vergleich von Daten mit historischen Normen. Für solche Fälle kannst du mit Claude eine Bewertungsmatrix (Rubric) zur Auswertung der Ergebnisse erstellen.
Überprüfe den Code vor dem Mergen mit einem zweiten Agenten
Alles oben Genannte geschieht innerhalb der Agenten-Schleife. Es gibt einen zweiten Überprüfungsschritt, unmittelbar vor dem Mergen, bei dem du einen anderen Agenten um eine Code-Review bitten kannst.
Ein neuer Agent hat nicht dieselben Vorurteile wie der, der den Code geschrieben hat. Er hat seinen eigenen Kontext und wird nicht von der vorherigen Unterhaltung beeinflusst. Diese Isolation macht die Überprüfung ehrlicher und fängt Dinge ein, die der erste Agent übersehen haben könnte.
Einige Optionen, von manuell bis automatisiert:
- /review (eingebauter Skill) – eine schnelle einmalige Durchsicht eines PRs in deinem Terminal.
- /code-review (installierbares Plugin) – startet mehrere Unteragenten parallel, die den Diff aus verschiedenen Blickwinkeln lesen, die Ergebnisse nach Konfidenz bewerten und das Ergebnis am PR veröffentlichen.
- Claude Code Review – ein verwalteter Dienst, der bei Team- und Enterprise-Plänen automatisch bei jedem PR über GitHub ausgeführt wird.
Egal, für welche Option du dich entscheidest, eine letzte Verteidigungslinie vor dem Merge in die Produktion ist hilfreich.
Zusammenfassung
Du hast jetzt zwei Ebenen:
- Überprüfung, die während des Bauens durch Claude läuft
- eine Review vor dem Merge von einem Agenten, der den Code nicht geschrieben hat
Beide gehören zum selben Entwicklungslebenszyklus. Denk an deine derzeitigen manuellen Schritte: Du machst eine Änderung, räumst sie auf, bestätigst, dass sie funktioniert, commitest, eröffnest einen PR, lässt ihn reviewen und beobachtest CI.
Du kannst all diese Schritte in einen Workflow bündeln, indem du einen Skill schreibst, der andere Skills aufruft. Zum Beispiel hat das Claude Code Team einen Skill, den sie bei der Arbeit an Features ausführen und der Folgendes bündelt:
- Den Skill \
/simplify\zum Bereinigen des Diffs - Einen benutzerdefinierten \
/verify\-Skill, um die Änderung end-to-end zu bestätigen - Eine Design-Prüfung, falls der Diff die UI berührt hat
- Einen Schritt zum Eröffnen und Abonnieren eines PRs
- Einen Skill, um CI zu beobachten und Fehler zu beheben, sobald sie auftauchen
Dein Workflow mag anders aussehen – aber durch das Erstellen von Feedbackschleifen und das Bündeln von Skills kann Claude mehr Arbeit eigenständig überprüfen und end-to-end ausführen.
