Der legendäre Skill, den Entwickler großer Tech-Unternehmen nutzen: Tutorial zu mattpocock/skills mit 300.000 Sternen – in 5 Schritten loslegen: erst mit /grill-me die Anforderungen klären, dann mit /tdd programmieren

Anmerkung des Autors: In diesem Artikel lernst du Schritt für Schritt die zwei zentralen Skills aus mattpocock/skills kennen – auch ohne Vorkenntnisse. Mit /grill-me klärst du zuerst die Anforderungen, danach schreibst du mit /tdd den Code. Für jeden Schritt gibt es Abnahmekriterien.

Kurz gesagt: Lass den Agenten mit /grill-me zuerst die Anforderungen klären und schreibe anschließend mit /tdd jeweils einen Test nach dem anderen.

Stand: 22.10.2026, Peking-Zeit. Das GitHub-Projekt mattpocock/skills hat rund 300.000 Sterne, steht unter der MIT-Lizenz und ist aktuell in Version v1.3.1 verfügbar. Die Zahl der Sterne zeigt nur, wie viel Aufmerksamkeit ein Projekt bekommt – sie bedeutet nicht, dass es in deinem Projekt automatisch gut funktioniert. Deshalb geht es in diesem Artikel nur darum, wie du es installierst und verwendest und woran du erkennst, ob es richtig funktioniert. Die Wirkung wird nicht übertrieben dargestellt.

Dieser Praxisleitfaden führt dich Schritt für Schritt durch den Ablauf. Als Beispiel dient die kleine Aufgabe, eine Gutscheinprüfung in den Bestellprozess einzubauen. Wir gehen von der Installation bis zum ersten erfolgreichen Test.

Ziel: Skill installieren, mit /grill-me eine Runde zur Anforderungsklärung durchlaufen und mit /tdd den ersten Test von „rot zu grün“ bringen
Zeitaufwand: Die Installation dauert nur wenige Minuten (laut Autor „in 30 Sekunden erledigt“). Wie lange die Fragen und das Schreiben des Tests dauern, hängt vor allem davon ab, wie schnell du antwortest. Die folgende Schätzung stammt von der Redaktion: insgesamt etwa 30 Minuten bis eine Stunde
Voraussetzungen: Du verwendest bereits einen Programmier-Agenten, etwa Claude Code, Codex, GitHub Copilot, Gemini CLI oder Cursor, und hast ein Code-Repository, in dem du gefahrlos experimentieren kannst
Schwierigkeitsgrad: Einsteigerfreundlich. Der Ablauf besteht hauptsächlich aus der Arbeit mit grafischen Oberflächen und Dialogen. Terminalbefehle sind als optionale Möglichkeit aufgeführt.

Die wichtigsten Punkte zu mattpocock/skills: Wofür sind grill-me und tdd da?

mattpocock/skills ist eine öffentliche Sammlung von Agent-Skills von Matt Pocock. Die Beschreibung des Repositorys lautet „Skills for Real Engineers“. Im README schreibt der Autor, dass die Skills klein, kombinierbar und mit jedem Modell kompatibel sind – und auf „jahrzehntelanger Erfahrung in der Softwareentwicklung“ beruhen.

Schwerpunkt	Beschreibung	Nutzen
/grill-me	Stellt Fragen in mehreren Runden und schlägt für jede Frage eine Antwort vor. Schreibt keine Dateien und lässt sich nur durch eine manuelle Eingabe von dir starten.	Gleiche dich vor dem Loslegen mit dem Agent ab und decke Entscheidungen auf, die dir bisher nicht bewusst waren.
/tdd	Legt zunächst die Test-Seams fest und wartet auf deine Bestätigung. Anschließend geht es nach dem Prinzip „Rot → Grün“ weiter – ein Test nach dem anderen.	Jeder Schritt liefert Feedback, und die Tests halten einem Refactoring stand.
/setup-matt-pocock-skills	Wird einmal pro Repository ausgeführt und richtet Issue-Tracker, Triage-Labels und den Speicherort für Dokumentation ein.	Gibt den Skills für Entwicklungsaufgaben vor, wo sie ihre Arbeit ablegen sollen.
Installationswege	Du hast die Wahl zwischen einem Plugin mit automatischen Updates und skills.sh mit bearbeitbaren Dateien.	Installierst du beide Varianten, wird jeder Skill doppelt angezeigt.

