Test und Spe­zi­fi­ka­tion zuerst

Ob eine Aufgabe erledigt ist, entscheidet ein Maßstab. Steht er vor der Arbeit fest, misst Claude sich während der ganzen Arbeit daran. Dieses Kapitel zeigt, wie ein Test oder eine Spezifikation zu diesem Maßstab wird, mit welchen Bausteinen Claude Code ihn prüft und wann sich der Aufwand lohnt.

Warum ein Agent ohne Prüfung beim Anschein stehen bleibt, erklärt Vibe-Coding / Agentic Engineering, Kapitel 07. Die Methode selbst, mit Messungen und den Fallen beim Einrichten, beschreibt der Beitrag Erst der rote Test.

Woran Claude merkt, dass es fertig ist

Die Empfehlungen von Anthropic (externe Seite, code.claude.com) halten in einem Satz fest, wann Claude aufhört: wenn die Arbeit fertig aussieht. Bekommt Claude etwas, das mit Bestanden oder Durchgefallen antwortet, schließt sich die Schleife von selbst. Claude arbeitet, fährt die Prüfung, liest das Ergebnis und bessert nach, bis sie durchgeht.

Den Wert einer solchen Prüfung bestimmt ihr Zeitpunkt. Ein Test, den Claude nach dem Code schreibt, hält fest, was der Code schon tut. Ein Test, der vorher dasteht, beschreibt die Aufgabe. Das ist der Kern der testgetriebenen Entwicklung, und er gilt genauso für eine Spezifikation. Beide sind Formen desselben Maßstabs:

• Ein Test ist ausführbar. Er sagt für einen Fall, was herauskommen muss, und meldet das Ergebnis über seinen Rückgabewert.
• Eine Spezifikation beschreibt ein Vorhaben im Ganzen: welche Dateien und Schnittstellen es berührt, was dazugehört und was ausdrücklich draußen bleibt. Maschinell prüfbar wird sie dort, wo sie in einen Test mündet.

Einen eigenen Befehl für dieses Vorgehen führt die Befehlsübersicht (externe Seite, code.claude.com) nicht. Geprüft wird an drei Stellen: während der Arbeit, nach jeder Antwort und am Ende. Während der Arbeit fährt Claude die Testfälle, die im Auftrag stehen.

Testfälle gehören in den Auftrag

Die kleinste Spezifikation ist eine Handvoll Beispiele im Prompt. Die Empfehlungen (externe Seite, code.claude.com) stellen dafür zwei Aufträge nebeneinander. Der erste bestellt eine Funktion, die E-Mail-Adressen prüft. Der zweite nennt dazu drei Adressen mit dem erwarteten Ergebnis und bittet darum, die Tests nach dem Bauen auszuführen. Mit dem zweiten Auftrag weiß Claude, wann es fertig ist, und kann es selbst nachweisen.

Bei einem Fehler steht die Nachstellung am Anfang. Im Beispiel der Empfehlungen für einen Fehlerbericht verlangt der Auftrag zuerst einen Test, der am gemeldeten Fehler scheitert, und erst danach die Behebung. Geht es um Tempo oder Abdeckung, gehört eine Zahl in den Auftrag. Die Prompt-Sammlung der Doku (externe Seite, code.claude.com) rät, Kennzahl und Schwelle zu nennen, damit eindeutig ist, wann die Arbeit abgeschlossen ist.

Ein Satz im Auftrag wirkt für diese eine Antwort. Wie man ihn formuliert, damit der erste Test aus dem richtigen Grund rot ist, steht im Beitrag Erst der rote Test. Dort steht auch, warum eine Regel in der CLAUDE.md allein wenig ausrichtet.

Die Spezifikation vor der Arbeit

Für größere Vorhaben empfiehlt Anthropic, sich zuerst von Claude befragen zu lassen, das Ergebnis als SPEC.md festzuhalten und es in einer frischen Sitzung umzusetzen (Empfehlungen (externe Seite, code.claude.com)). Wie diese Befragung vor dem Plan steht, zeigt Kapitel 23, den Prompt dafür die zweite Ebene.

