Brians-brain/claude-skills

Frag Matt

Antworte in traditionellem Chinesisch.

Du erinnerst dich nicht an jedes Skill, also frag nach.

Bevor du erklärst, was ein Skill tut, oder vorschlägst, einen Schritt zu überspringen, lies zuerst die SKILL.md dieses Skills: Die Zusammenfassung hier dient nur der Orientierung.

Ein Prozess ist ein Pfad durch diese Skills. Die meisten Pfade folgen einem Hauptprozess, in den zwei Zufahrtsrampen münden. Die anderen werden eigenständig oder als darunter liegende Begriffe verwendet.

Hauptprozess: Idee → Livegang

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

1. /grill-with-docs – Schärfe die Idee durch ein Interview. Beginne hier, solange du in einem Arbeitsverzeichnis arbeitest: Es ist zustandsbehaftet und bewahrt Erkenntnisse in GLOSSARY.md und ADRs auf. (Kein Arbeitsverzeichnis? Verwende stattdessen /grill-me, siehe „Eigenständige Nutzung“. Beide führen denselben grundlegenden Mechanismus /grilling aus; grill-with-docs hinterlässt schriftliche Aufzeichnungen, also ist es besser, solange es ein Repo gibt, um sie zu speichern.)

2. Abzweigung: Kann jedes Problem im Gespräch gelöst werden? Wenn ein Problem eine ausführbare Antwort benötigt (Status, Geschäftslogik, eine UI, die du sehen musst), mache einen Umweg über einen Prototypen und verbinde beide Richtungen mit /handoff (der Prototyp kommt in ein eigenes Verzeichnis – genau das ist der Zweck von /handoff; siehe „Phasengrenzen“):

   • Übergib mit /handoff und starte eine neue Session für diese Datei,
   • Beantworte die Frage mit /prototype mittels Wegwerfcode,
   • Übergib die Erkenntnisse mit /handoff zurück und referenziere sie aus dem ursprünglichen Ideen-Thread.

3. Abzweigung: Ist dies eine Erstellung, die mehrere Sessions erfordert?

   • Ja → /to-spec (verwandle den Thread in ein Pflichtenheft), dann zerlege es mit /to-tickets in Tracer-Bullet-Tickets, die jeweils ihre Blockierungskante angeben. Bearbeite die Tickets dann auf eine der folgenden Arten:
     • Einmal /implement pro Ticket, mit /clear des Kontexts zwischen den Tickets. Im lokalen Tracker bedeutet das eine Datei pro Ticket unter .scratch/<feature>/issues/, manuell in der Reihenfolge der Blockierer; im echten Tracker werden Kanten zu nativen Blockierungslinks, sodass jedes Ticket übernommen werden kann, dessen Blockierer erledigt sind. Jedes Ticket ist in sich abgeschlossen, sodass der Kontext des vorherigen verworfen werden kann.
     • Verwende /implement-spec, um das gesamte Pflichtenheft auf einmal auszuführen. Es liest Tickets als Aufgabengraph, führt Implementierungs-Agenten auf der bereiten Frontier parallel aus und legt alles auf einem einzigen Integrationsbranch ab. Verwende es, wenn du die gesamte Erstellung koordinieren willst, anstatt Tickets selbst nacheinander voranzutreiben.
   • Nein → Verwende /implement hier im selben Kontextfenster.

   In beiden Fällen wird Code durch /tdd (ein Red-Green-Slice nach dem anderen) erstellt und mit /code-review-zh abgeschlossen, einer zweiachsigen Überprüfung des Diffs (Standards + Spezifikation). /implement führt beide für jedes Ticket aus; /implement-spec verwendet /tdd für jeden Implementierer und führt abschließend /code-review-zh auf dem Integrationsbranch durch. Verwende /tdd eigenständig, wenn du testgesteuert ein bestimmtes Verhalten ohne vollständiges Pflichtenheft umsetzen willst; verwende /code-review-zh eigenständig, um jederzeit einen Branch oder PR gegen einen festen Punkt zu überprüfen.

   Wenn die Arbeit als Pull Request eingereicht wird, bestimmt /pr die Form des PR-Texts: minimale visuelle Darstellung der Änderungen, Vorher-Nachher-Beweise für die Korrektheit und Bewertung von Einweg-/Zweiwegtüren. Es ist modellaufgerufen, also wird der Agent es jedes Mal beim Schreiben eines PR verwenden.

