Matt Pococks Skills-Pack: ein Workflow aus Grillen, Spec, Ticket, Umsetzung, Review

Vibe Coding macht großen Spaß, bis der Code auf ein echtes Produkt trifft. Du beschreibst ein Feature, der Agent nickt und produziert einen Berg Code, und ein Pull Request taucht auf, der sehr geschäftig aussieht. Dann kommen die Probleme hoch. Das Verhalten ist nicht ganz das, was das Team im Kopf hatte, die Erklärung ist voller Fachjargon, ein Randfall bricht den Checkout, und der bestehende Code ist still schwerer zu ändern geworden.

Dass ein Agent schlechten Code schreibt, ist nicht der beängstigende Teil, denn das tun Menschen auch. Der beängstigende Teil ist, dass ein Agent ein Missverständnis beschleunigt. Eine unscharfe Anfrage wird zu einem großen, überzeugenden und teuren Fehler.

Matt Pococks Skills-Repository ist eine praktische Antwort darauf. Seine README nennt sich „Skills For Real Engineers“: kleine Anweisungen, die man aufrufen kann, wenn eine bestimmte Art von Hilfe gebraucht wird. Die Idee ist nicht, den ganzen Entwicklungsprozess an ein riesiges Framework abzugeben. Sie ist, dem Agenten eine Handvoll verlässlicher Spielzüge für die Momente zu geben, in denen ingenieurmäßiges Urteil zählt.

Der Agent verdient sein Geld, indem er zuerst auf den gefährlichen Abschnitten einer Aufgabe bremst und erst danach das Tippen beschleunigt.

Was das Pack enthält

Das Repository ist ein Satz kombinierbarer Skills für die Arbeit mit einem Agenten innerhalb einer bestehenden Codebasis. Ein Skill prüft eine Idee kritisch, ein anderer wandelt sie in eine Spec um, ein weiterer teilt die Spec in Tickets, und Umsetzung und Review bekommen je einen eigenen, fokussierten Skill.

Dieses Versprechen ist kleiner als „die ganze Firma durch diese Methodik jagen“, und es ist nützlicher. Das Repo behält seine eigenen Konventionen, seinen Tracker, seine Dokumentation und Architektur, und die Skills helfen dem Agenten, sich darin zurechtzufinden.

Pro Repository ist ein einmaliges Setup nötig. Installiere das Pack mit einer dieser beiden Optionen, niemals mit beiden:

claude plugins install mattpocock-skills

oder:

npx skills@latest add mattpocock/skills

Führe dann dies einmal innerhalb des Repos aus:

/setup-matt-pocock-skills

Während des Setups lernt der Agent das lokale Layout kennen, inklusive Issue-Tracker, Triage-Labels und Dokumentationspfaden. Es ist keine tägliche Routine. Es ist Kontext, der sonst immer wieder neu entdeckt, erraten oder vergessen würde.

Warum ein Prompt nicht reicht und ein riesiger Prozess auch nicht

Ein Prompt äußert einen Wunsch. Er kann nicht verlässlich alle Entscheidungen tragen, die in einem kurzen Produktsatz versteckt sind.

„Gespeicherte Warenkörbe zum Shop hinzufügen“ klingt klar, bis jemand fragt, was ein gespeicherter Warenkorb enthält, wer ihn sehen darf, was bei Bestandsänderungen passiert, ob Preise festgeschrieben werden und wohin das Feature gehört. Ein einzelner Prompt begräbt diese Fragen unter einem Befehl: bau es.

Die Gegenreaktion ist ein schwergewichtiger Prozess, der behauptet, jedes Projekt gleich zu behandeln. Er tauscht Mehrdeutigkeit gegen Zeremonie, selbst wenn die Aufgabe winzig ist oder das Repo schon eine gute Routine hat. Der Prozess wird zum Produkt.

Dieses Pack sitzt zwischen beiden. Fokussierte Skills zielen auf fokussierte Fehlerbilder. Eine Idee lässt sich grillen, eine haltbare Spec lässt sich schreiben, wenn eine gerechtfertigt ist, und Tickets lassen sich auf den verwendeten Tracker zuschneiden. Für einen einzeiligen Tippfehler lässt sich fast all das überspringen. Verglichen mit einem Framework, das den gesamten Workflow übernimmt, sind kleine Skills einfacher zu kombinieren, zu lesen und auszutauschen.

Die Fehlerbilder, auf die es zielt

Die README hilft, weil sie bestimmte Fehlerbilder benennt und KI-Coding nicht als eine einzige magische Tätigkeit behandelt.