Warum grill-me und tdd zusammen einsetzen?

Im README werden mehrere häufige Fehlerquellen aufgeführt. Zwei davon passen genau zu diesen beiden Skills. Die erste lautet: „Der Agent hat nicht das gemacht, was ich wollte.“ Dahinter steckt eine Kommunikationslücke zwischen dir und dem Agent. Die Lösung ist eine Runde „Grilling“: Der Agent fragt dich ausführlich danach, was du vorhast. /grill-me besteht im Grunde nur aus einer Anweisung: den Grilling-Skill aufzurufen. Die eigentlichen Regeln für die Fragen stehen im Skill „grilling“.

Ein weiteres Problem lautet: „Der Code läuft nicht.“ Selbst wenn die Anforderungen geklärt sind, arbeitet der Agent praktisch im Blindflug, wenn er nicht sehen kann, wie der Code tatsächlich ausgeführt wird. Bei /tdd wird zuerst ein Test geschrieben, der fehlschlägt. Danach folgt genau der Code, der nötig ist, damit der Test besteht. So erhält der Agent bei jedem Schritt verlässliches Feedback. Zusammen lösen die beiden Skills also unterschiedliche Aufgaben: Der erste klärt, was gebaut werden soll, der zweite prüft, ob es richtig umgesetzt wurde.

So installierst du mattpocock/skills und legst mit grill-me und tdd los: Einstieg in 5 Schritten

Schritt 1: mattpocock/skills installieren (am besten über die grafische Oberfläche)

Die offizielle Anleitung beschreibt die Installation für Claude Code, Codex, GitHub Copilot und Gemini CLI. Für andere Agents empfiehlt sie skills.sh. Laut README funktionieren die Skills mit jedem Modell. Auggie, Droid, Goose und einige weitere Agents wurden laut offizieller Seite bisher noch nicht getestet. Hier empfiehlt sich zunächst die Installation über skills.sh.

Dein Agent	Empfohlene Installation	Automatische Updates
GitHub Copilot (VS Code)	Öffne die Befehlspalette, wähle Chat: Install Plugin From Source und gib `https://github.com/mattpocock/skills` ein	Ja, täglich
Claude Code	Installiere `mattpocock-skills` über den offiziellen Plugin-Marktplatz `claude-plugins-official`	Ja, standardmäßig aktiviert
Codex	Füge zuerst den Plugin-Marktplatz `mattpocock/skills` hinzu und installiere dann das Plugin	Ja, beim Start
Copilot CLI	Installiere das Plugin über den Plugin-Marktplatz `mattpocock`	Nach einmaliger Einrichtung von `autoUpdate: true`
Gemini CLI	Installiere die Verzeichnisse `engineering` und `productivity` separat	Nein, Befehle müssen erneut ausgeführt werden
Cursor, OpenCode, Windsurf, Devin, Amp, Pi usw.	skills.sh	Nein, manuelle Updates erforderlich

Für VS-Code-Nutzer ist die Installation besonders einfach. Öffne mit Ctrl+Shift+P (unter macOS Cmd+Shift+P) die Befehlspalette, gib Chat: Install Plugin From Source ein und füge nach der Bestätigung die Repository-Adresse ein. Wenn du lieber das Terminal verwendest, kannst du die offiziellen Installationsbefehle direkt kopieren:

Claude Code: Führe claude plugin install mattpocock-skills@claude-plugins-official aus. Automatische Updates sind standardmäßig aktiviert.
Codex: Führe zuerst codex plugin marketplace add mattpocock/skills und danach codex plugin add mattpocock-skills@mattpocock aus. Updates erfolgen bei jedem Start.
GitHub Copilot CLI: Führe zuerst copilot plugin marketplace add mattpocock/skills und danach copilot plugin install mattpocock-skills@mattpocock aus.
Gemini CLI: Führe gemini skills install https://github.com/mattpocock/skills.git --path skills/engineering und gemini skills install https://github.com/mattpocock/skills.git --path skills/productivity separat aus. Die Skills werden nicht automatisch aktualisiert. Führe die beiden Befehle erneut aus, wenn du aktualisieren möchtest.
Andere Agents (skills.sh): Führe npx skills@latest add mattpocock/skills -a cursor aus. Ersetze cursor durch den Namen deines Agents, zum Beispiel opencode, devin, windsurf, amp oder pi. Ohne -a kannst du den Agent selbst auswählen. Für Updates verwendest du npx skills@latest update. Wenn neue Skills verfügbar sind, führe den Befehl add erneut aus.
Nur einen einzelnen Skill installieren: Führe npx skills@latest add mattpocock/skills --skill=<name> aus und ersetze <name> durch den Namen des Skills.

