Razsk/VideoStudio

Ask Matt

Du erinnerst dich nicht an jede Fertigkeit, also frage.

Bevor du sagst, was eine Fertigkeit tut oder empfiehlst, einen Schritt auszulassen, lies die SKILL.md dieser Fertigkeit: Die Zusammenfassungen hier dienen nur der Orientierung.

Ein Ablauf ist ein Pfad durch die Fertigkeiten. Die meisten Pfade verlaufen entlang eines Hauptablaufs, und zwei Auffahrten münden in ihn. Alles andere ist eigenständig oder eine darunter liegende Vokabularschicht.

Der Hauptablauf: Idee → Auslieferung

Der Weg, den die meiste Arbeit nimmt. Du hast eine Idee und möchtest sie umsetzen.

1. /grill-with-docs schärft die Idee durch ein Interview. Beginne hier, wann immer du in einem Arbeitsverzeichnis arbeitest: Es ist zustandsbehaftet und behält das Gelernte in GLOSSARY.md und ADRs. (Kein Arbeitsverzeichnis? Verwende stattdessen /grill-me, das unter "Eigenständig" behandelt wird. Beide führen dasselbe /grilling-Primitiv aus; grill-with-docs hinterlässt eine Papierspur, was es in einem Repository zum besseren der beiden macht.)

2. Verzweigung: Kannst du jede Frage im Gespräch klären? Wenn eine Frage eine ausführbare Antwort benötigt (Zustand, Geschäftslogik, eine UI, die man sehen muss), mache einen Umweg über einen Prototypen, der in beide Richtungen durch /handoff überbrückt wird (ein Prototyp lebt in einem eigenen Verzeichnis, wofür /handoff genau da ist; siehe Phasengrenzen):

   • /handoff raus, dann öffne eine neue Sitzung für diese Datei,
   • /prototype um die Frage mit Wegwerfcode zu beantworten,
   • /handoff zurück, was du gelernt hast, und verweise im ursprünglichen Ideenfaden darauf.

3. Verzweigung: Ist das ein Build mit mehreren Sitzungen?

   • Ja → /to-spec (verwandle den Faden in eine Spezifikation), dann /to-tickets um ihn in Tracer-Bullet-Tickets aufzuteilen, die jeweils ihre blockierenden Kanten deklarieren. Dann bearbeite die Tickets auf eine von zwei Arten:
     • /implement pro Ticket, mit /clear des Kontexts zwischen jedem. Bei einem lokalen Tracker ist das eine Datei pro Ticket unter .scratch/<feature>/issues/, zuerst nach Blockierern bearbeitet; bei einem echten Tracker werden die Kanten zu nativen Blockierungslinks, sodass jedes Ticket, dessen Blocker erledigt sind, aufgegriffen werden kann. Jedes Ticket ist in sich abgeschlossen, daher ist der Kontext des letzten Tickets wegwerfbar.
     • /implement-spec für die gesamte Spezifikation in einem Durchlauf. Es liest die Tickets als Aufgabengraph, führt Implementierungs-Subagenten parallel über die bereite Frontier aus und bringt alles auf einem Integrationszweig zusammen. Greife danach, wenn du den Build lieber orchestrieren möchtest, anstatt jedes Ticket selbst zu fahren.
   • Nein → /implement direkt hier, im selben Kontextfenster.

   In beiden Fällen wird der Code durch /tdd (ein Rot-Grün-Slice nach dem anderen) gebaut und mit /code-review, einer zweiachsigen Überprüfung (Standards + Spezifikation) des Diffs, abgeschlossen. /implement führt beide pro Ticket aus; die Implementierer von /implement-spec treiben jeweils /tdd an, und es führt eine /code-review über den Integrationszweig durch. Greife auf /tdd allein zurück, wenn du nur ein konkretes Verhalten test-first bauen möchtest, ohne eine vollständige Spezifikation, und auf /code-review allein, wann immer du einen Zweig oder PR gegen einen festen Punkt überprüfen möchtest.

   Wenn die Arbeit als Pull Request hochgeht, formt /pr den Textkörper: die kleinste visuelle Darstellung, die die Änderung zeigt, Vorher/Nachher-Belege, dass es funktioniert, und eine Einweg- oder Zweiweg-Tür-Entscheidung. Es wird modellgesteuert aufgerufen, sodass der Agent danach greift, wann immer er einen PR schreibt.