Zum Maßstab wird eine Spezifikation durch ihren Schluss. Die brauchbarsten stehen für sich: Sie nennen die beteiligten Dateien und Schnittstellen und sagen, was nicht zur Aufgabe gehört. Am Ende steht ein Prüfschritt, der das Feature von vorn bis hinten als funktionierend belegt. Eine gute Spezifikation endet also mit einer Prüfung von vorn bis hinten, etwa einem End-to-End-Test. Für den Test zuerst gehören außerdem Akzep­tanz­kri­te­rien hinein, also Sätze, die festhalten, wann ein Teil der Aufgabe erfüllt ist. Aus jedem lässt sich ein Test schreiben.

Ein Plan beschreibt den Weg zum Ergebnis, eine Spezifikation das Ergebnis selbst. Wie viel Papier ein Vorhaben überhaupt braucht und ab wann eine Spezifikation zu viel wird, wägt der Beitrag ADR und Spezifikation ab.

Der Test als Abschlussbedingung

Für Arbeit über viele Antworten hinweg gibt es seit Version 2.1.139 vom 11.05.2026 den Befehl /goal (Versionsliste (externe Seite, code.claude.com)). Am Ende jeder Antwort prüft ein zweites Modell eine Bedingung, und Claude arbeitet weiter, bis sie erfüllt ist. Die Doku zu /goal (externe Seite, code.claude.com) nennt als Einsatz ausdrücklich die Umsetzung eines Entwurfsdokuments, bis alle Akzep­tanz­kri­te­rien gelten. Eine Spezifikation mit Akzep­tanz­kri­te­rien lässt sich damit direkt als Ziel setzen.

Eine Bedingung, die über viele Antworten hinweg hält, hat laut Doku meist drei Teile:

• einen messbaren Endzustand, etwa ein Testergebnis oder den Rückgabewert eines Baus,
• die Angabe, wie Claude ihn belegt, etwa dass npm test mit 0 endet,
• die Auflagen für den Weg dorthin, etwa dass keine andere Testdatei geändert wird.

Der Bewerter liest dabei nur, was im Gespräch steht. Die Bedingung verlangt deshalb etwas, das Claudes eigene Ausgabe zeigen kann. Wie /goal im Einzelnen arbeitet, steht in Kapitel 28.

Fester bindet ein Stop-Hook. Er läuft am Ende jeder Antwort, fährt ein eigenes Skript und lässt Claude weiterarbeiten, bis das Skript zufrieden ist. Die Anleitung zu Hooks (externe Seite, code.claude.com) zeigt dazu eine Form, bei der ein Subagent die Tests selbst ausführt, bevor Claude aufhören darf. Diese Agent-Hooks sind als experimentell gekennzeichnet. Die Formen vergleicht die zweite Ebene, die Mechanik der Hooks erklärt Kapitel 18.

Am Ende die laufende Anwendung

Ein grüner Testlauf belegt, was die Tests prüfen. Ob die Anwendung als Ganzes tut, was sie soll, ist eine weitere Frage. Der Beitrag Erst der rote Test beschreibt eine Untersuchung, in der Agenten fast die volle Punktzahl erreichten, sobald die Prüfung im Arbeitsablauf lag. Die geforderte Bibliothek war dabei tot oder fehlte ganz.

Für diesen letzten Blick dienen zwei mitgelieferte Skills. /run startet die Anwendung und bedient sie, damit man eine Änderung arbeiten sieht. /verify baut und startet sie und beobachtet das Ergebnis, ohne auf Tests oder Typprüfungen auszuweichen (Doku zu Skills (externe Seite, code.claude.com)). Die Empfehlungen (externe Seite, code.claude.com) setzen /verify an den Schluss: Man ruft es selbst auf, nachdem Claudes eigene Prüfung bestanden ist. Seit Version 2.1.215 vom 19.07.2026 startet Claude /verify nur noch auf Aufruf. Wie man den beiden Skills den Start eines Projekts beibringt und wie daraus eine Prüfung vor jedem Commit wird, zeigt die zweite Ebene.

Wann sich das lohnt

Test und Spezifikation zuerst lohnen sich, wo eine Maschine entscheiden kann, ob die Aufgabe erledigt ist:

• Fehlerbehebung: Der Test, der den Fehler nachstellt, belegt danach die Behebung.
• Neue Funktion mit klaren Fällen: Drei Beispiele im Auftrag kosten einen Satz.
• Vorhaben über mehrere Dateien: Befragung, Spezifikation, frische Sitzung, und die Akzep­tanz­kri­te­rien als Bedingung für /goal.
• Lauf ohne Zuschauer: Zielbedingung oder Stop-Hook, damit der Lauf an der Prüfung endet.