Für Copilot CLI musst du außerdem einmalig ~/.copilot/settings.json öffnen und diesen Konfigurationsabschnitt hinzufügen: {"extraKnownMarketplaces": {"mattpocock": {"source": {"source": "github", "repo": "mattpocock/skills"}, "autoUpdate": true}}}. Damit wird der Plugin-Marktplatz von mattpocock als Quelle aus dem GitHub-Repository mattpocock/skills eingetragen und die automatische Aktualisierung aktiviert. Laut offizieller Dokumentation entspricht der Abschnitt dem vorgegebenen Format, wurde aber noch nicht praktisch getestet.

Du solltest dich entweder für die Plugins oder für skills.sh entscheiden. Plugins sind schreibgeschützte Pakete, die automatisch aktualisiert werden. skills.sh kopiert bearbeitbare Dateien in dein Projekt. Installierst du beides, liegt jeder Skill zweimal vor. Wenn du skills.sh verwendest, fragt dich das Installationsprogramm, welche Skills du installieren möchtest. Achte darauf, setup-matt-pocock-skills auszuwählen.

Wenn Sie nur einzelne Skills installieren möchten, müssen Sie jeweils zwei Abhängigkeiten gemeinsam installieren. grill-me ruft selbst nur grilling auf, daher muss grilling ebenfalls installiert sein. tdd hängt von codebase-design ab und verwendet dessen Begriffe für das Schnittstellendesign, um über Seams zu sprechen.

Das Ergebnis ist erfolgreich, wenn: Sie im Agent-Dialog / eingeben und in der Vorschlagsliste grill-me, tdd und setup-matt-pocock-skills sehen – und jeder Eintrag genau einmal erscheint.

Schritt 2: /setup-matt-pocock-skills im Dialog ausführen

Wenn Sie diese Skills zum ersten Mal in einem Repository verwenden, geben Sie zunächst /setup-matt-pocock-skills im Agent-Dialog ein. Der Agent stellt Ihnen nacheinander drei Fragen: Welchen Issue-Tracker Sie verwenden (GitHub, GitLab, lokale Dateien oder eine andere von Ihnen beschriebene Lösung), welche Labels Sie für die Ticket-Triage nutzen möchten und wo die erstellten Dokumente gespeichert werden sollen.

Antworten Sie einfach ehrlich. Wenn Sie sich nicht sicher sind, wählen Sie lokale Dateien – das können Sie später noch ändern. Genau genommen ist /grill-me nicht vom Repository abhängig, daher können Sie diesen Schritt überspringen. Bei Engineering-Skills wie /tdd empfiehlt es sich jedoch, die Einrichtung vorher abzuschließen. Sie muss nur einmal pro Repository durchgeführt werden.

Das Ergebnis ist erfolgreich, wenn: der Agent alle drei Fragen gestellt und Ihnen mitgeteilt hat, dass die Einrichtung abgeschlossen ist, und Sie wissen, wo die Dokumente künftig gespeichert werden.

Schritt 3: Das passende Modell für grill-me und tdd auswählen

In der offiziellen Dokumentation wird besonders darauf hingewiesen, dass die Fragestellungsphase stärker als bei den meisten Skills vom Modell abhängt. Beim gezielten Nachfragen kommt es auf das Wissen des Modells darüber an, „wie ein System scheitern kann“. Verwenden Sie dafür also das beste Modell, auf das Sie Zugriff haben. Beim Schreiben der Implementierung folgt das Modell hauptsächlich dem bereits aufgebauten Kontext – dafür reicht oft auch ein günstigeres Modell.

