mattpocock/to-tickets

In Tickets zerlegen

Zerlege einen Plan, eine Spezifikation oder ein Gespräch in eine Reihe von Tickets: Tracer-Bullet-vertikale Scheiben, die jeweils die Tickets deklarieren, die sie blocken.

Der Issue-Tracker und das Triage-Label-Vokabular sollten dir bereitgestellt worden sein. Falls nicht, sage dem Benutzer, er soll /setup-matt-pocock-skills ausführen.

Prozess

1. Kontext sammeln

Arbeite mit dem, was bereits im Gesprächskontext vorhanden ist. Wenn der Benutzer eine Referenz (einen Spezifikationspfad, eine Issue-Nummer oder URL) als Argument übergibt, rufe sie ab und lies ihren vollständigen Text und die Kommentare.

2. Codebasis erkunden (optional)

Wenn du die Codebasis noch nicht erkundet hast, tue dies, um den aktuellen Stand des Codes zu verstehen. Ticket-Titel und -Beschreibungen sollten das domänenspezifische Glossar des Projekts verwenden und ADRs in dem Bereich respektieren, den du berührst.

Suche nach Möglichkeiten, den Code vorzurefaktorisieren, um die Implementierung zu vereinfachen. "Make the change easy, then make the easy change."

3. Vertikale Scheiben entwerfen

Zerlege die Arbeit in Tracer-Bullet-Tickets.

• Jede Scheibe schneidet einen schmalen, aber VOLLSTÄNDIGEN Pfad durch jede Schicht (Schema, API, UI, Tests): vertikal, KEINE horizontale Scheibe einer Schicht
• Eine abgeschlossene Scheibe ist für sich allein demonstrierbar oder verifizierbar
• Jede Scheibe ist so dimensioniert, dass sie in ein einziges frisches Kontextfenster passt
• Jegliche Vorrefaktorisierung sollte zuerst erfolgen

Gib jedem Ticket seine Blockierungskanten: die anderen Tickets, die abgeschlossen sein müssen, bevor es beginnen kann. Ein Ticket ohne Blocker kann sofort starten.

Breite Refaktorisierungen sind die Ausnahme von der vertikalen Scheibenbildung. Eine breite Refaktorisierung ist eine einzige mechanische Änderung (Umbenennen einer Spalte, Neutypisierung eines gemeinsamen Symbols), deren Schadensradius sich über die gesamte Codebasis erstreckt, sodass eine einzelne Bearbeitung Tausende von Aufrufstellen auf einmal zerbricht und keine vertikale Scheibe grün landen kann. Zwinge sie nicht in eine Tracer-Bullet; ordne sie als Expand-Contract an. Expandiere zuerst: füge die neue Form neben der alten hinzu, sodass nichts kaputt geht. Migriere dann die Aufrufstellen in Batches, die nach Schadensradius dimensioniert sind (pro Paket, pro Verzeichnis), jeder Batch sein eigenes Ticket, das durch den Expand blockiert wird, und halte CI von Batch zu Batch grün, weil die alte Form noch existiert. Abschließend kontrahiere: lösche die alte Form, sobald kein Aufrufer mehr vorhanden ist, in einem Ticket, das durch jeden Migrationsbatch blockiert wird. Wenn selbst die Batches nicht allein grün bleiben können, behalte die Reihenfolge bei, aber lass sie einen Integrationszweig teilen, der alle ein abschließendes Integrate-and-Verify-Ticket blockt; grün wird nur dort versprochen.

4. Den Benutzer befragen

Präsentiere die vorgeschlagene Aufteilung als nummerierte Liste. Zeige für jedes Ticket:

• Titel: kurzer beschreibender Name
• Blockiert durch: welche anderen Tickets (falls vorhanden) zuerst abgeschlossen sein müssen
• Was es liefert: das End-to-End-Verhalten, das dieses Ticket funktionsfähig macht

Frage den Benutzer:

• Ist die Granularität richtig? (zu grob / zu fein)
• Sind die Blockierungskanten korrekt: hängt jedes Ticket nur von Tickets ab, die es tatsächlich blockieren?
• Sollten Tickets zusammengeführt oder weiter aufgeteilt werden?

Wiederhole den Vorgang, bis der Benutzer die Aufteilung genehmigt.

5. Die Tickets im konfigurierten Tracker veröffentlichen

Veröffentliche die genehmigten Tickets. Wie hängt vom Tracker ab, den /setup-matt-pocock-skills konfiguriert hat; die Tickets sind gleich, nur die Form der Blockierungskanten ändert sich:

• Lokale Dateien → schreibe eine Datei pro Ticket unter .scratch/<feature-slug>/issues/<NN>-<slug>.md, nummeriert ab 01 in Abhängigkeitsreihenfolge (Blocker zuerst). Jede Datei listet unter "Blockiert durch" die Nummern/Titel, von denen sie abhängt. Verwende die Vorlage für die einzelne Ticketdatei unten: ein Ticket pro Datei, niemals eine einzige kombinierte Datei.
• Ein echter Issue-Tracker (GitHub, Linear, …) → veröffentliche einen Issue pro Ticket in Abhängigkeitsreihenfolge (Blocker zuerst), sodass die Blockierungskanten jedes Tickets reale Bezeichner referenzieren können. Verwende die native Blockierungs-/Unterticket-Beziehung der Plattform, falls vorhanden; andernfalls setze "Blockiert durch" jedes Tickets auf die blockierenden Issues. Wende das Triage-Label ready-for-agent an, sofern nicht anders angewiesen; die Tickets sind von Natur aus agentengreifbar.

Arbeite die Frontier ab: jedes Ticket, dessen Blocker alle erledigt sind. Bei einer rein linearen Kette bedeutet das von oben nach unten.

Schließe oder ändere KEIN übergeordnetes Issue.

:

Was zu bauen ist: das End-to-End-Verhalten, das dieses Ticket funktionsfähig macht, aus der Perspektive des Benutzers, keine schichtweise Implementierungsliste.

Blockiert durch: die Nummern/Titel der Tickets, die dieses blockieren, oder "Keine (kann sofort starten)".

Status: ready-for-agent

• Akzeptanzkriterium 1
• Akzeptanzkriterium 2

Übergeordnet

Ein Verweis auf das übergeordnete Issue im Tracker (falls die Quelle ein bestehendes Issue war; andernfalls diesen Abschnitt weglassen).

Was zu bauen ist

Das End-to-End-Verhalten, das dieses Ticket funktionsfähig macht, aus der Perspektive des Benutzers, nicht schichtweise Implementierung.

Akzeptanzkriterien

• Kriterium 1
• Kriterium 2

Blockiert durch

• Ein Verweis auf jedes blockierende Ticket oder "Keine (kann sofort starten)".

Vermeide in beiden Formen spezifische Dateipfade oder Code-Snippets: sie werden schnell veraltet. Ausnahme: wenn ein Prototyp ein Snippet erzeugt hat, das eine Entscheidung präziser kodiert als Prosa (Zustandsmaschine, Reducer, Schema, Typform), binde es ein und notiere kurz, dass es von einem Prototyp stammt. Reduziere auf die entscheidungsreichen Teile, kein funktionierendes Demo, nur die wichtigen Teile.