A.4. Matt Pocock Skills

Unter KI-Nutzung – vom Anfänger zum Profi stehen Skills als Prinzip: ein Workflow on-demand, nicht dauernd im Kontext. Dieser Anhang ist ein fertiges Skillset dazu — die Skills von Matt Pocock (extern) .

Das Set ist kein Prozess-Framework, das die Steuerung übernimmt. Es sind kleine, kombinierbare Abläufe gegen typische Agent-Fehler: Der Agent baut das Falsche. Er redet zu viel. Der Code läuft nicht. Die Codebase verkommt. Die Übersicht folgt deshalb Situationen, nicht einer Skill-Liste.

Stand: offizieller Katalog im Repo (promoted Skills im Plugin, Version 1.2.x). Namen und Details ändern sich. Authority ist die jeweilige SKILL.md, nicht eine Blog-Zusammenfassung und nicht der Installer-Index auf skills.sh.

Vier Fehler, die Pocock im README (extern) als Ausgangspunkt nennt:

1. Misalignment. Ich denke, der Agent weiß, was ich will. Das Gebaute zeigt: hat er nicht. Dagegen hilft ein Grilling — der Agent interviewt mich, bis die Zweige der Entscheidung sitzen.
2. Zu viel Text. Ohne gemeinsame Sprache erklärt der Agent denselben Fachbegriff in zwanzig Wörtern. Dagegen hilft ein Glossar (CONTEXT.md), das /grill-with-docs mitbaut.
3. Der Code funktioniert nicht. Ohne Feedback-Loop fliegt der Agent blind. Dagegen /tdd und bei harten Bugs /diagnosing-bugs.
4. Ball of Mud. Agenten beschleunigen Entropy. Dagegen Design pflegen: /to-spec fragt nach Modulen, /improve-codebase-architecture sucht Vertiefungen — Survey, kein Rescue.

Besonders geeignet ist das Set also, wenn ich mit einem Coding-Agenten Software entwickle: Idee schärfen, bei größerer Arbeit Spec und Tickets schneiden, dann umsetzen; eigene Einstiege für Bugs, eingehende Requests, Recherche und Architektur. Weniger geeignet als Einstieg, solange Spec, Iteration und Tests aus 0.4 noch nicht sitzen.

Vor dem ersten Engineering-Flow im Repo: /setup-matt-pocock-skills. Die Skill fragt, wo Issues liegen (GitHub, GitLab, lokale Markdown-Dateien oder ein anderer Tracker), welche Triage-Labels gelten und wo Domain-Docs sitzen. Ohne das raten /to-spec, /to-tickets, /triage und /wayfinder den Tracker.

Unsicher, welcher Ablauf passt: /ask-matt. Der Router empfiehlt und stoppt. Er feuert die genannte Skill nicht. Bei Widerspruch zwischen Router und SKILL.md gilt die SKILL.md.

Zwei Install-Wege, nicht beide: Claude-Code-Plugin mattpocock-skills (managed, read-only, Updates automatisch) oder npx skills@latest add mattpocock/skills (editierbare Kopien im Projekt). Quelle: github.com/mattpocock/skills (extern) und aihero.dev/skills (extern) .

Die Karte kommt aus /ask-matt: ein Main Flow (Idee → Ship), On-Ramps, die darauf münden, Upkeep, und Standalones. User-invoked Skills tippe ich selbst; model-invoked Skills darf der Agent greifen, wenn die Aufgabe passt. Eine user-invoked Skill darf model-invoked Skills aufrufen, nie eine andere user-invoked. Deshalb sagt /to-tickets „dann /implement“ zu mir, nicht zum Agenten.

Das ist der Hauptweg.

Idee
  → /grill-with-docs          (im Repo; ohne Repo: /grill-me)
  → [optional] Prototype, wenn die Frage nur am laufenden Ding entscheidbar ist
  → klein, eine Session:     /implement
  → groß, mehrere Sessions:  /to-spec → /to-tickets → /implement pro Ticket
  → /implement treibt /tdd und schließt mit /code-review