Phase	Anforderungen an das Modell	Empfehlung
Fragen mit /grill-me	Hängt vom technischen Wissen des Modells ab. Je leistungsfähiger das Modell, desto präziser die Fragen.	Verwenden Sie das stärkste verfügbare Modell, zum Beispiel Claude Opus 5.5.
Implementierung mit /tdd	Folgt hauptsächlich dem bereits aufgebauten Kontext.	Hier können Sie zu einem günstigeren Modell wechseln.
Anbindung	In Claude Code und Codex das Modell je nach Phase wechseln.	Mit einem API-Schlüssel von APIYI über apiyi.com verschiedene Modelle anbinden.

So richten Sie eine einheitliche Schnittstelle in Claude Code und Codex ein:

Claude Code: Legen Sie zunächst zwei Umgebungsvariablen fest: ANTHROPIC_BASE_URL auf https://api.apiyi.com (einheitliche Schnittstelle von APIYI) und ANTHROPIC_AUTH_TOKEN auf Ihren API-Schlüssel. Starten Sie anschließend claude und wechseln Sie im Dialog mit /model das Modell.
Codex: Öffnen Sie ~/.codex/config.toml und fügen Sie die beiden Zeilen model = "<模型ID>" und model_provider = "apiyi" ein. Ergänzen Sie dann den Abschnitt [model_providers.apiyi] und tragen Sie darunter die drei Zeilen name = "APIYI", base_url = "https://api.apiyi.com/v1" und env_key = "APIYI_API_KEY" ein. Die Modell-ID entnehmen Sie der Anzeige in der Konsole.

Die Feldnamen können sich je nach Tool-Version ändern. Maßgeblich sind daher die offizielle Tool-Dokumentation und docs.apiyi.com.

🎯 Modellauswahl: Verwenden Sie für die Fragestellungsphase lieber das beste verfügbare Modell und wechseln Sie erst für die Implementierung zu einem günstigeren. Über APIYI auf apiyi.com können Sie mit einem API-Schlüssel bequem zwischen Modellen in Claude Code und Codex wechseln. Wichtig: APIYI löst nur das Problem des Modellaufrufs und ersetzt nicht die Skills selbst, etwa grill-me und tdd.

So erkennen Sie, dass alles funktioniert: Prüfen Sie im Dialog, welches Modell gerade aktiv ist. In Claude Code können Sie dafür /model verwenden. Vergewissern Sie sich, dass in der Fragestellungsphase das von Ihnen ausgewählte leistungsstarke Modell aktiv ist.

Schritt 4: Mit /grill-me die Anforderungen an die „Gutscheinvalidierung“ klären

Öffne eine neue Sitzung. Mach nicht in der Sitzung weiter, in der der Agent bereits einen Plan erstellt hat, und schalte den Planmodus aus. Im Planmodus versucht der Agent, schnell einen Plan zu erstellen. In diesem Schritt soll er aber immer wieder Fragen stellen. Gib im Chatfenster /grill-me Ich möchte die Gutscheinprüfung in den Bestellablauf integrieren ein und drücke die Eingabetaste.

grill-me wird nicht automatisch vom Agenten aufgerufen, sondern nur dann, wenn du es selbst eingibst. Es zerlegt die Anforderungen in einen „Entscheidungsbaum“ und stellt in jeder Runde alle Fragen, deren Voraussetzungen bereits geklärt sind. Jede Frage ist nummeriert und enthält eine empfohlene Antwort. Die Formulierungen sind so gewählt, dass ein einfaches „yes“ bedeutet, dass du die Empfehlung annimmst. Eine Fragerunde könnte etwa so aussehen (nur als Beispiel):

❓ Q1 – Welcher Zeitpunkt zählt für den Ablauf?: Der Zeitpunkt der Bestellung oder der erfolgreichen Zahlung?
➡️ Empfehlung: Der Zeitpunkt der Bestellung, damit der Gutschein nicht während des Bezahlvorgangs plötzlich ungültig wird.

❓ Q2 – Wird die Versandgebühr bei der Mindestsumme für den Rabatt berücksichtigt?
➡️ Empfehlung: Nein, es zählt nur die Zwischensumme der Waren.

❓ Q3 – Wie viele Gutscheine dürfen für eine Bestellung maximal verwendet werden?
➡️ Empfehlung: Einer.

