TL;DR: Matt Pococks Skills-Repo hat über 160.000 GitHub-Stars, und sein Kern-Workflow passt in vier Befehle: Erst lässt du den Agenten dich ausquetschen (grill-me), dann komprimierst du die Antwort in ein Spec, schneidest es in Tickets, die je in ein Context Window passen, und lässt implementieren — aber reviewen von einem frischen Subagenten. Der Trick ist nicht Intelligenz, sondern Prozess: Der Agent schreibt keinen Code, bevor ihr euch verstanden habt, und er bewertet seine eigene Arbeit nicht selbst.
Das Problem: Der Agent tippt schneller, als ihr denkt
Die meisten AI-Coding-Projekte scheitern nicht an der Modellqualität, sondern daran, dass Design-Fragen nie gestellt wurden. Mensch und Agent starten mit einer vagen Idee ins Chat-Fenster, der Agent legt los, und zwanzig Minuten später entsteht ein PR, den niemand so bestellt hat — Halbfertig-Spaghetti, weil keiner das Design durchdacht hat, bevor das Tippen anfing.
Matt Pocock, bekannt für seine TypeScript-Kurse, hat gegen genau das ein Set von Skills gebaut: sein persönliches .agents-Verzeichnis, öffentlich gemacht unter github.com/mattpocock/skills. Inzwischen über 160.000 Stars und Millionen Downloads — und seit Kurzem auch ein offizielles End-to-End-Tutorial dazu.
Die Grundhaltung: Alignment vor Code. Klug ist der Agent schon. Was fehlt, ist ein Prozess, der die Denk-Arbeit erzwingt, die vorher niemand gemacht hat.
Phase 1: grill-me — die automatisierte, diskussionsfreudige Gumti-Ente
Der wohl beliebteste Skill im Repo besteht aus drei Sätzen. Er tut nichts Spektakuläres: Er stellt die richtige Frage zum richtigen Zeitpunkt. Statt in den Planungsmodus zu gehen, lässt du den Agenten dich ausquetschen — eine Frage nach der anderen, bis beide dasselbe Verständnis von Ziel, Randbedingungen und Risiken haben.
Vor AI-Zeiten hieß das Rubber Ducking. Der Unterschied: Der Grill-Prozess macht aus der Rubber Duck eine diskussionsfreudige Ente, die widerspricht, Lücken sucht und Annahmen markiert, die du stillschweigend vorausgesetzt hast.
Die gesteigerte Variante /grill-with-docs pflegt zusätzlich ein CONTEXT.md mit Projekt-Vokabular und nutzt Architectural Decision Records (ADRs), damit nicht-offensichtliche Entscheidungen dokumentiert statt nur im Chat-Verlauf begraben werden.
Phase 2: to-spec — aus Diskussion wird Artefakt
Nach dem Grillen folgt die Gabelung im Flow: Passt die Arbeit in eine Session, gehst du direkt zu Implementierung. Braucht sie mehrere Sessions, komprimierst du die Diskussion mit /to-spec in ein Detailed Spec — das Ziel, User Stories, Implementierungs- und Test-Entscheidungen, geschrieben in den Issue-Tracker, nicht in eine Chat-Nachricht.
Das Spec ist der Anker, auf den sich später alles zurückführen lässt: jedes Ticket, jeder Review-Kommentar, jeder Commit. Ohne dieses Artefakt ist "fertig" nur ein Gefühl.
Phase 3: to-tickets — ein Ticket pro Context Window
/to-tickets schneidet das Spec in Scheiben, die jeweils in ein Context Window passen. Pococks Beispiel aus dem Tutorial: Ein Spec wurde zu elf Sub-Issues.
Warum diese Härte? LLMs haben eine verlässliche "Smart Zone". Je voller der Kontext, desto mehr vergisst der Agent über Konventionen, Randfälle und frühere Anweisungen. Ein Ticket, das unterhalb dieser Grenze bleibt (grob unter ~140K Tokens used context), wird zuverlässiger gebaut als ein Mega-Ticket, das drei Sessions lang im Gedächtnisbauch einer einzigen Konversation lebt.
Wichtig beim Schnitt: Die Tickets sollten vertikale Scheiben sein — ein durchgängiger funktionaler Querschnitt statt "erst die DB, dann das UI, dann die Tests". Dann ist jedes Ticket allein testbar.
Phase 4: implement — und vor allem: Review mit frischem Kontext
Der /implement-Skill arbeitet ein Ticket ab: Type Checks, Build, TDD an den vorher vereinbarten Nähten — und zum Abschluss /code-review, ausgeführt in Subagenten.
Das ist der Punkt, an dem die meisten Setups es sich einfach machen: Der Main-Agent reviewt seinen eigenen Code — im selben verbrauchten Kontext, in dem er ihn geschrieben hat. Das Ergebnis ist wohlwollend bis blind. Ein sauberer Kontext reviewt ehrlicher, weil er keine Rechtfertigungslogik mitschleppt.
Pococks Code-Review fährt darum zwei Achsen als parallele Subagenten, die sich gegenseitig nicht kontaminieren:
| Achse | Frage | Referenz |
|---|---|---|
| Standards | Hält sich der Diff an Coding-Standards und klassische Code-Smells? | codingstandards.md im Repo + Smell-Baseline |
| Spec | Implementiert der Code tatsächlich das Original-Ticket/Spec? | Ursprüngliches Issue/Spec |
In Pococks eigenem Setup laufen die Implementierungs-Subagenten in Sandcastle, seinem Orchestrator für sandboxed Coding-Agents. Für den Alltag funktioniert der Flow aber genauso mit normalen Subagenten — das Prinzip ist die frische Kachel, nicht das Tool.
Setup in zwei Befehlen
npx skills@latest add mattpocock/skills
/setup-matt-pocock-skills
Der Setup-Skill konfiguriert Issue-Tracker, Triage-Labels und Dokument-Layout einmal pro Repo. Danach läuft der Flow in fester Reihenfolge: grill → (spec → tickets) → implement. Wer nur die Essenz will: grill-me funktioniert auch komplett für sich — die Drei-Satz-Version kostet null Infrastruktur und ist der ROI-stärkste Einzelskill.
Der Flow im Überblick
| Phase | Befehl | Artefakt | Dauer |
|---|---|---|---|
| Alignment | /grill-me oder /grill-with-docs | Geteiltes Verständnis, CONTEXT.md | 10–30 Min |
| Verdichten | /to-spec | Spec im Tracker | einmalig |
| Schneiden | /to-tickets | Tickets à ein Context Window | einmalig |
| Bauen | /implement + /code-review | PR mit frischem Review | pro Ticket |
❌ So nicht — ✅ so
- ❌ Prompt rein, Code raus, PR auf — ✅ erst grillen lassen, Fragen beantworten, dann Spec
- ❌ "Mach mal das ganze Feature" in einem Chat — ✅ ein Ticket pro Context Window
- ❌ Main-Agent reviewt eigenen Code im vollen Kontext — ✅ frischer Subagent, zwei getrennte Achsen
- ❌ Entscheidungen nur im Chatverlauf — ✅ Spec und ADRs im Tracker, Version für Version
Wann der Flow Overkill ist
Fairerweise: Für einen Zwei-Zeilen-Fix oder einen Throwaway-Prototype ist der volle Vier-Phasen-Zug zu lang. Der Flow lohnt ab dem Punkt, an dem ein Feature mehrere Sessions überleben muss, andere Leute (oder Agents) später daran weiterarbeiten, oder du selbst morgen nicht mehr weißt, warum du dich für Variante B entschieden hast. Genau dafür ist das Repo gemacht — "Skills for Real Engineers", nicht für Prompt-Spielereien. Für Arbeit, die größer ist als eine Agenten-Session überhaupt fassen kann, gibt es im Repo übrigens noch /wayfinder — ein Karten-System aus Decision-Tickets auf dem Tracker.
FAQ
Womit fange ich an, wenn mir der ganze Flow zu viel ist?
Mit /grill-me allein. Der Skill besteht aus drei Sätzen, braucht keine Konfiguration und ändert sofort, wie du planst: Der Agent stellt dir so lange eine Frage nach der anderen, bis ihr dasselbe Bild vom Ziel habt. Der Rest des Flows (spec, tickets, review) baut darauf auf, ist aber einzeln nachrüstbar. Wer nur eine Sache aus diesem Artikel mitnimmt, sollte vor dem nächsten Feature-Anfang den Agenten sich ausquetschen lassen statt selbst loszuprompten.
Brauche ich Sandcastle oder Pococks exakte Toolchain?
Nein. Sandcastle ist Pococks eigenes Tool zur Orchestrierung sandboxed Coding-Agents, aber der Flow funktioniert mit jedem Agenten-Setup, das Subagenten oder zumindest frische Sessions kann — Claude Code, Codex, OpenClaw, was auch immer. Der übertragbare Kern ist die Regel "Implementierung und Review laufen in getrennten, frischen Kontexten", nicht das konkrete Tool. Selbst der Review-Teil lässt sich primitiv umsetzen: neuen Chat auf, Diff rein, zwei Achsen abfragen.
Wie groß darf ein Ticket höchstens sein?
Als Faustregel: Es muss inklusive Codebasis-Kontext und Diskussion in ein einziges Context Window passen und dabei in der verlässlichen Zone des Modells bleiben — grob unter etwa 140K Tokens used context, je nach Modell auch deutlich darunter. Ein gutes Zeichen ist, dass du das Ticket in einer Session mit grünen Tests abschließen kannst. Wenn ein Ticket nach "Phase 1 von 3" klingt, ist es zu groß geschnitten — dann lieber noch einmal teilen.
Was ist der Unterschied zwischen grill-me und grill-with-docs?
/grill-me ist die schnelle Variante: Der Agent stellt Fragen, ihr redet, bis das Verständnis geteilt ist — fertig. /grill-with-docs führt dieselbe Befragung, pflegt aber persistente Artefakte: ein CONTEXT.md als Glossar deiner Domäne und Architectural Decision Records für die nicht-offensichtischen Entscheidungen. Für Einmal-Arbeit reicht grill-me, in einem Team-Repo mit Historie zahlt sich die Docs-Variante ab der zweiten Woche aus.
Warum soll ein Fremder meinen Code reviewen statt der Agent, der ihn geschrieben hat?
Weil der schreibende Agent befangen und blind ist: Sein Kontext ist voll von den Kompromissen und Irrtümern, die zum Code geführt haben, und Modelle neigen dazu, die eigene Leistung wohlwollend zu beurteilen. Ein frischer Subagent sieht nur Diff, Standards und Spec — und meldet Smells ehrlicher, gerade weil er keine eigene Leistung verteidigt. Der Zwei-Achsen-Ansatz (Standards parallel zu Spec-Treue) verhindert zusätzlich, dass Review-Kommentare aus einem Kanal den anderen kontaminieren.
Läuft das mit Claude Code nur oder auch mit anderen Agenten?
Das Format (Skills als SKILL.md-Dateien im Agenten-Verzeichnis) ist bewusst Cross-Tool angelegt und funktioniert in Claude Code, Codex und anderen Harnesses, die Ordner-basierte Skills laden. Der Installer (npx skills add mattpocock/skills) legt die Dateien entsprechend ab, /setup-matt-pocock-skills passt Tracker und Layout an dein Repo an. Welche Modell-Qualität darunter liegt, ist dem Flow egal — er strukturiert ja gerade den Prozess rund um das Modell.
Sources
- Matt Pocock: Skills-Repo — https://github.com/mattpocock/skills
- Matt Pocock: End-to-End-Tutorial des Workflows (X) — https://x.com/mattpocockuk/status/2075218406266036236
- Matt Pocock: Workflow-Tutorial (YouTube) — https://www.youtube.com/watch?v=M6mYodf0dJM
- Matt Pocock: Skills Changelog v1.1 (/wayfinder, /to-spec, /to-tickets, Code-Review-Achsen) — https://www.aihero.dev/skills/skills-changelog-v1-1-wayfinder-to-spec-to-tickets-grilling-improvements
- Matt Pocock: AI-Coding-Workshop mit Sandcastle (YouTube) — https://www.youtube.com/watch?v=-QFHIoCo-Ko
- Alex Rusin: "Matt Pocock Skills: The Main Flow Explained" — https://blog.alexrusin.com/matt-pocock-skills-main-flow
- Aditya Kumar Puri: "Matt Pocock's Claude Code Skills made me rewrite how I work with AI agents" — https://adityakumarpuri.medium.com/matt-pococks-5-claude-code-skills-made-me-rewrite-how-i-work-with-ai-agents-d71853c3056c
- Danny Shmueli: Subagents + Pocock-Skills in Hermes — https://dannyshmueli.com/2026/04/29/Matt-Pocock-Skills-Hermes-Subagents-Feature-Work/