Grilling zuerst. /grill-with-docs interviewt und schärft die Domain-Sprache. CONTEXT.md ist ein Glossar, keine Spec. Die meisten Entscheidungen leben nur im Gespräch. Deshalb Grilling und /to-spec in derselben Session halten — nicht dazwischen leeren.

Spec und Tickets nur, wenn das Build die Session überlebt. Passt die Arbeit in ein scharfes Kontextfenster (Pocock: smart zone, grob ~150k Tokens), dann nach dem Grilling direkt /implement. Mehrere Sessions: /to-spec verdichtet das Gespräch (kein zweites Interview), /to-tickets schneidet tracer-bullet-Tickets mit Blockern. Jedes Ticket ist eine frische Session; dazwischen /clear.

Ohne Working Directory — Plan, Text, Design ohne Repo — /grill-me statt /grill-with-docs. Dieselbe Interview-Primitive, kein Paper Trail. Mit Repo ist /grill-with-docs die bessere Wahl.

Braucht eine Frage etwas zum Anschauen (State, UI): Grilling stoppen, /handoff in ein Prototype-Verzeichnis, /prototype, /handoff zurück. Das Prototype bleibt als Quelle auf einem eigenen Branch, es ist nicht das Produkt.

/grill-with-docs schärft, was in eine Session passt. Wenn der Weg zur Destination noch unsichtbar ist — Greenfield, riesiges Feature — /wayfinder.

Wayfinder legt eine Map aus Decision Tickets auf dem Tracker an und löst sie einzeln. Es produziert Entscheidungen, keinen Code. Wenn die Map klar ist: /to-spec, dann Tickets und /implement. Geradewegs /implement wirft die verlinkten Entscheidungen weg. Ein gut gescopetes Feature gehört nicht hierher.

/diagnosing-bugs für die harten Fälle: intermittierend, Regression zwischen zwei bekannten Zuständen, erster Blick reicht nicht. Die Skill blockiert Theorie, bis ein Befehl schon rot auf diesen Bug geht. Dann minimieren, hypothetisieren, instrumentieren, fixen, Regressionstest.

Kein Audit ohne Symptom. „Wo sind die Bottlenecks?“ ohne beobachtbaren Fehler ist out of scope. Fehlt ein Seam für den Test, mündet das in Architektur — nicht in mehr Raten.

/triage ist der Einstieg für Arbeit, die angekommen ist: Bug-Reports, Feature-Requests von anderen, roh. Die Skill schiebt Issues durch Rollen (needs-triage, needs-info, ready-for-agent, ready-for-human, wontfix) und schreibt einen Agent-Brief. Danach /implement auf ready-for-agent.

Tickets, die /to-tickets schon erzeugt hat, sind agent-ready. Die nicht noch einmal triagen.

/research delegiert Lesearbeit an einen Background-Agenten: Primärquellen, eine zitierte Markdown-Datei im Repo. Die Datei füttert später Grilling oder Spec. Research ersetzt Alignment nicht.

/improve-codebase-architecture scannt nach Vertiefungen, zeigt Kandidaten, ändert keinen Code. Den gewählten Kandidaten nehme ich in /grill-with-docs und von dort in den Main Flow. Die Form eines schon gewählten Moduls: /codebase-design (Vokabular: deep module, Seam, Interface) — Bank, nicht Survey.

Vorher: Grilling plus /domain-modeling (Glossar und ADRs). Eine Nachricht ist schon verloren: /wait-what — Re-Pitch in Klartext mit dem Vokabular aus CONTEXT.md. /wait-what repariert eine Message. Die Kur für Jargon ist die gemeinsame Sprache vorher.

/wizard erzeugt ein interaktives Skript für Schritte, die nur ich tun kann: Secrets, fremdes Dashboard, Cutover. Was der Agent selbst kann, soll er selbst tun.