4. /retro schließt den Kreislauf. Nach einem Build, besonders wenn es schiefgelaufen ist, blickt es auf die Sitzung zurück und schlägt Änderungen an der Umgebung des Agenten vor, nicht am Code: Navigationshinweise, automatisierte Prüfungen, die Codierungsstandards, die /code-review durchsetzt, Steuerungsdateien, Werkzeuge. Mechanische Fehler werden zu deterministischen Prüfungen; Ermessensentscheidungen werden zu Codierungsstandards. Der nächste Build beginnt dann in einer besseren Umgebung.

Kontexthygiene

Halte die Schritte 1–3 in einem einzigen ununterbrochenen Kontextfenster (nicht komprimieren oder löschen bis nach /to-tickets), damit das Grilling, die Spezifikation und die Tickets alle auf demselben Denken aufbauen. Jedes /implement beginnt dann frisch und arbeitet vom Ticket aus. Führe /retro in der Sitzung aus, auf die es zurückblickt, bevor du löschst; nach dem Löschen richte es stattdessen auf das Protokoll dieser Sitzung.

Die Grenze hierfür ist die Smart Zone: das Fenster (~150k Tokens bei modernen Modellen), in dem das Modell noch scharf denkt. Wenn eine Sitzung sich ihr vor /to-tickets nähert, dränge nicht auf verschlechterter Leistung; führe /compact an der nächsten Phasengrenze aus und fahre fort (siehe Phasengrenzen).

Auffahrten

Eine Startsituation, die Arbeit generiert und dann in den Hauptablauf mündet.

• Bugs und Anfragen häufen sich → /triage. Es bewegt Issues durch Triage-Rollen und produziert agentenfertige Issues, die /implement später aufnimmt.

  Triage ist nur für Issues, die du nicht erstellt hast: Bugmeldungen, eingehende Feature-Anfragen, alles, was roh ankommt. Tickets, die /to-tickets erstellt hat, sind bereits agentenfertig, also triage sie nicht.

• Etwas ist kaputt → /diagnosing-bugs. Für die harten Fälle: der Bug, der dem ersten Blick widersteht, der intermittierende Flake, die Regression, die zwischen zwei bekannten guten Zuständen eingeschlichen ist. Es weigert sich zu theoretisieren, bis es eine enge Rückkopplungsschleife hat (einen Befehl, der bereits auf diesen Bug rot wird), dann behebt es mit einem Regressionstest. Sobald die Behebung drin ist, führe /retro in derselben Sitzung aus, um zu fragen, was den Bug verhindert hätte; wenn die eigentliche Erkenntnis ist, dass es keine gute Naht gibt, um ihn zu sichern, ist das ein Job für /improve-codebase-architecture.

• Ein riesiges, nebulöses Vorhaben: ein Greenfield-Projekt oder ein riesiger Feature-Build, zu groß für eine Sitzung → /wayfinder, der kognitiv anspruchsvollste Ablauf hier. Wenn der Weg von hier zum Ziel noch nicht sichtbar ist, erstellt es eine gemeinsame Karte von Entscheidungstickets auf dem Issue-Tracker und löst sie nacheinander, wobei Entscheidungen, keine Ergebnisse produziert werden, bis der Nebel sich gelichtet hat und der Weg klar ist. Wo /grill-with-docs eine Idee schärft, die du in einer Sitzung halten kannst, ist wayfinder für die Idee, die du nicht halten kannst, und es ist langsamer und dichter, also hebe es dir genau dafür auf, niemals für ein gut abgegrenztes Feature.

  Wenn die Karte klar ist, übergibt es, es baut nicht: Münde in den Hauptablauf bei /to-spec ein, das die verknüpften Entscheidungen der Karte in einen umsetzbaren Plan kollabiert, dann wie üblich /to-tickets und /implement. Die Karte direkt in /implement zu schleifen, überspringt diese Kollabierung und wirft die verknüpften Details weg, also gehe nur dann direkt zu /implement, wenn sich das Vorhaben als wirklich klein herausgestellt hat.