Weniger bringt das Vorgehen in drei Fällen:

• Beim Erkunden. Wer erst herausfinden will, wie sich eine Schnittstelle verhält, kennt das erwartete Ergebnis noch gar nicht. Dort ist ein Wegwerfversuch mit anschließendem Test billiger.
• Bei Gestaltung. Für eine Oberfläche ist ein Bildschirmfoto der bessere Maßstab. Die Empfehlungen lassen Claude das Ergebnis aufnehmen und mit dem Entwurf vergleichen.
• Bei Tests, die Claude nebenbei anlegt. Eine Untersuchung fand, dass ihre Menge das Ergebnis kaum verändert, gemessen an sechs Modellen (Erst der rote Test). Den Unterschied macht ein Test, der vor der Arbeit feststeht.

Wie ein Prüfer mit frischem Kontext die fertige Arbeit nachsieht, zeigt Kapitel 25.

Die erste Ebene hat gezeigt, an welchen Stellen Claude Code einen Maßstab prüft. Hier geht es um die Handgriffe. Wie entsteht eine Spezifikation, die sich prüfen lässt? Wie hält man den fertigen Diff gegen sie? Wie wird aus Akzep­tanz­kri­te­rien eine Zielbedingung, und welcher Hook fährt die Tests selbst? Zum Schluss geht es um /verify und um Tests für Code, den es schon gibt.

Die Spezifikation im Gespräch erarbeiten

Die Empfehlungen von Anthropic (externe Seite, code.claude.com) geben für die Befragung einen kurzen Prompt vor, der mit einer knappen Beschreibung des Vorhabens beginnt. Sinngemäß lautet er so:

Ich möchte [kurze Beschreibung] bauen. Befrage mich ausführlich
mit dem Werkzeug AskUserQuestion: zu Umsetzung, Oberfläche,
Grenzfällen, Bedenken und Abwägungen. Stell keine naheliegenden
Fragen. Geh an die schwierigen Stellen, an die ich vielleicht
noch nicht gedacht habe. Frag weiter, bis alles abgedeckt ist,
und schreib dann eine vollständige Spezifikation nach SPEC.md.

In der Voreinstellung bleibt jede Frage offen, bis man sie beantwortet. Hat man mit askUserQuestionTimeout eine Frist gesetzt, schließt eine unbeantwortete Frage danach von selbst, und Claude fährt nach eigenem Urteil fort (Werkzeugreferenz (externe Seite, code.claude.com)). Die Befragung passt deshalb in eine Sitzung, bei der man dabei ist. Was in die fertige Datei gehört, steht in der ersten Ebene: die beteiligten Dateien und Schnittstellen, die Grenzen der Aufgabe und ein Prüfschritt von vorn bis hinten.

Für ein Vorgehen mit Test zuerst lohnt sich ein eigener Abschnitt mit Akzep­tanz­kri­te­rien. Jedes Kriterium ist ein Satz, aus dem sich ein Test schreiben lässt. Diesen Abschnitt liest man vor der Umsetzung selbst durch, denn ab hier misst Claude sich daran. Danach wird die Datei committet. Jede spätere Änderung an der Spezifikation zeigt dann der Diff.

Die Umsetzung beginnt in einer neuen Sitzung. Deren Kontext gehört ganz der Umsetzung, und die Spezifikation liegt als Datei zum Nachschlagen bereit. Beim Test zuerst lautet der erste Auftrag dort, aus den Akzep­tanz­kri­te­rien Tests zu schreiben, sie laufen zu lassen und die roten Läufe zu zeigen. Erst der zweite Auftrag verlangt den Code. Wie man die Tests währenddessen mit einer Rechteregel sperrt und welche Fallen die Regel hat, steht im Beitrag Erst der rote Test. Die Rechteregeln selbst erklärt Kapitel 16.

Den Diff gegen die Spezifikation prüfen

/code-review sucht Fehler im Diff. Ob die Umsetzung die Spezifikation erfüllt, prüft ein Subagent mit einem Auftrag, den man selbst schreibt. Die Empfehlungen zeigen das mit einer Datei PLAN.md, und Kapitel 25 erklärt, was der Auftrag nennt und warum der Prüfer als Subagent läuft. Mit einer Spezifikation sieht er so aus:

Prüfe mit einem Subagent den Diff zur Ratenbegrenzung gegen
SPEC.md. Ist jede Anforderung umgesetzt? Hat jeder genannte
Grenzfall einen Test? Ist außerhalb der Aufgabe etwas verändert?
Melde Lücken. Stilfragen lass weg.

Der Schluss des Auftrags schließt Stilfragen aus. Ein Prüfer, der Lücken finden soll, meldet meistens welche, auch wenn die Arbeit in Ordnung ist.

Akzeptanzkriterien als Zielbedingung

Eine Spezifikation mit Akzep­tanz­kri­te­rien wird mit /goal zum Ende eines Laufs. Die Bedingung darf bis zu 4.000 Zeichen lang sein (Doku zu /goal (externe Seite, code.claude.com)). Für den Test zuerst sieht sie etwa so aus:

/goal Alle Akzeptanzkriterien aus SPEC.md gelten:
npm test endet mit 0, und Claude nennt zu jedem
Kriterium den Test, der es prüft.
git status --short tests/ zeigt keine Änderung.
Zeig beide Ausgaben am Ende jeder Antwort.
Oder stopp nach 25 Antworten.

Beide Befehle stehen darin, weil der Bewerter nur Claudes Ausgabe liest und selbst nichts ausführt. Warum der Blick auf das Testverzeichnis dazugehört, steht im Beitrag Erst der rote Test, Abschnitt „Die Zielbedingung“. Der Schluss der Bedingung setzt eine Obergrenze. Eine Grenze nach Antworten oder Zeit schreibt man in die Bedingung, und Claude meldet in jeder Antwort den Stand dazu.

Jedes Urteil des Bewerters steht im Verlauf, und mit Ctrl+O sieht man seine Begründung. Was ein Ziel beendet, wie es nach Fehlern weiterläuft und wie es mit -p in einem Skript läuft, steht in Kapitel 28.

Wer am Ende der Antwort den Test fährt

/goal ist technisch ein Stop-Hook mit einem Prompt, der nur für die laufende Sitzung gilt. Ein Stop-Hook in den Einstellungen gilt dagegen für jede Sitzung in seinem Geltungsbereich und kann ein Skript oder einen Prompt ausführen. Dazu kommt eine dritte Bauart, der Agent. Die Tabelle vergleicht vier Wege, am Ende einer Antwort über die Tests zu urteilen. Ein Stop-Hook kann außerdem eine Adresse per HTTP oder ein MCP-Werkzeug aufrufen. Alle fünf Arten von Hooks erklärt Kapitel 18.

Quelle: Doku zu /goal (externe Seite, code.claude.com) und Anleitung zu Hooks (externe Seite, code.claude.com), Stand 12.10.2026.

Die Bauart als Agent startet einen Subagent, der Dateien lesen, Code durchsuchen und andere Werkzeuge benutzen kann, bevor er entscheidet. Er hat in der Voreinstellung 60 Sekunden Zeit und bis zu 50 Runden mit Werkzeugen. Die Anleitung zeigt genau diesen Fall, einen Hook, der vor dem Ende prüft, ob alle Unit-Tests bestehen. Mit deutschem Auftrag sieht er so aus:

{
  "hooks": {
    "Stop": [
      {
        "hooks": [
          {
            "type": "agent",
            "prompt": "Prüfe, ob alle Unit-Tests bestehen. Führe die Testsammlung aus und sieh dir das Ergebnis an. $ARGUMENTS",
            "timeout": 120
          }
        ]
      }
    ]
  }
}

Die Anleitung grenzt die beiden Bauarten mit Modell so ab: Ein Prompt genügt, wenn die Eingabedaten des Hooks für die Entscheidung reichen. Ein Agent ist nötig, wenn etwas am tatsächlichen Stand des Codes geprüft werden muss. Agent-Hooks sind experimentell. Für den Dauerbetrieb rät die Anleitung zu Hooks als Befehl. Ein solcher Befehl lässt Claude mit dem Rückgabewert 2 weiterarbeiten. Warum ein gescheiterter Testlauf dafür übersetzt werden muss, steht im Beitrag Erst der rote Test.

