Matt Pococks Agent Skills: Engineering statt Vibe Coding?

Was sind Matt Pococks Agent Skills?

Matt Pococks Agent Skills sind weder ein eigenes KI-Modell noch eine eigenständige Agenten-Runtime. Das Repository enthält vor allem Markdown-basierte `SKILL.md`-Dateien, Referenzdokumente, Setup-Anweisungen und Plugin-Manifeste. Ausgeführt werden diese Anweisungen vom jeweiligen Coding-Agenten, etwa Codex oder Claude Code.

Die Projektidee ist bewusst schmal. Statt einen vollständigen Softwareentwicklungsprozess zu übernehmen, soll jeder Skill eine klar begrenzte Engineering-Disziplin abbilden. `/tdd` beschreibt einen testgetriebenen Red-Green-Loop und verschiebt Refactoring ausdrücklich in die Review-Phase, `/diagnosing-bugs` strukturiert die Fehlersuche und `/code-review` trennt die Prüfung gegen Projektstandards von der Prüfung gegen die Spezifikation.

Die README stellt diese Sammlung ausdrücklich GSD, BMAD und Spec Kit gegenüber. Laut Pocock nehmen solche Systeme dem Entwickler zu viel Kontrolle ab und machen Prozessfehler schwerer korrigierbar. Das ist die Positionierung des Autors, kein unabhängiger Nachweis dafür, dass kleine Skills generell bessere Ergebnisse liefern.

Die GitHub-Sterne zeigen außergewöhnlich hohe Aufmerksamkeit, aber weder aktive Installationen noch Softwarequalität. Auch die Abweichung zwischen `package.json`- und Plugin-Version ist zunächst nur Versionsdrift. Sie beweist für sich genommen keinen Funktionsfehler.

Warum ist das ein Gegenentwurf zu Vibe Coding?

Vibe Coding optimiert zunächst auf Geschwindigkeit: Absicht beschreiben, Code generieren lassen, Ergebnis ausprobieren. Das funktioniert bei Prototypen erstaunlich gut. In größeren Codebasen entstehen die Probleme dort, wo Anforderungen unklar sind, Feedback-Schleifen fehlen oder niemand mehr nachvollziehen kann, warum eine Architekturentscheidung getroffen wurde.

Pococks Skills setzen genau an diesen Übergängen an:

• `/grill-with-docs` soll Anforderungen durch ein strukturiertes Interview klären und ein gemeinsames Domänenvokabular dokumentieren.
• `/to-spec` verdichtet den bereits geklärten Stand in eine Spezifikation, ohne ein neues Interview zu beginnen.
• `/to-tickets` zerlegt die Spezifikation in umsetzbare Arbeitspakete mit Abhängigkeiten.
• `/implement` verbindet die Umsetzung an vorher vereinbarten Schnittstellen mit TDD und Code Review.
• `/handoff` komprimiert den Arbeitsstand für eine neue Agenten-Session.

Der technische Kern ist nicht deterministischer Output. Ein Sprachmodell bleibt stochastisch. Die Skills sollen vielmehr den Prozess vorhersehbarer machen: gleiche Arbeitsschritte, explizite Completion Criteria, weniger implizite Annahmen und ein gemeinsames Vokabular. Der Skill `writing-great-skills` beschreibt dazu Progressive Disclosure: Detailwissen wandert in Referenzdateien und wird erst geladen, wenn es wirklich gebraucht wird.

Das ist Engineering statt blindem Prompten, aber noch keine Durchsetzungsschicht. Ein Skill kann den Agenten zu Tests anweisen. Er kann nicht garantieren, dass die Tests sinnvoll sind, vollständig laufen oder einen Fehler tatsächlich abdecken. Dafür brauchst du weiterhin den passenden Agent-Harness aus Tools, Logs und Berechtigungen, eine CI-Pipeline und menschliches Review.

Welche 22 Skills gehören zum öffentlichen Kern?

Das Claude-Plugin-Manifest listet 22 ausgelieferte Skills. Daneben enthält das Repository experimentelle, persönliche, veraltete und sonstige Skill-Bereiche. Für den beworbenen Plugin-Umfang ist deshalb das kuratierte Manifest maßgeblich, nicht jeder auffindbare `SKILL.md`-Pfad.

Eine wichtige Trennung betrifft den Aufruf. Laut Repository-Referenz starten User-invoked Skills nur nach einem expliziten Nutzeraufruf und orchestrieren den Ablauf. Model-invoked Skills darf das Modell bei einer passenden Aufgabe automatisch laden. Dadurch muss nicht die komplette Methodik permanent im Kontext liegen.

