g-ki/agent-skills

Aufgabenunterteilung (Task Breakdown)

Ein Design in einen Backlog aus 1-Story-Point-Tickets verwandeln, die jeder Entwickler im Team aufnehmen, abschließen und eigenständig mergen kann.

Eingabe

$ARGUMENTS

• Wenn ein Pfad angegeben ist, dieses Dokument lesen.
• Andernfalls das letzte RFC oder die *.notes.md-Datei aus einer "Productive-Thinking"-Sitzung in dieser Konversation oder auf der Festplatte verwenden. Dabei handelt es sich in der Regel um lokale, unversionierte Dateien (in git-ignorierten Ordnern wie .rfcs/ suchen, dann in docs/rfcs/, docs/adr/, rfcs/). Wenn keine gefunden werden, fragen, welches Dokument oder Design zerlegt werden soll.
• Wenn die Quelle Lücken aufweist, die das Aufteilen blockieren (kein gewähltes Design, kein Rollout-Ansatz), diese auflisten und fragen, bevor Antworten erfunden werden. Kleine Lücken können stattdessen zu Spike-Tickets werden.

Was „1 Story Point“ hier bedeutet

Ein Ticket ist 1 Punkt, wenn alle der folgenden Bedingungen zutreffen. Wenn eine davon nicht erfüllt ist, teilen Sie es auf:

1. Eine Person, etwa ein Tag oder weniger, inklusive Tests und Review-Korrekturen.
2. Ein PR zum Review mit einem einzigen Zweck. Ein Reviewer kann ihn verstehen, ohne andere offene PRs zu lesen.
3. Eigenständig mergebar. Der Hauptzweig bleibt grün und auslieferbar, nachdem das Ticket gemerged wurde, was normalerweise bedeutet, dass neues Verhalten hinter einem Feature-Flag verborgen ist oder noch nicht verdrahtet ist.
4. Testbar. Es gibt 1–5 Abnahmekriterien, die jemand anderes als der Autor überprüfen kann.
5. Keine versteckten Unbekannten. Wenn der Implementierer erst recherchieren müsste, um zu wissen, was zu tun ist, handelt es sich um einen Spike, nicht um eine Story.

Wenn das Team eine eigene Definition eines Punkts hat, dieser folgen und dies oben in der Ausgabe vermerken.

Wie aufgeteilt wird

Den Code vor dem Aufteilen lesen: Bestätigen, dass die Dateien, Module, Schemata und Tests, die jedes Ticket betrifft, tatsächlich existieren, und sie im Ticket benennen. Tickets, die echte Pfade nennen, werden aufgegriffen; vage Tickets bleiben im Backlog liegen.

Mit einem Walking Skeleton beginnen: der dünnste End-to-End-Slice, der beweist, dass das Design in Produktion funktioniert (oft hinter einem Flag), und dann verdicken. Dadurch wird das Risiko nach vorne verlagert, anstatt Integrationsprobleme im letzten Ticket zu entdecken.

Wenn ein Ticket zu groß ist, funktionieren diese Aufteilungen normalerweise:

• Vorbereiten, dann ändern. Zuerst ein reines Refactoring herausziehen ("die Änderung einfach machen, dann die einfache Änderung durchführen"), mit Tests, die das aktuelle Verhalten vor dem Refactoring fixieren.
• Erweitern / Migrieren / Kontrahieren für Schema- und API-Änderungen: neue Spalte oder neuen Endpoint hinzufügen, Backfill oder Dual-Write durchführen, Lesezugriffe umstellen, dann den alten Pfad entfernen. Jede Phase ist ein eigenes Ticket.
• Nach Ebene hinter einem Flag: Datenmodell → Service-Logik → API → UI, jeweils mergebar, weil das Flag ausgeschaltet ist.
• Lesepfad vor Schreibpfad und Happy Path vor Edge Cases und Fehlerbehandlung.
• Nach Variante: ein Ticket pro Provider, Dateityp oder Client, nachdem das erste das Muster etabliert hat.
• Spikes für Unbekanntes: zeitlich begrenzt (≤ 1 Tag), und die Ausgabe ist eine Entscheidung plus Folge-Tickets, kein Produktivcode. Jeder Spike erhält eine Frage: mit einer Antwort und eine Zeitbox. Tickets, die von der Entscheidung abhängen, werden nur so weit aufgeteilt, wie es sicher ist, mit einem Hinweis, dass sie verfeinert werden, sobald der Spike entschieden ist. Spikes früh platzieren: sie blockieren alles dahinter.

Die Arbeit nicht vergessen, die kein Feature-Code ist: Einrichtung und Entfernung von Feature-Flags, Metriken/Alarme/Dashboards, Runbook- oder Dokumentationsaktualisierungen, Daten-Backfills, stufenweise Rollout-Schritte und Bereinigung des alten Pfads. Hier bleiben Projekte normalerweise stecken, die "fast fertig" sind.