Codebase-Gesundheit

Keine Feature-Arbeit, nur Instandhaltung.

• /improve-codebase-architecture wird immer dann ausgeführt, wenn du einen freien Moment hast, um die Codebase für Agenten betriebsbereit zu halten. Es deckt Vertiefungsmöglichkeiten auf; eine auszuwählen erzeugt eine Idee, die du im Hauptablauf bei /grill-with-docs aufnehmen kannst. Es ist die Erkundung, die die Kandidaten findet; /codebase-design (unten) ist die Werkbank, auf der du den ausgewählten entwirfst.

Vokabular darunter

Zwei modellgesteuerte Referenzen, die unterhalb der anderen Fertigkeiten laufen, jede die alleinige Quelle der Wahrheit für ihr Vokabular. Greife direkt darauf zu, wenn die Wörter, nicht der Prozess, das Problem sind; oder lass die obigen Fertigkeiten sie einbinden.

• /domain-modeling: Schärfe die Domänensprache des Projekts: fordere einen vagen Begriff heraus, löse ein überladenes Wort auf ("Konto" macht drei Jobs), halte eine schwer umkehrbare Entscheidung als ADR fest. Es ist die aktive Disziplin, die /grill-with-docs antreibt, um GLOSSARY.md als sauberes Glossar zu erhalten.
• /codebase-design ist das Tiefmodul-Vokabular (Modul, Schnittstelle, Tiefe, Naht, Adapter, Hebelwirkung, Lokalität) zum Entwerfen der Form eines Moduls: viel Verhalten hinter einer kleinen Schnittstelle an einer sauberen Naht. /tdd und /improve-codebase-architecture sprechen es beide.

Phasengrenzen

Eine Phase ist ein Arbeitspaket innerhalb einer Sitzung: das Grilling, die Implementierung, die Qualitätssicherung. An der Grenze zwischen zwei von ihnen hast du fünf Optionen, und zwischen ihnen zu wählen, ist die unscharfste Entscheidung in dieser gesamten Karte:

• Weitermachen: bleib, wo du bist. Kostet nichts, verliert nichts.
• /clear: leere das Fenster, wenn nichts hier für das Nächste wichtig ist.
• /handoff schreibt eine tragbare Markdown-Datei. Eng gefasst: nur für ein neues Gerüst, ein neues Verzeichnis, einen Kollegen oder zum Abspalten einer Nebenaufgabe mitten in einer Phase. Was es erkauft, ist Portabilität.
• Subagent: sende eine eng gefasste Aufgabe in ein eigenes Fenster und erhalte einen Bericht zurück.
• /compact komprimiert diesen Kontext und sät eine frische Sitzung damit. Der Standard, am unteren Ende des Baums und nicht der erste Zugriff.

Lies PHASE-BOUNDARIES.md für den geordneten Baum: die fünf Fragen, die Begründung hinter jedem Zweig und warum die Primärquellenkosten Weitermachen als erstes ausschließen lassen. Triff die Entscheidung an einer Grenze; mitten in der Phase mache weiter oder teile den Rest in Subagenten auf.

Eigenständig

Völlig außerhalb des Hauptablaufs.