Für einzelne Aufgaben gibt es denselben Riegel, den Hook TaskCompleted. Er kam mit Version 2.1.33 vom 06.02.2026 für Abläufe mit mehreren Agenten (Versionsliste (externe Seite, code.claude.com)). Er läuft in zwei Fällen (Hook-Referenz (externe Seite, code.claude.com)): Ein Agent markiert eine Aufgabe über das Werkzeug TaskUpdate als erledigt, oder ein Teammate eines Agent Teams beendet seine Antwort mit offenen Aufgaben. Endet er mit 2, bleibt die Aufgabe offen, und die Fehlerausgabe geht als Rückmeldung an das Modell. Die Referenz zeigt dazu ein Skript, das die Testsammlung fährt. Teams beschreibt Kapitel 22.

/verify und /run

Drei mitgelieferte Skills arbeiten zusammen, um die Anwendung zu starten und eine Änderung an der laufenden Anwendung zu bestätigen (Doku zu Skills (externe Seite, code.claude.com)):

/run und /verify brauchen keine Einrichtung. Wie gestartet wird, leiten sie aus der Art des Projekts ab, etwa Kommandozeile, Server oder Browser, und aus README, package.json oder Makefile. Bei Projekten, die mehr als einen gewöhnlichen Start brauchen, wird diese Ableitung unzuverlässig. Gemeint sind etwa eine Datenbank, eine Datei mit Umge­bungs­va­ria­blen, eine grafische Sitzung oder ein Bau in mehreren Schritten.

Für solche Projekte zeichnet /run-skill-generator das Rezept auf. Der Skill bringt die Anwendung aus einer sauberen Umgebung zum Laufen und hält fest, was funktioniert hat. Das committet er als Skill des Projekts unter .claude/skills/run-<name>/. Man ruft ihn einmal je Projekt auf und erneut, wenn sich Bau oder Start ändern.

/verify legt sein Rezept auch selbst an. Muss es eine Anwendung ohne aufgezeichnetes Rezept bauen und bedienen, schreibt es das Gelungene nach .claude/skills/verify/SKILL.md. Im Wurzelverzeichnis des Repositorys ersetzt dieser Skill den mitgelieferten /verify. Seit Version 2.1.205 vom 08.07.2026 ändert Claude die Datei nur noch, wenn sie einen Lauf in die Irre geführt hat. Man kann sie deshalb committen, ohne in jeder Sitzung einen neuen Diff zu bekommen.

Damit hängt eine Regel zusammen, die Kapitel 17 beschreibt. Seit Version 2.1.286 soll Claude einen eigenen Skill namens verify direkt vor jedem Commit aufrufen. Die Doku zu Skills nennt heute auch simplify, und beide gelten, wenn sie beim Start der Sitzung bereitliegen. Ausgenommen sind Änderungen nur an Doku oder Tests. Der erste Commit mit den neuen Tests ist also ausgenommen. Geprüft wird beim Commit mit dem Code. Das aufgezeichnete Rezept aus /verify zählt dabei als Skill des Projekts. Den mitgelieferten /verify nimmt die Doku dabei ausdrücklich aus. Ein einziger Lauf von /verify, der im Wurzelverzeichnis ein Rezept anlegt, richtet so ab der nächsten Sitzung eine Prüfung vor jedem Commit ein. Die Bedingungen dafür, etwa dass Claude den Skill aufrufen darf, stehen in jenem Kapitel.

Tests für vorhandenen Code

Die Rezepte der Doku (externe Seite, code.claude.com) beschreiben den umgekehrten Fall: Code ist da, Tests fehlen. Der Ablauf hat vier Schritte. Claude sucht Funktionen ohne Tests, legt ein Gerüst für die Tests an, ergänzt Fälle für die Ränder, fährt die neuen Tests und behebt, was dabei scheitert. Dabei liest Claude die vorhandenen Testdateien und übernimmt deren Stil, Rahmenwerk und Art der Zusicherungen. Die Doku rät außerdem, Claude nach Grenzfällen fragen zu lassen, die man selbst übersehen hat.

Hier entsteht der Test nach dem Code. Ein nachgelieferter Test ist beim ersten Lauf grün, und das belegt noch nichts. Den roten Lauf ersetzt eine Mutation, also eine absichtlich kaputte Fassung des Codes, gegen die der Test fallen muss. In Claude Code ist das ein weiterer Auftrag:

Ändere in NotificationsService.swift die Grenzprüfung
absichtlich falsch, fahre die neuen Tests, zeig mir die Ausgabe
und nimm die Änderung danach wieder zurück.

Fällt der Test gegen die kaputte Fassung und besteht er gegen die echte, misst er etwas. Warum dabei auch die Gegenprobe am unveränderten Stand dazugehört, steht im Beitrag Erst der rote Test.