4. /retro schließt den Kreislauf. Nach einer Erstellung, besonders wenn etwas schiefgelaufen ist, überprüft es die gesamte Session und schlägt Verbesserungen an der Arbeitsumgebung des Agenten vor, nicht am Code: Navigationshinweise, automatische Prüfungen, die von /code-review-zh durchgesetzten Schreibstandards, Leitfäden, Tools. Mechanische Fehler werden zu deterministischen Prüfungen; Urteilsfragen werden zu Schreibstandards. Die nächste Erstellung beginnt in einer besseren Umgebung.

Kontexthygiene

Halte die Schritte 1–3 im selben, ununterbrochenen Kontextfenster (kein Compact oder Clear vor /to-tickets), sodass das Interview, das Pflichtenheft und die Tickets auf demselben Denken aufbauen. Danach beginnt jedes /implement von vorne, basierend auf dem Ticket. Führe /retro in der Session aus, die es überprüfen soll, vor dem Clear; wenn bereits gecleart wurde, richte es auf die Aufzeichnungen dieser Session.

Die Einschränkung hierfür ist die Smart Zone – der Fensterbereich, in dem das Modell noch scharf推理 kann (bei den neuesten Modellen etwa 150.000 Token). Wenn eine Session vor /to-tickets diese Grenze erreicht, quäle dich nicht in einem degenerierten Zustand weiter; führe an der letzten Phasengrenze /compact aus und fahre fort (siehe „Phasengrenzen“).

Zufahrtsrampen

Startsituationen, die Arbeit erzeugen und dann in den Hauptprozess münden.

• Bugs und Anfragen stapeln sich → /triage. Es lässt Issues zwischen Triage-Rollen zirkulieren und produziert agentenreife Issues, die dann von /implement übernommen werden.

  Triage wird nur für Issues verwendet, die nicht von dir erstellt wurden: Bugmeldungen, eingehende Feature-Anfragen, alles Unverarbeitete. Die von /to-tickets erzeugten Tickets sind bereits agentenreif, also triagiere sie nicht.

• Etwas ist kaputt → /diagnosing-bugs. Für die harten Fälle: Bugs, die nicht auf den ersten Blick erkennbar sind, intermittierende Instabilität, Regressionen, die sich zwischen zwei bekanntermaßen korrekten Zuständen einschleichen. Es lehnt Theorien ab, bis eine enge Rückkopplungsschleife existiert (ein Befehl, der wegen dieses Bugs bereits rot wird), und behebt sie dann mit einem Regressionstest. Führe nach der Behebung in derselben Session /retro aus und frage, was diesen Bug hätte verhindern können; wenn die wahre Erkenntnis ist, dass es keine gute Naht gab, um ihn zu verriegeln, ist dies ein Job für /improve-codebase-architecture.

• Ein großes, nebliges Projekt: komplett neues Projekt oder riesige Feature-Erstellung, das eine Session nicht fasst → /wayfinder, der hier intensivste Prozess. Wenn der Weg von hier zum Ziel noch nicht sichtbar ist, zeichnet es eine Shared Map aus Entscheidungs-Tickets im Issue-Tracker, löst eines nach dem anderen und produziert Entscheidungen, keine Ergebnisse, bis der Nebel sich lichtet und der Weg klar wird. /grill-with-docs schärft Ideen, die du in einer Session fassen kannst; Wayfinder ist für Ideen, die du nicht fassen kannst – es ist langsamer und dichter, also hebe es dir für genau diesen Fall auf und verwende es niemals für klar abgegrenzte Features.

  Sobald die Karte klar ist, übergibt es, statt zu bauen: Es mündet über /to-spec in den Hauptprozess, der die verbundenen Entscheidungen der Karte in einen baubaren Plan destilliert, gefolgt von /to-tickets und /implement. Die Karte direkt an /implement zu übergeben, überspringt diese Destillation und verliert die Details der Verbindungen – also verwende diesen direkten Weg nur, wenn sich das Projekt am Ende als sehr klein herausstellt.