• Fehlausrichtung. Der Agent baut eine plausible Lesart, die nicht die gemeinte ist. grill-me verhört die Idee direkt, und grill-with-docs bringt die Dokumentation des Repositorys und den Domänenkontext ins Gespräch.
• Wortreicher Jargon. Eine Antwort kann selbstsicher klingen und das Produkt trotzdem verwirrender hinterlassen als zuvor. Der dokumentationsorientierte Ablauf kann Kontext in CONTEXT.md und in ADRs festhalten, und domain-modeling macht zentrale Begriffe explizit, damit sie sich nicht in Namen wie data, item oder manager auflösen.
• Code, der nicht funktioniert. Für testgetriebene Umsetzung verweist der Workflow auf /tdd und auf diagnosing-bugs, wenn ein fehlerhaftes Verhalten eine Untersuchung statt eines weiteren spekulativen Patches braucht.
• Ein Schlammklumpen. Wenn ein Feature nirgends passt, ist noch eine Abstraktion nicht immer die Kur. to-spec, improve-codebase-architecture und codebase-design machen die Form des Systems sichtbar und helfen, sie bewusst zu verbessern.

Ein paar Routing- und Koordinations-Skills runden das Ganze ab. ask-matt hilft, einen Weg zu wählen, wayfinder unterstützt Pläne über mehrere Sitzungen, handoff bewahrt den Zustand, wait-what prüft das Verständnis und triage sortiert, was als Nächstes passieren soll.

Die Pipeline

Der Kernablauf verkettet fünf Schritte:

/grill-with-docs -> /to-spec -> /to-tickets -> /implement -> /code-review

Unter der Haube steuert /implement das /tdd. Jeder Schritt hat eine Aufgabe, und seine Ausgabe gibt dem nächsten Schritt etwas Konkretes an die Hand.

1. Die Idee grillen

Beginne mit /grill-with-docs, wenn ein Feature produktliche und technische Belange umspannt. Beschreibe, was gewünscht ist, und bitte den Agenten, die Annahmen anhand der Dokumentation des Repositorys infrage zu stellen.

Im Beispiel des gespeicherten Warenkorbs kommen die nützlichen Fragen vor jedem Code. Ist ein gespeicherter Warenkorb an ein Konto gebunden? Darf ein Kunde mehrere behalten? Prüft das Wiederherstellen Bestand und Preis erneut? Ist es eine Momentaufnahme oder ein Zeiger in den Live-Katalog? Lässt er sich teilen? Was sieht der Nutzer, wenn ein Produkt eingestellt wurde?

Das Ziel ist kein endloses Interview. Es geht darum, die Entscheidungen hervorzuholen, die sonst, offen gelassen, standardmäßig von der Umsetzung getroffen würden.

Wenn die Idee schon gut verstanden ist, reicht das leichtere grill-me. Fängt der Agent an, Begriffe zu benutzen, die das Team nicht verwendet, bitte um eine CONTEXT.md, ein ADR oder einen Domain-Modeling-Durchgang. Ein kurzes gemeinsames Vokabular ist mehr wert als eine lange Antwort.

2. Entscheidungen in eine Spec überführen

Mit den Antworten in der Hand führe /to-spec aus. Eine Spec nennt, was das Feature tut, was es nicht tut und woran das bestehende System einen Erfolg erkennt.

Nimm einen TypeScript-Shop. Seine Spec könnte einen gespeicherten Warenkorb als benannte Liste beschreiben, die einem eingeloggten Kunden gehört. Gespeichert werden nur Produkt-IDs und Mengen, ohne eingefrorene Preise oder Bestandszahlen. Beim Wiederherstellen wird die Verfügbarkeit erneut geprüft, und Zeilen, die nicht erfüllbar sind, laufen durch die schon vorhandene Fehlerbehandlung. Gäste werden zum Anmelden aufgefordert.

Das ist weit wertvoller als „gespeicherte Warenkörbe hinzufügen“. Das Team bekommt etwas Konkretes zum Prüfen, und der Agent bekommt Grenzen. Steht öffentliches Teilen nicht in der Spec, sollte das niemand als Einladung lesen, es zu erfinden. Eine Spec macht wichtige Entscheidungen prüfbar, bevor sie zu Code werden.

3. Die Spec in Tickets überführen

Führe /to-tickets aus, sobald die Spec stabil genug zum Aufteilen ist. Tickets sollten Scheiben beschreiben, die sich bauen und prüfen lassen, und keine Liste vager Abteilungen. Ein sinnvoller Weg, dieses Feature zu schneiden:

1. Domänenmodell und Speicherschicht für Warenkörbe, die eingeloggten Kunden gehören.
2. Kommandos plus Validierung für Speichern, Auflisten, Umbenennen, Löschen und Wiederherstellen.
3. Ein Wiederherstellungsschritt, der Bestand und heutige Preise erneut prüft.
4. Shop-Bildschirme, inklusive Lade-, Leer- und Fehlerzuständen.
5. Integrationstests für Zugriffsregeln, fehlende Produkte und ein sauberes Wiederherstellen.

Das Ticketformat sollte dem Tracker und den Konventionen des Repos folgen, was einer der Gründe ist, warum der Setup-Befehl zählt: Die Skills können den Tracker des Projekts, die Labels und die Doku-Pfade nutzen. Tickets wirken außerdem als natürlicher Haltepunkt. Vielleicht braucht das erste Release nur Speichern und Wiederherstellen. Den Umfang hier zu kürzen, ist besser, als ihn nach der Umsetzung zu kürzen.

4. Mit Tests voran umsetzen