/to-questionnaire ist die Inverse von /grill-me: Sie grilled mich zum Versand (wer, was zurück), nicht zum Thema, das ich nicht kenne. Die Antworten kommen später ins Grilling oder in die Spec.

Kein Flow, jeweils für sich:

25 Skills im promoted Katalog. Slash-Namen bleiben Englisch.

Einstieg: /setup-matt-pocock-skills, /ask-matt.

Main Flow: /grill-with-docs (im Repo) bzw. /grill-me (ohne), /to-spec, /to-tickets, /implement. Intern bzw. am Ende: /tdd, /code-review. Optionaler Umweg: /prototype, /handoff.

On-Ramps: /wayfinder, /diagnosing-bugs, /triage.

Upkeep und Vokabular: /improve-codebase-architecture, /codebase-design, /domain-modeling. Die Primitive hinter mehreren Interviews: /grilling.

Weitere Standalones: /research, /wizard, /to-questionnaire, /wait-what, /teach, /writing-for-agents, /resolving-merge-conflicts.

Daneben liegen im Repo in-progress-Skills (Beta, nicht im Plugin) und misc-Skills (selten gebraucht, etwa Pre-Commit-Hooks). Der Installer-Index zählt auch alte Namen und Aliase. Authority für „was gilt“ ist CHANGELOG plus aktuelle SKILL.md, nicht die Zählung „53 Skills“.

Alte Slugs nicht mischen: to-prd ist to-spec, to-issues steckt in to-tickets, diagnose ist diagnosing-bugs, pathfinder / decision-mapping ist wayfinder, writing-great-skills ist writing-for-agents.

• grill-me vs. grill-with-docs: Mit Repo Paper Trail, ohne Repo ohne. Beide rufen /grilling.
• grill-with-docs vs. wayfinder: Eine Session vs. Nebel über Sessions — nicht „großes Projekt“ allein.
• Spec verdient den Schritt nur bei Multi-Session-Arbeit. /to-spec interviewt nicht noch einmal; der Seam-Check vor der Prosa ist lasttragend.
• /implement treibt /tdd intern. /tdd allein, wenn ich nur ein konkretes Verhalten test-first bauen will.
• /implement schließt keine Tickets und legt keine PR an. Tickets, deren Blocker nie geschlossen werden, bleiben unsichtbar unblocked.
• CONTEXT.md ist Glossar. Die Spec steht im Tracker. Beides nicht vertauschen.
• User-invoked Skills fehlen oft in der Liste, die der Agent sieht (disable-model-invocation). Sie sind trotzdem da — Slash-Command tippen.
• Patches an kopierten SKILL.md-Dateien überleben npx skills update und das Plugin nicht. Stehendes Verhalten gehört nach AGENTS.md / CLAUDE.md oder in die Invocation.

First-Party. Produkt-UIs und Skill-Namen veralten; die Situationen tragen.

• mattpocock/skills auf GitHub (extern)
  Katalog, Failure Modes, User- vs. model-invoked. Authority: jeweilige SKILL.md.

• README: Skills For Real Engineers (extern)
  Warum das Set existiert; Installation Plugin vs. npx skills.

• CHANGELOG (extern)
  Renames, Retirements, Graduations.

• aihero.dev/skills (extern)
  First-Party-Seiten zu den Skills. Die Featured-Liste auf der Indexseite kann alte Slugs zeigen; die einzelnen /skills-<name>-Seiten und das Repo zählen.

• ask-matt (extern)
  Router: Main Flow, On-Ramps, Standalones. Sekundäre Karte — bei Widerspruch SKILL.md.

• to-spec (extern) · to-tickets (extern) · implement (extern) · grill-with-docs (extern) · wayfinder (extern)
  Die Kette Idee → Spec → Tickets → Implementieren, inkl. Wann Spec skippen und dass Wayfinder Entscheidungen liefert, keinen Code.

• Smart Zone (extern)
  Fenster, in dem das Modell noch scharf bleibt; Grenze für Grilling, Spec und Tickets in einer Session.