Code-Gesundheit

Keine Feature-Entwicklung, nur Wartung.

• /improve-codebase-architecture – Führe es aus, wenn du Zeit hast, um den Code in einem agentenfreundlichen Zustand zu halten. Es identifiziert Möglichkeiten zur Vertiefung; wenn du eine auswählst, entsteht eine Idee, die du in den Hauptprozess zu /grill-with-docs mitnehmen kannst. Es ist eine Erkundung, um Kandidaten zu finden; /codebase-design (siehe unten) ist die Werkbank, um einen ausgewählten Kandidaten zu entwerfen.

Begriffliche Grundlagen

Zwei modellaufgerufene Referenzen, die unter anderen Skills arbeiten, jeweils die einzige Quelle der Wahrheit für ihre Begriffe. Verwende sie direkt, wenn das Problem bei den Begriffen und nicht beim Prozess liegt; oder lass die darüber liegenden Skills sie einbinden.

• /domain-modeling: Schärft die Domänensprache des Projekts: Hinterfragt einen vagen Begriff, löst ein überstrapaziertes Wort auf (z.B. „Materialnummer“ für drei verschiedene Dinge), zeichnet eine schwer umkehrbare Entscheidung als ADR auf. Es ist die aktive Disziplin, die /grill-with-docs verwendet, um GLOSSARY.md sauber zu halten.
• /codebase-design ist die Begriffswelt des Deep Module (Modul, Schnittstelle, Tiefe, Naht, Adapter, Hebel, Lokalität), um die Form von Modulen zu entwerfen: viel Verhalten hinter einer kleinen Schnittstelle auf sauberen Nähten. /tdd und /improve-codebase-architecture verwenden es.

Phasengrenzen

Eine Phase ist ein Arbeitsabschnitt innerhalb einer Session: Interview, Implementierung, QA. An der Grenze zwischen zwei Phasen hast du fünf Optionen, und die Wahl zwischen ihnen ist die unscharfste Entscheidung auf der gesamten Karte:

• Weitermachen: Bleib, wo du bist. Kostet nichts und verliert nichts.
• /clear: Leere das Fenster, wenn nichts davon für das Nächste wichtig ist.
• /handoff schreibt eine portable Markdown-Datei. Enger Anwendungsbereich: Nur für Wechsel des Harnesses, Wechsel des Verzeichnisses, Übergabe an Kollegen oder zum Abspalten einer Nebenaufgabe mitten in einer Phase. Es erkauft sich Portabilität.
• Sub-Agent: Sende eine klar abgegrenzte Aufgabe in ein eigenes Fenster und hole einen Bericht zurück.
• /compact komprimiert den Kontext und startet damit eine neue Session. Es ist die Voreinstellung, der unterste Ast des Baums, nicht der erste, nach dem man greift.

Der Entscheidungsbaum in Reihenfolge siehe PHASE-BOUNDARIES.md: fünf Fragen, die Argumente hinter jedem Zweig und warum die Kosten von Primärquellen Weitermachen zur ersten auszuschließenden Option machen. Triff Entscheidungen an der Grenze; mitten in der Phase fahre fort oder delegiere die verbleibende Arbeit an einen Sub-Agenten.

Eigenständige Nutzung

Vollständig außerhalb des Hauptprozesses.