Führe nun /implement aus. Es steuert /tdd, der Agent geht also von beobachtbarem Verhalten aus, schreibt einen fehlschlagenden Test, macht die kleinste Änderung, die ihn besteht, und hält die Testsuite im Spiel, während er die Tickets abarbeitet.

Im Shop-Fall übersetzt sich das in drei Tests: ein eingeloggter Kunde kann einen Warenkorb speichern, ein anderer Kunde kann ihn nicht lesen, und das Wiederherstellen eines Warenkorbs weist jede Zeile ab, deren Produkt verschwunden ist. Der Code sollte innerhalb der aktuellen Domänen- und Persistenzgrenzen des Repositorys bleiben. Eine zweite, parallele Warenkorb-Abstraktion ist nicht nötig, bloß weil der Prompt einen „gespeicherten Warenkorb“ erwähnte.

Schlägt ein Test fehl, bitte nicht um zufällige Änderungen, bis das Rot grün wird. Nutze diagnosing-bugs, um zu untersuchen. Sieh einen fehlschlagenden Test als Beleg über das System und nicht als Hürde auf dem Weg zum grünen Haken.

Manchmal zeigt die Arbeit, dass die Spec falsch lag. Dann ist der richtige Zug, zu ihr zurückzukehren, denn nichts zwingt diesen Workflow, geradlinig zu laufen. Das Ziel ist, Entscheidung, Ticket, Test und Code dieselbe Geschichte erzählen zu lassen, und nicht, zu schützen, was zuerst geschrieben wurde.

5. Das Ergebnis reviewen

Schließe mit /code-review ab. Das ist mehr als eine Stilprüfung. Reviewer suchen nach Übereinstimmung zwischen Verhalten und Spec, nach Tests, die wirklich die wichtigen Fälle abdecken, nach Respekt vor der schon vorhandenen Architektur und einer möglichst klein gehaltenen öffentlichen Oberfläche.

Ein solides Review könnte Wiederherstellungslogik aufdecken, die in einen Checkout-Service gehört, der schon in der Codebasis liegt, einen Listen-Endpunkt ohne Autorisierungsprüfung oder eine UI, die Leute ein nicht mehr verfügbares Produkt kaufen lässt. Es könnte auch finden, dass das Feature korrekt ist, während die Modulgrenze schwerer nachzuvollziehen wurde. Dann können improve-codebase-architecture oder codebase-design als Folgeschritt helfen, statt als Ritual, das jeder Änderung aufgezwungen wird.

Das abschließende Review schützt die Codebasis vor einem Feature, das nur seine eigenen engen Tests bestanden hat.

Was es auszeichnet

Der Workflow trennt Denkarten, die Agenten gern verwischen. Eine Produktentscheidung zu klären ist nicht das Entwerfen eines Moduls, ein Modul zu entwerfen ist nicht das Schreiben eines Tests, und ein bestehender Test beweist nicht, dass das Feature in die aktuelle Architektur gehört.

Das Urteil bleibt in menschlicher Hand. Du kannst nach dem Grillen anhalten, die Spec umschreiben, einen vorgeschlagenen Ticket-Schnitt verwerfen oder ask-matt den passenden Skill vorschlagen lassen. wayfinder deckt Pläne über mehrere Sitzungen ab, handoff bewahrt den Kontext, wait-what prüft eine verwirrende Anfrage und triage wählt das nächste Stück Arbeit.

Das passt besser zu echter Ingenieursarbeit als ein Prompt, der sagt „sei ein Senior-Entwickler“. Der Agent bekommt wiederholbare Verhaltensweisen, ohne so zu tun, als wäre Expertise ein Charakterzug.

Wann man es weglässt

Für einen einzeiligen Tippfehler, eine kleine Textänderung oder ein lokales Wegwerfexperiment ist das Ganze übertrieben. Das Setup hat seinen Preis, auch wenn er nur einmal pro Repo anfällt, und bewusste Pausen sind nicht umsonst, wenn die Änderung wirklich trivial ist.

Nutze den gesunden Menschenverstand. Änderungen, die Geschäftsregeln, Modulgrenzen, gespeicherte Daten, Berechtigungen oder eine öffentliche API berühren, rechtfertigen die Pause, denn sie kostet weniger als das Aufräumen nach einem selbstsicheren Missverständnis. Alles andere darf die Abkürzung nehmen.

Klein anzufangen funktioniert gut. Wähle einen Installationsweg, führe /setup-matt-pocock-skills in einem echten Repository aus und probiere /grill-me am nächsten Feature, das klar wirkt, es aber nicht ist. Verdient eine Änderung den vollen Weg, erweitere den Lauf über /grill-with-docs und weiter zu Specs, Tickets, /implement und /code-review.

Der Gewinn ist keine höhere Zeilenzahl pro Stunde. Es landen von vornherein weniger falsche Annahmen im Code. Das ist ein weit weniger glamouröses Versprechen als Vibe Coding, und es ist das, das noch hält, wenn der Shop live ist und ein anderer Entwickler erbt, was der Agent hinterlassen hat.