Diese Granularität ist die eigentliche Stärke des Projekts. Du kannst nur den Diagnose-Loop übernehmen, ohne gleichzeitig Pococks Ticketstruktur, Issue-Labels und vollständigen Implementierungsablauf einzuführen. Umgekehrt entsteht dadurch Integrationsarbeit: Dein Team muss entscheiden, welche Skills verbindlich sind, wie sie zu bestehenden Regeln passen und wer Änderungen daran prüft.

Wie sieht ein typischer Engineering-Workflow aus?

Die Skills lassen sich zu einer vollständigen Kette verbinden, müssen aber nicht immer gemeinsam laufen.

Der Ablauf ähnelt klassischer Softwareentwicklung: erst verstehen, dann spezifizieren, zerlegen, implementieren und prüfen. Der Mehrwert liegt nicht in einer neuen Methode, sondern in der Übersetzung etablierter Praktiken in wiederverwendbare Agentenanweisungen.

Genau deshalb solltest du die Sammlung nicht komplett installieren und sofort als Standardprozess behandeln. Wähle zuerst einen klaren Engpass. Wenn dein Agent vorschnell Fehler behebt, teste `/diagnosing-bugs`. Wenn Anforderungen regelmäßig verwässern, beginne mit `/grill-with-docs` und `/to-spec`. Kleine Skills sind nur dann ein Vorteil, wenn du sie auch klein einführst und ihre Wirkung beobachten kannst.

Wie installierst du die Skills für Codex und Claude Code?

Der universelle Weg führt über die Skills CLI. Sie kopiert ausgewählte Skills in den Projektkontext des gewünschten Agenten:

npx skills@latest add mattpocock/skills

Danach sollst du laut Quickstart `/setup-matt-pocock-skills` einmal pro Repository ausführen. Der aktuelle Setup-Skill konfiguriert den Issue-Tracker, bei installiertem `/triage` die Label-Bezeichnungen und die Domain-Dokumentstruktur des Repositories.

Für die Recherche wurde die Installation eines einzelnen Skills außerhalb eines Nutzerprojekts mit der Skills CLI 1.5.20 in einem isolierten temporären Home-Verzeichnis reproduziert:

npx -y skills@1.5.20 add mattpocock/skills \
  --skill grill-me \
  --agent codex \
  --yes

Der Befehl endete mit Exit-Code 0, legte `grill-me` unter `.agents/skills/grill-me/` ab und erzeugte eine `skills-lock.json`. `npx skills list –json` erkannte den Skill anschließend mit der Quelle `mattpocock/skills` und dem Scope `project`. Dieser Test belegt Installation und Erkennung, nicht die Wirksamkeit des Interview-Workflows in realer Projektarbeit.

Claude Code bietet zusätzlich ein natives, verwaltetes Plugin. Die README dokumentiert dafür diese Befehle innerhalb von Claude Code:

/plugin marketplace add mattpocock/skills
/plugin install mattpocock-skills@mattpocock

Die beiden Installationswege folgen unterschiedlichen Modellen. Die Skills CLI erzeugt bearbeitbare Projektkopien. Das Claude-Code-Plugin liefert ein verwaltetes, schreibgeschütztes Bundle. Ein natives Codex-Plugin ist laut Architecture Decision Record zurückgestellt, weil das Codex-Manifest den kuratierten Inhalt aus mehreren Skill-Verzeichnissen derzeit nicht sauber als Liste abbildet. Codex-Nutzer können die Skills trotzdem über die Skills CLI installieren.

Wichtig: Der geschlossene Issue #196 klärt den Updatepfad: `npx skills@latest update` aktualisiert die in `skills-lock.json` erfassten Skills. Der Thread warnt, dass lokale Änderungen an verwalteten Skill-Dateien dabei überschrieben werden können; einen konkret eingetretenen Datenverlust belegt er nicht. Versioniere Anpassungen und prüfe den Update-Diff wie bei einer Code-Abhängigkeit.

Was unterscheidet die Sammlung von Spec Kit, BMAD und Superpowers?

Die vier Projekte lösen verwandte Probleme, gehören aber nicht zur exakt gleichen Produktklasse. Ein Sieger-Ranking wäre deshalb irreführend.

Die folgende Gegenüberstellung fasst ausschließlich die Selbstdarstellung der vier offiziellen Repository-READMEs zusammen; sie ist weder ein Wirksamkeitsvergleich noch ein Sieger-Ranking.

