Den TDD-Skill von Matt Pocock einrichten

Der TDD-Skill liefert Arbeitsregeln für einen Coding-Agenten; er ersetzt nicht den Test-Runner oder die fachliche Abnahme. Die offizielle Detailseite [skills.sh/mattpocock/skills/tdd](https://skills.sh/mattpocock/skills/tdd) beschreibt den Einzel-Skill. Der vollständige Quellstand ist im [Repository mattpocock/skills](https://github.com/mattpocock/skills) und speziell in skills/engineering/tdd/SKILL.md einsehbar.

Einzel-Skill installieren

Für den einzelnen Skill wird auf der Produktseite dieser Befehl genannt:

npx skills add https://github.com/mattpocock/skills --skill tdd

Er installiert nur tdd aus der Sammlung. Vor dem Ausführen sollte das Team prüfen, in welches Projektverzeichnis das verwendete Tool schreibt, und den aktuellen Quelltext lesen. So bleibt nachvollziehbar, welche Anweisungen der Agent künftig erhält.

Claude-Code-Plugin verwenden

Für Claude Code nennt das Repository den offiziellen Plugin-Weg:

claude plugins install mattpocock-skills

Dieser Weg betrifft das Plugin-Paket, nicht nur die Einzelinstallation. Nach der Installation Claude Code beziehungsweise die betroffene Sitzung neu laden, falls der Client neue Skills nicht sofort erkennt. Welcher Weg passt, hängt davon ab, ob ein Projekt ausschließlich TDD oder eine größere Sammlung von Skills verwenden soll.

Vor dem ersten Test festlegen

Der Skill verlangt, öffentliche Testgrenzen – seine „Seams“ – vor dem ersten Test abzustimmen. Notiere etwa, ob ein Feature über eine HTTP-Antwort, eine CLI, eine UI oder eine öffentliche Klassen-API geprüft wird. Lies vorhandene CONTEXT.md-Dateien und Architekturentscheidungen, damit Testnamen die Sprache der Fachdomäne verwenden. Beginne anschließend mit einem einzelnen beobachtbaren Verhalten und einem erwarteten Ergebnis aus der Spezifikation, nicht mit einer Prüfung privater Methoden.

Im Red-Green-Zyklus arbeiten

Lass den Test zunächst aus dem erwarteten Grund scheitern. Implementiere dann nur das Minimum, das ihn grün macht. Wiederhole diesen kleinen vertikalen Schritt für das nächste Verhalten, statt zuerst eine breite Testsuite für eine angenommene Architektur zu schreiben. Refactoring und Review folgen erst nach verifizierten Änderungen. Jede Änderung sollte den normalen Testbefehl des Projekts erneut durchlaufen.