Der häufigste Fehler an dieser Stelle ist, immer mit „yes“ zu antworten. Damit bestätigst du lediglich den Plan des Agenten, ohne selbst etwas entschieden zu haben. Besser ist eine abgewogene Antwort, zum Beispiel:

Q1 yes. Q2 bin ich nicht einverstanden: Laut unseren Aktionsbedingungen wird die Versandgebühr einbezogen. Q3 weiß ich nicht, das muss ich mit dem Vertrieb klären. Fürs Erste nehmen wir einen Gutschein.

Die Fragen in der nächsten Runde bauen dann auf deinen Antworten auf, zum Beispiel: „Dürfen bei einbezogener Versandgebühr Versandgutscheine und Rabattgutscheine kombiniert werden?“ Wenn eine Frage Fakten betrifft, die im Repository zu finden sind, sollte der Agent selbst einen Sub-Agenten mit der Recherche beauftragen, statt dich zu fragen. In der offiziellen Dokumentation steht, dass insgesamt mehr als 40 Fragen über vier Runden hinweg normal sind.

Daran erkennst du, dass es funktioniert hat:
– Die Fragen kommen in Runden. Jede ist nummeriert und enthält eine empfohlene Antwort, die du mit „yes“ annehmen kannst.
– Die späteren Runden bauen deutlich auf deinen vorherigen Antworten auf.
– Du hast mindestens einmal widersprochen oder ernsthaft mit „Ich weiß es nicht“ geantwortet.
– Am Ende bittet dich der Agent zuerst, zu bestätigen, dass ihr euch einig seid. Vor deiner Bestätigung unternimmt er nichts und schreibt keine Dateien.

Schritt 5: Mit /tdd immer nur einen Test auf einmal schreiben

Mach in derselben Sitzung weiter, damit der gerade aufgebaute Kontext erhalten bleibt. Bei Bedarf kannst du zu einem günstigeren Modell wechseln. Gib dann /tdd Implementiere die Coupon-Validierung nach den eben bestätigten Regeln ein.

Das Tool schreibt nicht sofort Tests. Zuerst schlägt es mögliche Schnittstellen (Seams) vor, an denen sich testen lässt, und wartet dann auf deine Bestätigung. Kandidat A wäre zum Beispiel die reine Funktion validateCoupon(coupon, order, now). Damit lässt sich die Regel-Logik abdecken, aber nicht das Zusammenspiel mit dem Bestellablauf. Kandidat B wäre die checkout()-Methode des Bestellservices. Damit lässt sich auch dieses Zusammenspiel testen, allerdings dauert der Test länger. Wenn das Tool nur die Namen nennt, frag nach, was sich mit jedem Seam erfassen lässt und was nicht. Hier entscheiden wir uns für A.

Hier ist ein Beispiel für den ersten Test mit TypeScript und Vitest. Das ist nur zur Veranschaulichung – das Vorgehen funktioniert unabhängig von Programmiersprache und Test-Framework:

Testdatei: coupon.test.ts; it und expect werden aus vitest, validateCoupon aus ./coupon importiert
Testname: Nutzer können abgelaufene Coupons nicht verwenden
Übergebener Coupon: { code: "SAVE10", minSubtotal: 100, expiresAt: new Date("2026-10-01") } – der Coupon gilt ab einem Bestellwert von 100 Yuan und läuft am 1. Oktober ab
Übergebene Bestellung: { subtotal: 120 } – Zwischensumme: 120 Yuan
Übergebener Zeitpunkt: new Date("2026-10-22"). Der Zeitpunkt wird als Parameter übergeben, statt ihn innerhalb der Funktion abzurufen. So bleibt das Ergebnis unabhängig davon, an welchem Tag der Test ausgeführt wird.
Erwartetes Ergebnis: expect(result).toEqual({ ok: false, reason: "expired" }) – die Prüfung schlägt fehl, weil der Coupon abgelaufen ist

Führe zuerst den Test aus. Er schlägt fehl, weil validateCoupon noch nicht existiert. Anschließend schreibt der Agent nur den minimal nötigen Code, damit der Test besteht – zum Beispiel eine Prüfung, die bei now >= coupon.expiresAt den Grund „abgelaufen“ zurückgibt. Erst wenn der Test grün ist, folgt der nächste, etwa „Ablehnen, wenn die Zwischensumme den Mindestbetrag nicht erreicht“. Wichtig: Der erwartete Wert ist ein Literal, das sich aus den Regeln ableitet. Der Testname beschreibt, was Nutzer tun können – nicht, dass eine interne Funktion aufgerufen wurde.