Nicht um des Aufteilens willen aufteilen: Ein Ticket, das nur zusammen mit einem anderen sinnvoll gemerged werden kann, sollte ein Ticket sein, oder das Paar sollte entlang einer anderen Naht neu geschnitten werden.

Ausgabe

1. Den Backlog mit templates/tasks.md als <rfc-name>.tasks.md neben dem Quell-RFC schreiben. Wie der RFC ist es eine lokale Arbeitsdatei, standardmäßig unversioniert; falls ihr Ordner noch nicht in git ignoriert wird, zu .git/info/exclude hinzufügen. Tickets mit T-01, T-02, … nummerieren, damit Abhängigkeiten darauf verweisen können, jeden Status auf open setzen und den Projekt-Slug für Branch-Namen eintragen. Die Feldnamen genau wie in der Vorlage halten, da /implement-task und /deliver-project sie lesen.
2. Tickets in Meilensteine gruppieren, die den Phasen des RFCs entsprechen, die jeweils in etwas enden, das demonstrierbar oder auslieferbar ist.
3. Das Abhängigkeitsbild einfügen: Welche Tickets können parallel laufen und der kritische Pfad. Ein kleiner Mermaid-Graph ist geeignet, wenn es mehr als ~8 Tickets gibt.
4. Im Chat eine kurze Zusammenfassung geben: Anzahl der Tickets pro Meilenstein, wie viele sofort gestartet werden können, der kritische Pfad, Spikes und alle Tickets, bei denen nicht sicher ist, ob sie wirklich 1 Punkt sind. Den Benutzer bitten, Tickets zu markieren, die zu groß, zu klein oder falsch geordnet erscheinen, und überarbeiten.
5. Im Tracker des Teams veröffentlichen. Angenommen, das Team verwendet einen (Linear, Jira, GitHub Issues, …). Sobald der Benutzer mit der Aufteilung zufrieden ist, anbieten, über das verbundene Tracker-Tool zu veröffentlichen; wenn keins verbunden ist, sagen, welcher Connector helfen würde, und als Fallback eine CSV mit den Spalten ID, Title, Description, Acceptance Criteria, Story Points, Milestone, Depends On, Labels anbieten. Erst nach Bestätigung des Benutzers veröffentlichen, da es für das gesamte Team sichtbar ist. Für jedes Ticket ein Issue erstellen mit Titel, einer Beschreibung, die für sich allein steht (Kontext, Umfang, Dateien, nicht zum Umfang gehörig, Abnahmekriterien), Schätzung 1, dem Meilenstein und blockiert-von-Beziehungen für seine Abhängigkeiten, soweit der Tracker sie unterstützt. Dann den Issue-Key und -Link in das Feld Tracker: des Tickets in der lokalen Datei schreiben.
6. Auf den nächsten Schritt verweisen: /implement-task <ticket-id> für ein einzelnes Ticket, /spike-task <ticket-id> für einen Spike oder /deliver-project <tasks-file>, um den gesamten Backlog mit einem Team von Agenten auszuführen.

Wenn das Quell-RFC einen Bereich „Ausführungsplan“ hat, diesen aktualisieren, um auf die Aufgaben-Datei zu verlinken, anstatt die Liste zu duplizieren.

Verfeinerung nach einem Spike

Wenn der Entscheidungsdatensatz eines entschiedenen Spikes (Status decided) übergeben wird, den Backlog aktualisieren, anstatt neu zu beginnen:

1. Die genehmigten Backlog-Änderungen aus dem Datensatz anwenden: Tickets hinzufügen (die T-NN-Nummerierung fortsetzen, IDs nie wiederverwenden), Umfang, Kriterien oder Abhängigkeiten betroffener Tickets ändern und entfernte Tickets als canceled mit Grund markieren, anstatt sie zu löschen.
2. Jedes geänderte oder neue Ticket erneut gegen den 1-Punkt-Test prüfen und die Zusammenfassung, den Abhängigkeitsgraphen und den kritischen Pfad aktualisieren.
3. Die RFC-Abschnitte aktualisieren, die der Datensatz auflistet.
4. Den Tracker synchronisieren: Neue Issues erstellen, geänderte aktualisieren und entfernte löschen, dabei die neuen Schlüssel in die Aufgaben-Datei schreiben. Wenn der Benutzer die Entscheidung und ihre Backlog-Änderungen gemeinsam genehmigt hat, deckt diese Genehmigung die Synchronisierung ab; andernfalls zuerst bestätigen lassen.
5. Den Spike auf done setzen und in ein paar Zeilen zusammenfassen, was sich geändert hat.