Spec Kit passt, wenn ein Team eine gemeinsame Spec-Driven-Development-Pipeline einführen will. BMAD geht weiter in Richtung eines virtuellen agilen Teams mit Rollen und umfangreichen Workflows. Superpowers setzt stärker auf automatisch greifende methodische Disziplin. Pococks Sammlung ist interessanter, wenn erfahrene Entwickler die Kontrolle behalten und nur bestimmte Praktiken standardisieren wollen.

Der Preis dieser Freiheit ist fehlende Einheitlichkeit. Zwei Entwickler können aus derselben Sammlung völlig unterschiedliche Abläufe bauen. Das ist in einem kleinen, erfahrenen Team oft erwünscht. Für Organisationen, die einen verbindlichen Prozess mit klaren Artefakten und Freigaben brauchen, kann ein stärker vorgegebenes System einfacher zu kontrollieren sein.

Wo liegen die Grenzen und Risiken?

Prompt-Gates sind keine Runtime-Gates

Die Regeln stehen überwiegend in natürlicher Sprache. Das Modell kann sie missverstehen oder überspringen. Issue #221 berichtet beispielsweise, dass beim Grilling mehrere Fragen gebündelt wurden, obwohl eine Frage pro Schritt vorgesehen war. Issue #540 beschreibt einen Wayfinder-Lauf, in dem Human-in-the-Loop-Entscheidungstickets im autonomen Queue-Modus übersprungen wurden.

Das sind konkrete Praxisberichte, keine Häufigkeitsmessung. Sie zeigen aber die Grenze des Ansatzes: Wo ein Schritt wirklich verpflichtend ist, brauchst du technische Gates in CI, Berechtigungen, Statusautomaten oder eine explizite menschliche Freigabe.

Subagenten können unkontrolliert auffächern

Die Skills `research` und `code-review` arbeiten mit delegierten Agenten. Issue #530 und Issue #573 dokumentieren Fälle rekursiver Agentenstarts. Das kann Laufzeit und Tokenverbrauch erhöhen. Ob der konkrete Fehler auftritt, hängt vom Agent-Harness und dessen Delegationsregeln ab.

Informationen können zwischen den Phasen verloren gehen

Jede Verdichtung von Interview zu Spezifikation, Tickets und Implementierung kann Details abschwächen. Issue #341 beschreibt genau diesen Traceability-Verlust. Eine plausible Spezifikation ist nicht automatisch eine vollständige Spezifikation.

Praktisch heißt das: Bewahre zentrale Constraints, Negativanforderungen und Akzeptanzkriterien als versionierte Primärartefakte auf. Lass Tickets auf konkrete Abschnitte verweisen, statt Anforderungen bei jeder Phase frei neu zusammenzufassen.

Komplexe Skills sind weniger portabel als Markdown vermuten lässt

Einfache Anweisungen wie TDD oder strukturiertes Debugging lassen sich relativ leicht zwischen Agenten übertragen. Orchestrierung hängt stärker von Toolnamen, Subagenten und Berechtigungsmodellen ab. Issue #561 kritisiert harness-spezifische Agent-Toolnamen im Code-Review-Workflow.

Die Behauptung der README, die Skills arbeiteten mit jedem Modell, sollte deshalb eng gelesen werden. Markdown lässt sich überall anzeigen. Das bedeutet nicht, dass jeder Harness komplexe Delegation, Hintergrundarbeit und Skill-Aufrufe identisch unterstützt.

Drittanbieter-Skills erweitern die Vertrauensgrenze

`npx skills add` lädt Anweisungen eines Drittprojekts in einen Agenten, der möglicherweise Shell-, Datei-, GitHub- oder Deployment-Zugriff besitzt. Lies vor der Installation mindestens `SKILL.md`, eingebundene Referenzen und Installationsskripte. MIT-Lizenz und hohe GitHub-Sterne ersetzen kein Security Review.

Ein historisches Beispiel liefert Issue #171: Der Handoff-Skill konnte sensible Werte in Übergabedokumente übernehmen. Das Issue wurde geschlossen, nachdem Redaction-Regeln ergänzt wurden. Es ist damit keine belegte aktuell offene Sicherheitslücke, zeigt aber, warum auch reine Markdown-Skills sicherheitsrelevant sind.

Es fehlt ein unabhängiger Wirksamkeitsnachweis