Das aktuelle tdd kennt nur noch „Rot → Grün“; eine Refactoring-Phase gibt es nicht. Sie wurde im Juni 2026 entfernt, weil der Agent diesen Schritt fast nie ausführte. Das Refactoring übernimmt jetzt /code-review. In der Skill-Beschreibung steht zwar weiterhin red-green-refactor – das ist ein bekannter Fehler, aber die Formulierung kann den Skill nach wie vor auslösen. Mocks sollten nur für Systemgrenzen wie externe APIs, Zeit und Zufallszahlen verwendet werden, nicht für eigene Module.

Das gilt als Erfolg:
– Bevor die erste Testdatei geschrieben wird, listet der Agent die Seams auf und wartet auf deine Bestätigung.
– Es erscheint immer nur ein Test: erst Rot, dann Grün, erst danach folgt der nächste. Es gibt keine Phase mit „erst einen Stapel Tests, dann einen Stapel Code“.
– Wenn du den Namen einer internen Funktion änderst, schlagen die Tests nicht fehl.

Wann Sie Skills wie grill-me und tdd einsetzen – und eine Checkliste zur Fehlerbehebung

Viele kommen nicht deshalb nicht weiter, weil sie nicht wissen, wie es geht, sondern weil sie den falschen Anwendungsfall wählen. Diese Tabelle können Sie sich speichern und bei Bedarf zu Rate ziehen.

Ihre Situation	Skill	Erläuterung
Ihre Idee ist noch vage und muss nicht unbedingt etwas mit Code zu tun haben	/grill-me	Kein Repository erforderlich, keine Dateien werden geschrieben. Der Skill eignet sich auch für geschäftliche Entscheidungen und Texte.
Sie ändern Code in einem Repository und möchten Begriffe und Entscheidungen festhalten	/grill-with-docs	Derselbe Frageprozess, aber zusätzlich werden `GLOSSARY.md` und ADRs aktualisiert.
Der Arbeitsumfang passt nicht in eine Sitzung	/wayfinder	Erstellt eine Karte mit Entscheidungs-Tickets im Issue-Tracker, die Sie nacheinander abarbeiten können.
Sie möchten ein Verhalten mit klar definierten Ein- und Ausgaben implementieren	/tdd	Eignet sich für Geschäftslogik, Request-Response-Verträge, Datentransformationen und Validierungen.
Es gibt bereits eine Spezifikation oder ein Ticket, das vollständig umgesetzt werden soll	/implement	Steuert `/tdd` entlang der vereinbarten Seams und führt vor dem Commit `/code-review` aus.

Wenn Sie nicht sicher sind, welchen Skill Sie verwenden sollen, geben Sie /ask-matt ein. Der Skill empfiehlt Ihnen anhand Ihrer Situation eine passende Lösung. Die meisten Probleme aus der Praxis lassen sich in der folgenden Tabelle nachschlagen.