Diese Ebene ordnet ein. Sie zeigt, woher Anthropics Rat stammt, Tests vor dem Code zu schreiben, und welche Bausteine Claude Code seither dafür bekommen hat. Danach geht es um die Frage, wer den Maßstab schreibt, und um ein Werkzeug, das aus einer Spezifikation selbst Tests erzeugt.

Wie die Empfehlung entstand

Am 18.04.2025 veröffentlichte Anthropic einen Beitrag mit Empfehlungen für Claude Code, damals noch im Blog „Engineering at Anthropic“ (Archivfassung vom 20.04.2025 (externe Seite, web.archive.org)). Einer der Abläufe darin hieß sinngemäß: Tests schreiben und committen, dann Code schreiben, nachbessern und committen. Der Text nannte ihn einen Lieblingsablauf bei Anthropic für Änderungen, die sich mit Unit-, Integrations- oder End-to-End-Tests leicht prüfen lassen. Testgetriebene Entwicklung werde mit einem Agenten noch wirksamer.

Der Ablauf hatte fünf Schritte, alle als Auftrag an Claude:

1. Tests aus erwarteten Paaren von Eingabe und Ausgabe schreiben. Dabei ausdrücklich sagen, dass testgetrieben gearbeitet wird, damit Claude keine Mock-Implementierungen für Funktionen baut, die es noch gar nicht gibt.
2. Die Tests laufen lassen und bestätigen, dass sie fehlschlagen. Oft hilft der ausdrückliche Hinweis, in diesem Schritt noch keinen Code für die Umsetzung zu schreiben.
3. Die Tests committen, sobald man mit ihnen zufrieden ist.
4. Code schreiben, der die Tests besteht, ohne die Tests zu ändern, und weitermachen, bis alle bestehen. Dabei kann es helfen, mit unabhängigen Subagents prüfen zu lassen, ob sich die Umsetzung an die Tests überanpasst.
5. Den Code committen.

Die Begründung stand gleich dahinter: Claude arbeite am besten mit einem klaren Ziel, an dem es sich abarbeiten kann, etwa einem Entwurfsbild oder einem Testfall.

Heute leitet die alte Adresse auf die Seite mit den Empfehlungen in der Doku (externe Seite, code.claude.com) um. Dort kommt der Name testgetriebene Entwicklung nicht mehr vor (Stand 12.10.2026). Die Prompt-Sammlung der Doku (externe Seite, code.claude.com) führt den Kern des Ablaufs als Karte unter dem Reiter Test. Ihr Auftrag lautet, zuerst die Tests für eine Funktion zu schreiben und sie dann umzusetzen, bis die Tests bestehen.

Auf der Seite mit den Empfehlungen stehen zwei Stücke aus dem Beitrag von 2025 weiter da. Fast wörtlich steht das Muster mit zwei Sitzungen: Die eine schreibt die Tests, die andere den Code, der sie besteht. Der Rat zu unabhängigen Subagents steckt heute in der vierten von vier Stufen. Dort versucht ein frisches Modell, das Ergebnis zu widerlegen. Neu ist der Rat, einen Fehler zuerst mit einem scheiternden Test nachzustellen.

Dazu kommt die Frage, wie hart eine Prüfung das Ende einer Antwort blockiert. Jede der vier Stufen tauscht Einrichtung gegen Aufmerksamkeit. Erst /goal und Stop-Hook lassen einen Lauf ohne Zuschauer richtig zu Ende kommen. Im April 2025 bestand der ganze Ablauf aus Sätzen im Auftrag. Heute sitzen die härteren Stufen als Funktionen im Programm.

Die Bausteine in Versionen

Die Versionen und Daten stammen aus der Versionsliste (externe Seite, code.claude.com), die erste Zeile aus dem archivierten Beitrag.

Den Schritt vom 30.09.2026 beschreibt die Versionsliste (externe Seite, code.claude.com) als Hinweis zum Commit. Hat ein Projekt oder ein Nutzer einen Skill namens verify, soll Claude ihn direkt vor dem Commit aufrufen. Ausgenommen sind Commits nur an Doku oder nur an Tests. Die Doku zu Skills nennt heute dazu auch simplify. Wann /verify und /run als mitgelieferte Skills dazukamen, nennt die Versionsliste nicht. Der erste Eintrag zu aufgezeichneten Skills verify steht bei Version 2.1.205.