Für diese konkrete Sammlung besteht die Evidenz aus Repository-Dateien, Selbstdarstellung, einem reproduzierten Installationstest und einzelnen Issue-Berichten; eine kontrollierte unabhängige Wirksamkeitsstudie zu Softwarequalität oder Produktivität wurde nicht gefunden. Daraus lässt sich nicht ableiten, dass die Sammlung Softwarequalität oder Produktivität allgemein verbessert. Dafür wären kontrollierte Vergleiche mit identischem Modell, Harness, Repository, Aufgabenmix und mehreren Läufen nötig.

Für wen lohnen sich Matt Pococks Agent Skills?

Meine Empfehlung: Installiere nicht alle Skills global. Beginne projektbezogen mit einem Skill, definiere vorher ein beobachtbares Ziel und prüfe mehrere reale Aufgaben. Gute Kandidaten sind `/diagnosing-bugs` für reproduzierbare Fehlersuche oder `/grill-with-docs` für unklare Anforderungen. Erst wenn der Ablauf zum Team passt, solltest du weitere Skills kombinieren.

FAQ: Häufig gestellte Fragen zu Matt Pococks Agent Skills

Sind Matt Pococks Agent Skills ein Agenten-Framework?

Nicht im klassischen Sinn. Das Projekt bringt keine eigene Runtime und kein eigenes Modell mit. Es ist eine Sammlung wiederverwendbarer Anweisungen, die ein vorhandener Agent-Harness ausführt.

Wie viele Skills gehören zum offiziellen Umfang?

Das aktuelle Claude-Plugin-Manifest listet 22 Skills: 17 aus dem Bereich Engineering und 5 aus Productivity. Weitere `SKILL.md`-Dateien liegen in experimentellen, persönlichen oder veralteten Bereichen und gehören nicht automatisch zum beworbenen Plugin-Umfang.

Funktionieren die Skills mit Codex?

Ja, über die Skills CLI. Die Installation eines einzelnen Skills für Codex wurde mit der CLI-Version 1.5.20 reproduziert. Ein natives Codex-Plugin ist laut Projekt-ADR derzeit zurückgestellt.

Muss ich den vollständigen Workflow übernehmen?

Nein. Die Skills sind gerade für selektive Nutzung gedacht. Du kannst beispielsweise nur TDD, Diagnose oder Handoff übernehmen und den restlichen Projektprozess unverändert lassen.

Verhindern die Skills schlechten KI-Code?

Nein. Sie strukturieren den Prozess und können bessere Feedback-Schleifen anstoßen. Ob der Code korrekt, sicher und wartbar ist, müssen Tests, statische Analyse, Reviews und reale Ausführung belegen.

Können Updates eigene Anpassungen überschreiben?

Ja, das ist laut dem geschlossenen Issue #196 möglich. Der Thread beschreibt das Überschreibungsrisiko des Updatepfads, nicht einen reproduzierten Schadensfall. Versioniere lokale Änderungen und prüfe Updates als Diff, bevor du sie übernimmst.

Sind hohe GitHub-Sterne ein Qualitätsbeweis?

Nein. Die 187.189 Sterne im Snapshot vom 25. Juli 2026, 06:59 UTC belegen Aufmerksamkeit. Sie messen weder aktive Nutzer noch erfolgreiche Projekte, Codequalität oder Produktivitätsgewinn.

Fazit

Matt Pococks Agent Skills sind ein nachvollziehbarer, modularer Baukasten: Sie übersetzen etablierte Engineering-Disziplinen in kleine Agentenanweisungen. Nutze sie selektiv, projektbezogen und versioniert. Verlass dich bei Tests, Freigaben, Security und Reviews aber nie allein auf Prompt-Anweisungen: Ein Skill beschreibt den Prozess, der Agent-Harness und deine Toolchain müssen ihn absichern.

Weiterführend: Wie Vibe Coding von einem Meme zur professionelleren Praxis wurde, warum der Agent-Harness oft wichtiger als das Modell ist und wie ein spezialisierter Design-Skill gegen typische KI-Muster arbeitet.

## Quellen

• mattpocock/skills auf GitHub
• README mit Quickstart, Motivation und Skill-Referenz
• Claude-Plugin-Manifest mit dem kuratierten Skill-Umfang
• `package.json`
• Architecture Decision Record zum Claude-Code- und Codex-Plugin
• Skills CLI
• GitHub Spec Kit
• BMAD Method
• Superpowers
• NotebookLM-Recherche-Notebook

*Dynamische Repository-Daten abgerufen am 25. Juli 2026, 06:59 UTC. GitHub-Issues sind konkrete Praxisberichte, keine unabhängigen Häufigkeitsmessungen.*