Beobachtung	Häufige Ursache	Vorgehensweise
Es werden zu viele Fragen gestellt, teils über hundert	Der Umfang ist zu groß oder der Kontext ist so voll, dass die Qualität der Fragen leidet	Lassen Sie den Agenten die Arbeit in kleinere Aufgaben aufteilen und grillen Sie diese dann einzeln.
Der Prozess ist schnell vorbei und Sie sagen die ganze Zeit nur „Einverstanden“	Sie antworten zu passiv	Widersprechen Sie aktiv, weisen Sie auf eine Abweichung vom Umfang hin und sagen Sie ehrlich „Ich weiß es nicht“.
Eine Frage lässt sich auch nach wiederholtem Umformulieren nicht beantworten	Es handelt sich um eine Frage, die sich nicht im Gespräch klären lässt, etwa zum Interaktionsgefühl	Beenden Sie die Fragen und erstellen Sie mit `/prototype` einen einmaligen Prototyp zum Ausprobieren.
Sie können die Testgrenzen nicht festlegen	Für die infrage kommenden Seams wurden nur die Namen aufgeführt	Fragen Sie zuerst für jeden Seam nach, was er abdecken kann, was nicht und wie viel langsamer er ist.
Die Implementierung wurde zuerst geschrieben, die Tests erst danach	Das ist die Standardgewohnheit des Modells	Beobachten Sie die Arbeit an kritischen Ausschnitten und lassen Sie das Modell, falls nötig, zur „erst rot“-Phase zurückkehren.
Browsertests geraten in eine Endlosschleife	End-to-End-Tests wurden geschrieben, bevor die Funktion überhaupt existierte	Halten Sie in `CLAUDE.md` fest, dass Browsertests erst geschrieben werden, wenn das Verhalten funktioniert.
Die Tests kopieren lediglich die Implementierung	Für Konfiguration und Glue-Code gibt es keine unabhängige Referenzlösung	Verwenden Sie für solche Änderungen kein TDD und halten Sie die Regeln gegebenenfalls in `CLAUDE.md` fest.
Jeder Skill ist doppelt vorhanden	Sowohl das Plugin als auch skills.sh wurden installiert	Deinstallieren Sie eine der beiden Varianten.

Häufige Fragen zu mattpocock/skills (FAQ)

F1: Bedeutet eine Zahl von rund 300.000 Sternen, dass die Skills auf jeden Fall gut funktionieren?

Nein. Die Zahl der Sterne zeigt, wie viel Aufmerksamkeit das Projekt erhält, sagt aber nichts darüber aus, wie gut es in deinem Projekt funktioniert. Der Autor gibt an, auf jahrzehntelange Entwicklungserfahrung zurückzugreifen. Unabhängige Messungen, die eine Effizienzsteigerung belegen, gibt es bisher jedoch nicht. Am zuverlässigsten findest du es heraus, indem du die Abnahmekriterien aus den einzelnen Schritten dieses Artikels durchgehst und sie in deinem eigenen Repository praktisch ausprobierst.

F2: Funktionieren die Skills nur mit Tools wie Claude Code und Codex?

Nein. Die offizielle Liste enthält lediglich Installationsmethoden, die bereits getestet wurden. Nicht aufgeführte Agents lassen sich über skills.sh einbinden – entweder mit der Option `-a` oder über die interaktive Auswahl. In der README steht außerdem, dass sich die Skills mit beliebigen Modellen nutzen lassen. Im Grunde sind sie einfach als Markdown verfasste Anleitungen.

F3: Sollte ich nach den Fragen von grill-me eine neue Sitzung starten, bevor ich mit dem Programmieren beginne?

Nein. Der im Frageprozess aufgebaute Kontext ist besonders wertvoll. Laut Empfehlung solltest du in derselben Sitzung mit `/to-spec` eine Spezifikation erstellen lassen. Das kleine Beispiel in diesem Artikel macht anschließend direkt in derselben Sitzung mit `/tdd` weiter.

F4: Kann ich einstellen, dass pro Runde nur eine Frage gestellt wird, wenn mir zu viele Fragen auf einmal kommen?

Ja. Füge in deiner globalen `CLAUDE.md` einfach den Satz `When grilling, ask one question at a time.` ein. Bei Fragen in Runden siehst du jedoch auf einen Blick alle Punkte, über die du entscheiden kannst. Probiere es daher am besten ein paar Mal aus, bevor du etwas änderst.

F5: Warum beschreibt tdd den Ablauf als red-green-refactor, führt aber tatsächlich kein Refactoring durch?

Die Refactoring-Phase wurde im Juni 2026 bewusst entfernt, die Beschreibung wurde jedoch noch nicht entsprechend aktualisiert. Das Problem ist bekannt, aber noch offen. Der aktuelle Ablauf besteht aus „Rot → Grün“; das Refactoring übernimmt `/code-review`. Implementierung und Review in getrennten Sitzungen durchzuführen, funktioniert besser.

F6: Wie kann ich in der Frage- und Implementierungsphase am einfachsten unterschiedliche Modelle verwenden?