Wer den Maßstab schreibt

Ein Test ist so viel wert wie die Erwartung, die er festhält. Schreibt Claude Tests und Code in derselben Sitzung, beschreiben beide dasselbe Verständnis der Aufgabe. Ein Missverständnis steht dann im Test genauso wie im Code, und der grüne Lauf bestätigt es. Einem verwandten Fall galt 2025 der Rat, die Umsetzung von unabhängigen Subagents auf Überanpassung an die Tests prüfen zu lassen. Gemeint ist Code, der die Tests besteht und die Aufgabe trotzdem verfehlt.

Claude Code trennt die Rollen heute an drei Stellen:

• Bei der Spezifikation stellt Claude die Fragen, und die Antworten kommen vom Menschen. Geschrieben wird die Datei trotzdem von Claude. Deshalb liest man sie vor der Umsetzung selbst.
• Bei /goal entscheidet ein frisches Modell über das Ende, das an der Arbeit unbeteiligt ist. Die Bedingung schreibt der Mensch. Der Bewerter urteilt aber über das, was Claude im Gespräch zeigt.
• Bei einem Stop-Hook als Befehl urteilt ein Skript. Sein Urteil hängt an dem, was das Skript selbst prüft, unabhängig davon, was Claude zeigt.

Was die Trennung bringt, ist an anderer Stelle gemessen. Tests, die ein Agent nebenbei schreibt, verändern das Ergebnis in einer Untersuchung kaum. In einer zweiten erreicht ein Aufbau, der eigens für vorgegebene Tests von Menschen gebaut ist, ungewöhnlich hohe Werte. Zahlen und Aufbau beider Arbeiten stehen im Beitrag Erst der rote Test.

Wie Kiro aus Anforderungen Tests macht

Kiro, das Coding-Werkzeug von AWS, baut seine Arbeitsweise auf Spezifikationen auf. Wie viel Papier das bei kleinen Änderungen erzeugt, schildert der Beitrag ADR und Spezifikation. Eine Sache ist bei Kiro weiter ausgebaut als bei Claude Code: der Weg von der Anforderung zum Test.

Kiro schreibt Anforderungen in einer festen Satzform, die EARS heißt, und leitet daraus Eigenschaften ab (Doku zu Kiro (externe Seite, kiro.dev)). Eine Eigenschaft ist eine allgemeine Regel. Statt einzelne Beispiele aufzuzählen, erzeugt das Werkzeug Hunderte oder Tausende zufälliger Eingaben und versucht, die Regel damit zu brechen. Findet es einen Verstoß, verkleinert es die Eingabe auf die kleinste, die den Fehler noch auslöst. So bleibt zwischen jeder Anforderung und den Tests, die sie prüfen, eine nachvollziehbare Verbindung.

Laut der Tabelle in derselben Doku steht die Funktion allein in Kiros IDE bereit. Die Tests sind in der Voreinstellung freiwillig. Unter den Grenzen, die Kiro selbst nennt, steht diese: Eine zu schwache oder falsch gefasste Eigenschaft besteht, während das Verhalten weiter falsch ist.

In Claude Code entsteht diese Verbindung über Aufträge und Dateien. Die Spezifikation liegt in SPEC.md, die Tests schreibt Claude auf Bitte, auch eigen­schafts­ba­sierte mit einer passenden Bibliothek der jeweiligen Sprache. Dass jedes Kriterium einen Test hat, prüft ein Review gegen die Spezifikation oder eine Zielbedingung. Die Zuordnung von Kriterium zu Test hält in Claude Code der Auftrag fest.

Was offen bleibt

• Die Wirkung des Ablaufs in Zahlen. Anthropic nannte ihn 2025 einen Liebling im eigenen Haus. Weder jener Beitrag noch die heutigen Empfehlungen nennen eine Messung dazu.
• Seit wann es /verify und /run gibt. Die Versionsliste nennt den Zeitpunkt nicht.
• Agent-Hooks. Sie sind experimentell, und Verhalten wie Einrichtung können sich laut Anleitung noch ändern.
• Was der Bewerter von /goal übersieht. Laut Doku liest er nur, was Claude im Gespräch zeigt. Daraus folgt, dass er eine geänderte Testdatei, die Claude nicht zeigt, nicht bemerken kann. Das ist eine Folgerung aus der Beschreibung, und eine Messung dazu nennt die Doku nicht.