• /grill-me: dasselbe unerbittliche Interview wie /grill-with-docs, aber zustandslos: Es speichert nichts lokal und erstellt kein GLOSSARY.md. Greife darauf zu, wenn du nicht in einem Arbeitsverzeichnis arbeitest (Schärfen eines Plans, eines Designs, eines Textstücks, irgendetwas ohne Repository darunter). Wenn du in einem Arbeitsverzeichnis bist, verwende stattdessen /grill-with-docs: Es führt dasselbe Interview durch und hinterlässt eine Papierspur, also ist es strikt das bessere.
• /grilling ist das Interview-Primitiv selbst: Runden, die Frontier, Fakten sind die Aufgabe des Agenten und Entscheidungen sind deine. /grill-me und /grill-with-docs sind die zwei benannten Wege hinein, und /triage, /wayfinder und /improve-codebase-architecture führen es intern aus. Greife nur dann direkt darauf zu, wenn du das Interview ohne Hülle darum möchtest.
• /prototype ist ein kleines, wegwerfbares Programm, das eine einzige Designfrage beantwortet: Fühlt sich dieses Zustandsmodell richtig an, oder wie sollte diese UI aussehen? Wegwerfbar ist eine Einschränkung dafür, wie der Code geschrieben wird, kein Versprechen, ihn zu zerstören: Die Antwort fließt in den echten Code ein, und der Prototyp selbst wird als Primärquelle auf einem prototype/<name>-Zweig von main aus aufbewahrt, auf den im Implementierungs-Issue verwiesen wird. Es ist der Umweg in Schritt 2 des Hauptablaufs, aber greife immer dann darauf zu, wenn eine Designfrage auf Papier schwer zu klären ist.
• /research: Delegiere Lese-Arbeit an einen Hintergrundagenten: Er untersucht eine Frage anhand von Primärquellen und hinterlässt dann eine zitierte Markdown-Datei im Repository. Arbeite weiter, während er liest. Die Datei, die er erstellt, ist etwas, das in den Hauptablauf bei /grill-with-docs mitgenommen wird, da Recherche das Denken speist, nicht ersetzt.
• /to-questionnaire kommt zum Einsatz, wenn das Hindernis nicht in deinem Kopf oder der Codebase, sondern in jemand anderem Kopf steckt, und erstellt für diese Person einen Fragebogen zum Ausfüllen. Es ist das Gegenteil von /grill-me: Statt dich über das Thema zu interviewen, interviewt es dich über den Versand (an wen es geht, was du zurückbrauchst) und richtet die Fragen auf die Lücke. Was zurückkommt, ist Material für /grill-with-docs oder /to-spec.
• /wizard ist für die Schritte, die nur ein Mensch ausführen kann: Bereitstellen von Infrastruktur, Einrichten von Anmeldeinformationen oder CI-Geheimnissen, Durchklicken durch ein unbekanntes Drittanbieter-Dashboard, Ausführen einer einmaligen Migration oder Umstellung. Es erzeugt ein interaktives Bash-Skript, das jede URL öffnet, jeden Wert erfasst und in .env und GitHub-Secrets schreibt, sodass die Prozedur aufhört, etwas zu sein, das du einem Agenten jedes Mal neu erklären musst. Modellgesteuert, also greift der Agent danach, sobald er auf eine Wand trifft, die nur du passieren kannst. Wenn der Agent es einfach selbst tun könnte, sollte er es; dies ist für Fälle, in denen ein Mensch wirklich im Kreislauf ist.
• /wait-what ist die Korrektur für eine Nachricht, die nicht angekommen ist. Verwende es mitten im Gespräch, innerhalb jeder anderen Fertigkeit, und der Agent wiederholt, was er gerade gesagt hat, mit dem Kontext, den du vermisst hast, in einfachem Englisch, unter Verwendung des Vokabulars aus GLOSSARY.md. Es wirkt im Nachhinein; /grill-with-docs ist die vorbeugende Heilung, denn eine gemeinsam früh vereinbarte Sprache verhindert, dass der Jargon überhaupt ankommt.
• /teach: Lerne ein Konzept über mehrere Sitzungen hinweg, indem du das aktuelle Verzeichnis als zustandsbehafteten Arbeitsbereich verwendest.
• /writing-for-agents ist die Referenz zum Schreiben von Dokumenten, die Agenten konsumieren: Skills, AGENTS.md, referenzierte Dokumente.

Vorbedingung

/setup-matt-pocock-skills: Führe es vor deinem ersten Engineering-Ablauf aus, um den Issue-Tracker, Triage-Labels und das Dokumentenlayout zu konfigurieren, das die anderen Fertigkeiten voraussetzen. Benutzerdefinierte Issue-Tracker funktionieren ebenfalls.