Du kannst die Konfiguration aus Schritt 3 dieses Artikels nutzen, um in Claude Code oder Codex eine einheitliche Schnittstelle einzurichten. Mit einem API-Schlüssel von APIYI (apiyi.com) kannst du in der Fragephase Claude Opus 5.5 verwenden und für die Implementierung zu einem kostengünstigeren Modell wechseln. Der API-Proxy-Dienst übernimmt lediglich den Modellaufruf; die Skills installierst du wie gewohnt.

F7: Für welche Änderungen eignet sich tdd nicht?

Änderungen an Konfigurationen und Schnittstellen, Glue-Code, Typannotationen sowie einfaches CRUD, das Daten nur weiterleitet, haben oft keine unabhängig überprüfbare Soll-Antwort. Tests laufen dann leicht darauf hinaus, die Implementierung einfach zu wiederholen. Der Autor räumt ein, dass der Skill derzeit nicht beurteilen kann, ob sich TDD für eine Änderung lohnt – diese Entscheidung musst du selbst treffen. Wenn du unsicher bist, kannst du einen leichtgewichtigen Agenten bei APIYI (apiyi.com) bitten, die Eingaben und beobachtbaren Ausgaben der Änderung aufzulisten. Kann er das nicht, solltest du tdd dafür nicht verwenden.

mattpocock/skills: Kernaussagen und Zusammenfassung

Die wichtigsten Erkenntnisse

Erst fragen, dann schreiben: Gleiche die Anforderungen zuerst mit /grill-me ab und setze sie anschließend mit /tdd um – einen Test nach dem anderen.
Eine Installationsmethode wählen: Installiere entweder das Plugin oder nutze skills.sh. Andernfalls wird jedes Skill doppelt angezeigt.
Abhängigkeiten nicht vergessen: Bei einer separaten Installation benötigt grill-me zusätzlich grilling und tdd zusätzlich codebase-design.
Aktiv antworten: Widersprich öfter und sag ruhig „Das weiß ich nicht“. Durchgehend zuzustimmen ist der häufigste Fehler.
Zuerst die Testgrenzen klären: tdd listet zunächst die Testgrenzen auf und wartet auf deine Bestätigung. Danach geht es von Rot zu Grün – ohne Refactoring.
Modelle passend auswählen: Für Rückfragen das leistungsstärkste Modell verwenden, bei der Umsetzung kann es eine kleinere Variante sein. Mit einem einzigen API-Schlüssel von APIYI kannst du zwischen Modellen wechseln.

Zusammenfassung

Der Wert von mattpocock/skills liegt nicht bei rund 300.000 Sternen, sondern darin, zwei bewährte technische Grundsätze – erst Anforderungen abgleichen, dann in kleinen Schritten validieren – in wiederholbar ausführbare Skills zu verwandeln. Gehe die fünf Schritte aus diesem Artikel durch: installieren, Setup ausführen, Modell auswählen, mit /grill-me die Anforderungen klären und mit /tdd den ersten Test von Rot zu Grün bringen. So findest du heraus, ob diese Methode zu deinem Projekt passt.

Wenn du in der Klärungs- und Umsetzungsphase unterschiedliche Modelle verwenden möchtest, kannst du mit einem einzigen API-Schlüssel über APIYI unter apiyi.com in Claude Code und Codex zwischen ihnen wechseln. Danach heißt es: die Methode an echten Anforderungen üben und konsequent aktiv antworten.

Referenzen

GitHub – mattpocock/skills: Repository mit README und allen SKILL.md-Dateien
Link: github.com/mattpocock/skills
Hinweis: Informationen zu Installationsmethoden, verfügbaren Skills und Aktualisierungen findest du hier.
AI Hero – Skills-Dokumentation: Offizielle Beschreibungen der Skills grill-me, tdd und weiterer
Link: aihero.dev/skills
Hinweis: Enthält die Abnahme-Checkliste „It’s working if“ und Antworten auf häufige Fragen.
skills.sh – mattpocock/skills: Allgemeiner Installationsweg für andere Agents
Link: skills.sh/mattpocock/skills
Hinweis: Geeignet für Tools wie Cursor, OpenCode und Windsurf; Aktualisierungen müssen manuell durchgeführt werden.

Autor: Technisches Team von APIYI
Technischer Austausch: Du erreichst uns über die Startseite von APIYI unter apiyi.com. Weitere Informationen zur Anbindung findest du im Dokumentationszentrum unter docs.apiyi.com.