• /grill-me: Das gleiche strenge Interview wie /grill-with-docs, aber zustandslos: Es speichert nichts lokal und erstellt kein GLOSSARY.md. Verwende es, wenn du nicht in einem Arbeitsverzeichnis arbeitest (um einen Plan, ein Design, einen Artikel zu schärfen – alles ohne darunterliegendes Repo). Wenn du in einem Arbeitsverzeichnis arbeitest, verwende stattdessen /grill-with-docs: Es führt dasselbe Interview durch und hinterlässt schriftliche Aufzeichnungen, also ist es definitiv besser.
• /grilling ist der grundlegende Mechanismus des Interviews: Runden, Frontier, Fakten finden ist die Arbeit des Agenten, Entscheidungen treffen ist deine Arbeit. /grill-me und /grill-with-docs sind zwei benannte Einstiegspunkte, während /triage, /wayfinder und /improve-codebase-architecture es intern ausführen. Verwende es direkt nur, wenn du das Interview ohne jede Verpackung willst.
• /prototype ist ein kleiner Wegwerf-Code, der eine Designfrage beantwortet: Ist dieses Zustandsmodell sinnvoll, oder wie sollte diese UI aussehen? „Wegwerf“ ist eine Einschränkung für die Art, wie der Code geschrieben wird, kein Versprechen, ihn zu vernichten: Die Antwort fließt in den offiziellen Code ein, der Prototyp selbst wird als Primärquelle auf einem Branch prototype/<name> außerhalb von main gespeichert und vom Implementierungs-Issue aus referenziert. Es ist der Umweg in Schritt 2 des Hauptprozesses, kann aber jederzeit verwendet werden, wenn Designfragen auf dem Papier schwer zu lösen sind.
• /research: Delegiert die Lese-Arbeit an einen Hintergrund-Agenten: Es untersucht eine Frage anhand von Primärquellen und hinterlässt eine referenzierte Markdown-Datei im Repo. Während es liest, arbeitest du weiter. Die erzeugte Datei soll in den Hauptprozess /grill-with-docs eingespeist werden, denn Recherche nährt das Denken, ersetzt es nicht.
• /to-questionnaire wird verwendet, wenn das, was dich blockiert, nicht in deinem Kopf oder im Code ist, sondern im Kopf eines anderen. Es hilft dir, einen Fragebogen zu schreiben, den die andere Person ausfüllt. Es ist das Gegenteil von /grill-me: Es grillt nicht dich zum Thema selbst, sondern dich zum Versenden (an wen schicken, was zurückbekommen) und richtet die Fragen auf die Lücken aus. Das Zurückbekommene ist Rohmaterial für /grill-with-docs oder /to-spec.
• /wizard ist für Schritte, die nur ein Mensch erledigen kann: Infrastruktur aufbauen, Credentials oder CI-Secrets setzen, durch ein unbekanntes Drittanbieter-Backend klicken, einmalige Migrationen oder Switches durchführen. Es erzeugt ein interaktives Bash-Skript, das jede URL öffnet, jeden Wert abgreift und in .env und GitHub Secrets schreibt, sodass dieser Vorgang nicht jedes Mal neu mit dem Agenten erklärt werden muss. Es ist modellaufgerufen, also verwendet der Agent es, sobald er auf eine Wand stößt, die nur du durchbrechen kannst. Wenn der Agent es selbst tun kann, sollte er es selbst tun; dies ist nur für Fälle, in denen wirklich ein Mensch in der Schleife sein muss.
• /wait-what ist die nachträgliche Rettung für nicht angekommene Nachrichten. Es kann mitten in einem Gespräch, innerhalb jedes anderen Skills, verwendet werden; der Agent fügt den fehlenden Kontext hinzu, indem er das Gesagte in einfacher Sprache mit dem Vokabular von GLOSSARY.md wiederholt. Es ist die nachträgliche Rettung; /grill-with-docs ist die vorbeugende Lösung, denn eine frühzeitig vereinbarte gemeinsame Sprache verhindert, dass Fachbegriffe überhaupt erst auftauchen.
• /teach: Nutzt das aktuelle Verzeichnis als zustandsbehafteten Arbeitsbereich, um ein Konzept über mehrere Sessions hinweg zu lernen.
• /writing-for-agents ist die Referenz zum Schreiben von Dokumenten für den Agenten: Skills, AGENTS.md/CLAUDE.md, referenzierte Dokumente.
• /handoff: Komprimiert das aktuelle Gespräch in eine Übergabedatei für eine neue Session, ein neues Verzeichnis oder einen Kollegen (siehe „Phasengrenzen“).
• /git-guardrails-claude-code: Installiert einen Claude-Code-Hook, der gefährliche Git-Befehle (push, reset --hard usw.) abfängt, bevor sie ausgeführt werden. Einmal pro Rechner oder Projekt eingerichtet.

Voraussetzungen

/setup-matt-pocock-skills: Führe es vor der ersten Nutzung von Engineering-Prozessen aus, um den Issue-Tracker, Triage-Labels und die Dateistruktur einzurichten, die andere Skills voraussetzen. Unterstützt auch benutzerdefinierte Issue-Tracker.