Tasks abrufen

Überblick

get-tasks wandelt ein genehmigtes PRD in eine ausführbare Reihe von Aufgaben um. Jede Aufgabe wird in eine eigene Datei geschrieben, auf eine einzelne fokussierte Sitzung zugeschnitten, nach Abhängigkeiten geordnet und mit Abnahmekriterien, Validierungsschritten, einer Blockierungsliste und einem Rollback-Verfahren ausgeliefert.

Der Grund, warum dies als eigener Skill existiert: Ein PRD ist kein Plan. Ein PRD beschreibt, was das System tut und warum. Es sagt nichts über die Reihenfolge der Arbeit, was parallel gebaut werden kann, wo die riskanten Teile sind oder wie man beweist, dass ein Teil fertig ist. Ein PRD direkt in Code zu übersetzen, führt entweder zu einem heroischen Single-Pass-Änderung oder einer willkürlichen Reihenfolge, die auf halbem Weg zerbricht.

get-tasks liefert die fehlende Schicht. Es liest das PRD, bildet die tatsächliche Abhängigkeitsstruktur ab, schneidet die Arbeit in vertikale Scheiben und schreibt jede Scheibe als eigenständiges Artefakt, das ein Agent (oder ein Mensch) aufnehmen kann, ohne das gesamte PRD erneut zu lesen.

Dieser Skill stützt sich auf drei Quellen:

Abhängigkeitserste Zerlegung und vertikales Slicing — einen Abhängigkeitsgraphen erstellen, vertikal statt horizontal schneiden, jede Aufgabe dimensionieren und Kontrollpunkte setzen. Das macht die Reihenfolge korrekt.
Validierungsgesteuerte Ausführung — jede Aufgabe deklariert, wie sie über mehrere Validierungstypen verifiziert wird, nicht nur "Tests bestehen", und enthält eine Neuplanungsprozedur für den Fall, dass ein Schritt fehlschlägt.
Blockierungskanten und Tracer Bullets — jede Aufgabe gibt explizit an, was sie blockiert, sodass jede Aufgabe, deren Blocker erledigt sind, sofort beginnen kann.

Das Ergebnis ist ein Verzeichnis mit Aufgabendateien: tasks/<name>/task-01.md, task-02.md usw., nummeriert in Abhängigkeitsreihenfolge, plus tasks/<name>/plan.md, die sie indexiert. Blocker-Aufgaben erhalten die niedrigen Nummern.

Umfang dieses Skills

get-tasks ist bewusst umfassend. Es absorbiert, was mehrere engere Skills jeweils teilweise erledigt haben, sodass ein Benutzer nur einen Skill benötigt, um von einem genehmigten PRD zu einem nachverfolgbaren, ausführbaren Plan zu gelangen. Alles hier ist für diese einzelne Aufgabe relevant:

Betreff	Wo es behandelt wird
Lesen des PRD und Extrahieren von Verpflichtungen	Phase 1
Abhängigkeitsstruktur und -reihenfolge	Phase 2
Vertikales Slicing und Tracer Bullets	Phase 3
Breite Refactorings (erweitern, migrieren, zusammenziehen)	Phase 3
Pro-Aufgabe-Spezifikation	Phase 4
Dimensionierung und Aufteilungsregeln	Phase 5
Kontrollpunkte und Tore	Phase 5
Parallelisierungsklassifikation	Parallelisierungs-Taxonomie
Für Menschen lesbare Planzusammenfassung, Risiken, Entscheidungen	Phase 6
Tracker vs. Dateiziel	Aufgabenlisten-Ziel
Benutzerfreigabe vor dem Schreiben	Phase 7
Schreiben, Synchronisieren und Verifizieren von Artefakten	Phase 8
Umgang mit Fehlern und Neuplanung	Neuplanung, wenn eine Aufgabe fehlschlägt

Es ist absichtlich lang. Die Länge ist der Punkt: Eine Aufschlüsselung, die eines dieser Dinge implizit lässt, erzeugt Aufgaben, die fertig aussehen, es aber nicht sind. Wenn Sie versucht sind, zur Vorlage zu blättern, lesen Sie stattdessen die Phasen 2, 3 und 5 – dort scheitern Aufschlüsselungen tatsächlich.

Was dieser Skill nicht tut: Er schreibt keinen Code, führt die Aufgaben nicht aus und ersetzt nicht das PRD. Er wandelt ein Dokument in eine Reihe von Dokumenten um.

Wann zu verwenden

Verwenden Sie diesen Skill, wenn:

Ein PRD, eine Spezifikation oder ein Anforderungsdokument existiert und die Arbeit in ausführbare Aufgaben umgewandelt werden muss
Der Benutzer sagt "get tasks", "breakdown PRD", "pecah jadi task", "bikin task list" oder "mach daraus Aufgaben"
Eine Aufgabe fühlt sich zu groß an, um zu beginnen, und muss zerlegt werden
Sie den Umfang abschätzen, die Arbeit ordnen oder herausfinden müssen, was parallel laufen kann
Sie im Begriff sind, etwas zu implementieren, das mehr als eine Handvoll Dateien betrifft, und keine Aufgabenliste existiert

Wann NICHT zu verwenden:

Es existiert noch kein PRD – führen Sie zuerst get-prd aus, dann kommen Sie zurück
Die Änderung ist nach jedem Maßstab eine einzelne Aufgabe (eine Datei, eine offensichtliche Bearbeitung) – machen Sie sie einfach
Eine vollständige Aufgabenaufschlüsselung existiert bereits in tasks/ und Sie sind bereit zur Implementierung – fahren Sie direkt mit der Ausführung der Aufgaben in der Reihenfolge fort

Der Prozess

get-tasks läuft in neun Phasen. Jede Phase hat eine Abbruchbedingung. Fahren Sie nicht mit einer Phase fort, deren Abbruchbedingung nicht erfüllt ist.

0. PRD lokalisieren       -> Welches Dokument ist die Quelle?
1. Lesen und extrahieren  -> Wozu verpflichtet uns das PRD?
2. Abhängigkeitsgraph     -> Was hängt von was ab?
3. Vertikale Scheiben     -> Tracer Bullets, keine horizontalen Ebenen
4. Jede Aufgabe schreiben -> Eine Datei pro Aufgabe, vollständig spezifiziert
5. Ordnen, dimensionieren, Kontrollpunkte setzen -> Reihenfolge, Größe und Verifikationstore
6. Das Plan-Dokument schreiben -> Die für Menschen lesbare Zusammenfassung, die die Aufgaben indexiert
7. Benutzer befragen      -> Granularität, Blockierungskanten, zusammenführen oder aufteilen
8. Schreiben und verifizieren -> Dateien auf der Festplatte, Todos synchronisiert, Validatoren grün

Universelle Prinzipien für Aufgabenaufschlüsselung

Natürliche Sprachgeschwindigkeit: Präsentieren Sie die Aufschlüsselung und zusammenfassenden Gespräche in der Sprache, die der Benutzer spricht (Indonesisch oder Englisch), während Sie Dateinamen, Git-Begriffe und Code-Token standardmäßig halten (task-01.md, branch, commit, TDD).
Autonome Ausführungsbereitschaft: Jede generierte Aufgabendatei in tasks/<feature>/task-*.md muss vollständig in sich geschlossen sein. Jeder Codierungsagent sollte in der Lage sein, nur diese eine Aufgabendatei zu lesen, zu wissen, welche Dateien zu bearbeiten sind, welche Tests auszuführen sind und welche Definition von "erledigt" erfüllt sein muss, ohne raten zu müssen.
Vertikale Scheiben über horizontale Ebenen: Erstellen Sie niemals Aufgaben, die isoliert rein "Backend einrichten" oder "Frontend einrichten" sind, wenn sie nicht Ende-zu-Ende verifiziert werden können. Schneiden Sie vertikal (z. B. "SKU-Endpunkt speichern & abfragen mit UI-Trigger"), sodass jede Aufgabe testbaren Wert liefert.

Planung ist schreibgeschützt. Die Phasen 0 bis 7 produzieren Dokumente und Fragen, keinen Code. Erstellen, bearbeiten oder löschen Sie während dieser Phasen keine Quelldatei. Das Schreiben von Aufgabendateien unter tasks/ ist die einzige Dateisystemänderung, die vor der Genehmigung durch den Benutzer erlaubt ist. Wenn Sie dabei ertappen, einen Fehler zu beheben oder eine Funktion hinzuzufügen, während Sie die Arbeit aufschlüsseln, hören Sie auf: Das gehört zur Implementierung nach der Genehmigung und zu einer Aufgabe, die Sie noch nicht geschrieben haben.

Phase 0: PRD lokalisieren

Finden Sie das Quelldokument, bevor Sie irgendetwas anderes tun.

Konvention zuerst. get-prd speichert in docs/prd/<name>.md. Suchen Sie zuerst dort.
Dann die breitere Suche. Wenn docs/prd/ leer ist, suchen Sie nach einem PRD, das der Benutzer nennt. Akzeptieren Sie einen Issue-Body oder ein eingefügtes Anforderungsdokument – der Skill ist nicht formatgebunden, nur die Extraktion in Phase 1 setzt die PRD-Abschnittsnamen voraus.
Wenn mehr als ein Kandidat existiert, raten Sie nicht. Listen Sie sie auf und fragen Sie, welcher diese Arbeit regelt.
Wenn keiner existiert, stoppen Sie und sagen Sie es. Erfinden Sie keine Anforderungen. Leiten Sie den Benutzer zu get-prd für einen vollständigen Interview-zu-PRD-Durchlauf um.

Notieren Sie den genauen Pfad, von dem Sie arbeiten. Jede spätere Phase referenziert ihn.

Für eine Multi-Modul-Initiative, bei der das PRD nach Modul-ID aufgeteilt ist (docs/prd/identity.md, docs/prd/billing.md), bestätigen Sie, welches Modul diese Aufschlüsselung abdeckt. Eine Aufschlüsselung pro Modul, in der Build-Reihenfolge, die die Fähigkeitskarte festgelegt hat.

Abbruchbedingung: Ein einzelnes Quelldokument ist identifiziert, und sein Pfad ist dokumentiert.

Phase 1: Lesen und Extrahieren

Lesen Sie das PRD vollständig. Extrahieren Sie dann explizit das Material, das die Zerlegung steuert:

PRD-Abschnitt	Was Sie daraus extrahieren
Ziel	Der Endzustand, dem jede Aufgabe letztendlich dient
User Stories	Die beobachtbaren Verhaltensweisen, die funktionieren müssen, Kandidaten für Abnahmekriterien
Technische Entscheidungen	Module, Schnittstellen, Schemaänderungen, Verträge – diese definieren echte Grenzen zwischen Aufgaben
Projektstruktur	Wo Artefakte landen, was die "wahrscheinlich berührten Dateien" einschränkt
Befehle	Die konkreten Verifikationsbefehle, die jede Aufgabe zitieren wird
Teststrategie	Was hier als guter Test gilt und wo Tests hingehören
Grenzen	Immer / Zuerst Fragen / Niemals – Niemals-Punkte werden zu harten Einschränkungen für jede Aufgabe
Ausgeschlossen	Explizite Nicht-Ziele; nichts davon wird eine Aufgabe
Erfolgskriterien	Das endgültige Tor; der letzte Kontrollpunkt verifiziert dagegen

Regeln:

Beginnen Sie noch nicht mit dem Schneiden. Erst Extraktion, dann Zerlegung. Das Schneiden während des Lesens erzeugt Aufgaben, die durch die Reihenfolge geformt sind, in der Sie das Dokument gelesen haben.
Wandeln Sie vage Punkte in überprüfbare Aussagen um. Wenn das PRD sagt "das Dashboard sollte schnell sein", ist das Abnahmekriterium der Aufgabe eine Zahl, und wenn das PRD keine Zahl angegeben hat, machen Sie es als Blocker sichtbar, anstatt stillschweigend eine zu wählen.
Markieren Sie Lücken. Wenn ein benötigter Abschnitt fehlt oder leer ist, nennen Sie ihn. Eine fehlende Teststrategie bedeutet, dass der Verifikationsblock jeder Aufgabe später erfunden wird; sprechen Sie es jetzt an.
Erfinden Sie niemals Anforderungen. Wenn das PRD es nicht sagt, ist es keine Aufgabe.

Abbruchbedingung: Die Extraktionstabelle ist ausgefüllt, und jede Lücke wurde dem Benutzer mitgeteilt.

Phase 2: Den Abhängigkeitsgraphen abbilden

Bevor Sie eine einzelne Aufgabe schreiben, bilden Sie ab, was von was abhängt. Dies ist die Phase, die die Reihenfolge bestimmt und die teuerste Art von Fehler verhindert: einen Konsumenten zu bauen, bevor sein Produzent existiert.

Zeichnen Sie den Graphen. Konkret, nicht abstrakt:

Datenbankschema
    |
    +-- API-Modelle und -Typen
    |       |
    |       +-- API-Endpunkte
    |       |       |
    |       |       +-- Frontend-API-Client
    |       |               |
    |       |               +-- UI-Komponenten
    |       |
    |       +-- Validierungslogik
    |
    +-- Seed-Daten und Migrationen

Regeln:

Kanten zeigen vom Produzenten zum Konsumenten. Ein Pfeil bedeutet "das Ziel braucht zuerst die Quelle".
Keine Zyklen. Wenn zwei Dinge jeweils das andere brauchen, sind sie eine Aufgabe, oder die Schnittstelle zwischen ihnen muss zuerst als eigene Aufgabe definiert werden.
Schnittstellen sind Grenzen. Wenn zwei Aufgaben an einem Vertrag aufeinandertreffen (ein Typ, eine Endpunktform, ein Schema), definieren Sie den Vertrag in der früheren Aufgabe und konsumieren Sie ihn in der späteren. Lassen Sie niemals beide Aufgaben ihn unabhängig erfinden.
Finden Sie die Frontlinie. Die Frontlinie ist jede Aufgabe, deren Blocker alle erledigt sind. Sie ist das, was jetzt starten kann. Für eine lineare Kette ist die Frontlinie eine Aufgabe breit; für ein breites Projekt kann es mehrere sein.
Nennen Sie die Parallelisierungsmöglichkeiten und die harten Sequenzen. Unabhängige Scheiben können parallel laufen. Migrationen, gemeinsame Zustandsänderungen und alles, was denselben Vertrag berührt, müssen sequentiell sein.

Abbruchbedingung: Ein Abhängigkeitsgraph existiert, mit einer klaren Frontlinie und keinen Zyklen.

Phase 3: Vertikal schneiden

Schneiden Sie die Arbeit in Tracer Bullets: schmale, aber vollständige Pfade durch jede Schicht, die die Funktion benötigt.

Horizontales Schneiden ist der Standardfehler. Es sieht ordentlich aus und produziert nichts Lauffähiges bis zur letzten Aufgabe:

Schlecht (horizontal):
Aufgabe 1: Das gesamte Datenbankschema bauen
Aufgabe 2: Alle API-Endpunkte bauen
Aufgabe 3: Alle UI-Komponenten bauen
Aufgabe 4: Alles verbinden

Am Ende von Aufgabe 3 funktioniert nichts. Niemand kann etwas demonstrieren. Eine falsche Annahme in Aufgabe 1 wird in Aufgabe 4 entdeckt.

Vertikales Slicing produziert bei jedem Schritt funktionsfähige Software:

Gut (vertikal):
Aufgabe 1: Ein Benutzer kann ein Konto erstellen (Schema + API + UI für Registrierung)
Aufgabe 2: Ein Benutzer kann sich einloggen (Auth-Schema + API + UI für Login)
Aufgabe 3: Ein Benutzer kann eine Aufgabe erstellen (Aufgaben-Schema + API + UI für Erstellung)
Aufgabe 4: Ein Benutzer kann die Aufgabenliste anzeigen (Abfrage + API + UI für Listenansicht)

Regeln für einen guten Schnitt:

Er schneidet durch jede Schicht, die das Verhalten benötigt – Daten, Logik, Schnittstelle, Test.
Er ist eigenständig demonstrierbar oder verifizierbar. Wenn Sie nicht beschreiben können, wie Sie bestätigen, dass es funktioniert, ist es kein Schnitt.
Er passt in eine fokussierte Sitzung – ungefähr ein frischer Kontext-Fenster.
Er liefert Verhalten, nicht Struktur. "Die Benutzertabelle hinzufügen" ist kein Schnitt; "Ein Benutzer kann sich registrieren" ist einer.

Breite Refactorings sind die Ausnahme. Ein breites Refactoring ist eine mechanische Änderung (eine Spalte umbenennen, ein gemeinsam genutztes Symbol umtypisieren), deren Auswirkungsradius sich über die gesamte Codebasis erstreckt, sodass kein vertikaler Schnitt grün landen kann. Zwingen Sie es nicht in einen Tracer Bullet. Sequenzieren Sie es als erweitern, migrieren, zusammenziehen:

Erweitern – fügen Sie die neue Form neben der alten hinzu, sodass nichts kaputt geht.
Migrieren – verschieben Sie Aufrufstellen in Batches, die nach Auswirkungsradius dimensioniert sind (pro Paket, pro Verzeichnis), jeder Batch seine eigene Aufgabe, blockiert durch die Erweiterung, und halten Sie den Build von Batch zu Batch grün, weil die alte Form noch existiert.
Zusammenziehen – löschen Sie die alte Form, sobald kein Aufrufer mehr übrig ist, in einer Aufgabe, die von jedem Migrations-Batch blockiert wird.

Wenn selbst die Batches nicht allein grün bleiben können, behalten Sie dieselbe Sequenz bei, aber lassen Sie sie einen Integrationszweig teilen, der alle einen finalen Integrieren-und-Verifizieren-Aufgabe blockiert, wo Grün versprochen wird.

Abbruchbedingung: Jedes Arbeitspaket gehört zu genau einer Aufgabe, und jede Aufgabe ist ein vertikaler Schnitt oder ein deklarierter Schritt eines breiten Refactorings.

Phase 4: Jede Aufgabe schreiben

Schreiben Sie jede Aufgabe als eigene Datei. Eine Aufgabe pro Datei, immer – niemals ein einzelnes kombiniertes Dokument mit allen Aufgaben darin.

Ausgabepfad: tasks/<name>/task-NN.md, wobei <name> mit dem Namen des PRD übereinstimmt (also ein PRD unter docs/prd/billing.md erzeugt tasks/billing/task-01.md). Nummerieren Sie ab 01, in Abhängigkeitsreihenfolge – Blocker erhalten die niedrigen Nummern.

Vorlage für Aufgabendatei:

# Aufgabe NN: <Kurzer beschreibender Titel>

**Quelle:** docs/prd/<name>.md – <PRD-Abschnitt, den diese Aufgabe implementiert>

**Was zu bauen ist:** Das Ende-zu-Ende-Verhalten, das diese Aufgabe zum Laufen bringt, aus der
Perspektive des Benutzers. Keine schichtweise Implementierungsliste. Wenn Sie es nicht als Verhalten beschreiben können, das ein Benutzer oder Aufrufer beobachten kann, formen Sie die Aufgabe um.

## Abnahmekriterien

- [ ] <spezifische, überprüfbare Bedingung>
- [ ] <spezifische, überprüfbare Bedingung>

Jedes Kriterium muss von jemandem überprüfbar sein, der die Aufgabe nicht geschrieben hat. "Funktioniert korrekt" ist kein Kriterium. "Ein Benutzer kann sich mit einer E-Mail-Adresse und einem Passwort registrieren und wird zum Dashboard weitergeleitet" ist eines.

## Verifikation

- [ ] Tests bestehen: <der fokussierte Testbefehl des Repositorys oder der neue Test, der zuerst geschrieben werden soll>
- [ ] Build erfolgreich: <der Build-Befehl des Repositorys>
- [ ] Ausgabe stimmt überein: <erwartetes Muster oder Artefakt, das existieren muss>
- [ ] Keine Regressionen: <die vollständige Suite oder die relevante Teilmenge>
- [ ] Qualität & Sicherheit: <Eingabevalidierung, Auth-Grenzen, befolgt>

...

Regeln für jede Aufgabe:

Enthalten, was sie braucht. Eine Aufgabe darf auf andere Aufgaben verweisen, muss aber alles enthalten, was für ihre Ausführung notwendig ist – die genauen zu bearbeitenden Dateien, den genauen Befehl zum Ausführen von Tests, das genaue erwartete Ergebnis.
Nicht mehr als das, was sie braucht. Kein Hintergrundkontext, der nicht direkt relevant ist. Keine Spekulation über zukünftige Aufgaben.
Erwähnen Sie das Gesamtbild genau einmal – in einem "Warum diese Aufgabe jetzt"-Satz, der auf die Abhängigkeitskarte verweist. Danach nur die Aufgabe.
Schreiben Sie die Aufgabe so, dass ein anderer Agent sie ausführen kann. Wenn Ihr Prompt-Kontext die einzige Stelle ist, an der die Logik einer Aufgabe lebt, ist sie nicht geschrieben.

Phase 5: Ordnen, dimensionieren, Kontrollpunkte setzen

Sobald alle Aufgaben als Dateien existieren, ordnen Sie sie in die richtige Reihenfolge und dimensionieren Sie jede.

Ordnungsregeln

Abhängigkeiten zuerst. Keine Aufgabe beginnt, bevor ihre Blocker erledigt sind.
Wert zuerst. Wenn zwei Aufgaben gleich viele Blocker haben, wählen Sie diejenige, die den sichtbarsten oder testbarsten Wert liefert.
Risiko zuerst. Wenn eine Aufgabe ein hohes Risiko birgt (ungewohnte Technologie, unscharfe Anforderungen, viele unbekannte Abhängigkeiten), schieben Sie sie nach vorne, nicht nach hinten. Ein frühes Scheitern ist billiger.
Parallelisieren, wenn möglich. Wenn zwei Aufgaben keine gemeinsamen Blocker haben und kein gemeinsames Artefakt berühren, können sie parallel zugewiesen werden.

Dimensionierungsregeln

Ziel: Eine fokussierte Sitzung. Wenn Sie glauben, dass eine Aufgabe einen frischen Kontext erfordert, ist sie wahrscheinlich zu groß. Teilen Sie sie auf.
Wenn die Aufgabe breit ist, teilen Sie sie vertikal. Wenn die Aufgabe viele Dateien berührt, aber nur eine Schicht, teilen Sie sie lieber nach Verhalten als nach Datei.
Wenn die Aufgabe tief ist, teilen Sie sie horizontal. Wenn die Aufgabe viele Schichten durchschneidet (Datenbank bis Frontend), aber jede Schicht einfach ist, kann eine einzelne Aufgabe ausreichen. Wenn jede Schicht komplex ist, teilen Sie sie auf, aber stellen Sie sicher, dass jeder Teil Ende-zu-Ende verifizierbar ist.

Kontrollpunkte

Ein Kontrollpunkt ist ein Tor, das bestätigt, dass die Aufgabe wie angegeben funktioniert, bevor die nächste Aufgabe beginnt. Jede Aufgabe muss mindestens einen Kontrollpunkt haben:

Kontrollpunkt-Typ	Beschreibung
Testbestehen	Das Repositorys Testsuite (oder die relevante Teilmenge) läuft ohne Fehler
Build erfolgreich	Das Repository baut ohne Fehler (Kompilierung, Linting, Typen)
Ausgabe übereinstimmend	Ein erwartetes Artefakt existiert oder ein bestimmtes Muster wird in der Ausgabe gefunden
Keine Regressionen	Die vollständige Suite oder eine repräsentative Teilmenge läuft und bestehende Tests sind nicht gebrochen
Qualität & Sicherheit	Eingabevalidierung, Auth-Grenzen, sensible Daten werden angemessen behandelt

Jeder Kontrollpunkt muss mit einem spezifischen Befehl oder einer spezifischen Aktion verifizierbar sein. "Tests bestehen" allein reicht nicht; es muss der genaue Befehl zum Ausführen der Tests und das erwartete Ergebnis (z. B. "0 Fehler, 5 bestandene Tests") vorhanden sein.

Phase 6: Das Plan-Dokument schreiben

Nachdem alle Aufgaben geschrieben, geordnet und dimensioniert sind, schreiben Sie die plan.md.

Ausgabepfad: tasks/<name>/plan.md

Die plan.md indexiert die Aufgaben und fasst sie für Menschen zusammen. Ein KI-Agent kann die Aufgaben direkt ausführen, aber ein menschlicher Betreuer oder Architekt sollte in der Lage sein, die plan.md zu lesen, um den Umfang, die Reihenfolge und die Risiken zu verstehen, ohne jede Aufgabendatei öffnen zu müssen.

Plan-Datei-Vorlage:

# Plan: <Name>

**Quelle:** docs/prd/<name>.md

## Zusammenfassung

<2-3 Sätze darüber, was diese Reihe von Aufgaben erreicht>

## Aufgaben

| # | Titel | Blocker | Geschätzte Größe | Verifikation*
|---|---|---|---|---|
| 01 | <Title> | – | Mittel | Tests, Build |
| 02 | <Title> | 01 | Mittel | Tests, Build, Ausgabe |
| … | … | … | … | … |

\* Verifikationsspalte zitiert die Kontrollpunkt-Typen aus Phase 5.

## Abhängigkeitsgraph


## Risiken und Entscheidungen

- **Risiko:** <Beschreibung des Risikos> — <Minderungsstrategie>
- **Entscheidung:** <Beschreibung der Entscheidung> — <Begründung>

## Frontlinie

<Die Frontlinie ist der Satz von Aufgaben, die mit der nächsten Implementierungsrunde beginnen können:
Aufgabe XX (<Titel>), Aufgabe YY (<Titel>) …>

Phase 7: Benutzer befragen

Bevor Sie etwas auf die Festplatte schreiben, präsentieren Sie dem Benutzer den Plan zur Genehmigung. Der Plan umfasst:

Aufgabenliste (Tabelle aus Phase 6)
Abhängigkeitsgraph (Phase 2)
Risiken und Entscheidungen (Phase 6)
Frontlinie (Phase 5)
Mögliche Probleme (aus Phase 1 extrahiert)

Stellen Sie diese Fragen:

Granularität: Sind die Aufgaben zu fein oder zu grob? Möchten Sie, dass ich einige zusammenführe oder aufteile?
Blockierungskanten: Gibt es Abhängigkeiten, die ich falsch eingeschätzt habe?
Reihenfolge: Ist die Reihenfolge korrekt? Gibt es etwas, das früher oder später passieren sollte?
Ausgeschlossenes: Fehlt etwas Offensichtliches? (Überprüfen Sie dies doppelt – wenn etwas fehlt, ist die Aufschlüsselung unvollständig, und Sie müssen zu Phase 2 oder 3 zurückkehren)

Nicht zur Genehmigung einreichen, bevor Sie die obigen Schritte durchlaufen haben. Wenn Sie den Benutzer beim ersten Mal nach der Extraktion konsultieren, haben Sie die Entscheidungen noch nicht getroffen, die den Wert der Aufschlüsselung ausmachen.

Abbruchbedingung: Der Benutzer genehmigt den Plan oder gibt Anpassungen an. Wenn Anpassungen gewünscht werden, nehmen Sie sie vor und legen Sie sie erneut zur Genehmigung vor.

Phase 8: Schreiben und verifizieren

Sobald der Plan genehmigt ist:

Verzeichnis erstellen: tasks/<name>/
Aufgabendateien schreiben: task-01.md, task-02.md, … gemäß den Vorlagen aus Phase 4
Plan-Datei schreiben: plan.md gemäß der Vorlage aus Phase 6
Dateien verifizieren: Stellen Sie sicher, dass jede Datei existiert und gültiges Markdown enthält. Keine leeren Dateien.
Traker synchronisieren: Wenn Sie einen Aufgaben-Tracker verwenden, aktualisieren Sie ihn jetzt (optional, abhängig vom Skill-Kontext)
Validatoren auf Grün setzen: Stellen Sie sicher, dass die Ausgabe konsistent ist und keine offensichtlichen Fehler enthält

Keine Quelldateien erstellen, bearbeiten oder löschen. Die einzige Änderung am Dateisystem ist das Schreiben in tasks/<name>/.

Abbruchbedingung: tasks/<name>/ existiert mit task-01.md, task-02.md, … und plan.md, und jede Datei enthält gültigen Inhalt.

Fehlerbehandlung

Umgang mit ungültigem PRD

Wenn das PRD keine Abnahmekriterien hat, fragen Sie den Benutzer, bevor Sie welche erfinden
Wenn das PRD widersprüchliche Anforderungen enthält, markieren Sie den Widerspruch und fahren Sie nicht fort, bis er gelöst ist
Wenn das PRD technisch unmöglich ist (basierend auf bekanntem Wissen), sagen Sie es und stoppen Sie

Neuplanung, wenn eine Aufgabe fehlschlägt

Wenn während der Implementierung eine Aufgabe fehlschlägt:

Bestimmen Sie den Fehlermodus:
- Blockierender Fehler: Die Aufgabe kann nicht wie angegeben abgeschlossen werden.
- Teilweiser Fehler: Ein Teil der Aufgabe ist abgeschlossen, aber nicht alle Kriterien sind erfüllt.
Entscheidungsbaum:
- Wenn der Fehler auf ein fehlerhaftes Abnahmekriterium zurückzuführen ist: Aktualisieren Sie die Aufgabe und fahren Sie fort.
- Wenn der Fehler auf eine nicht erkannte Abhängigkeit zurückzuführen ist: Fügen Sie eine neue Aufgabe hinzu, blockieren Sie die aktuelle Aufgabe und ordnen Sie den Plan neu.
- Wenn der Fehler auf eine Änderung der Anforderungen zurückzuführen ist: Kehren Sie zu Phase 1 zurück (PRD erneut lesen und extrahieren) und durchlaufen Sie den Prozess erneut.
Aktualisieren Sie das Plan-Dokument: Aktualisieren Sie die plan.md, um die Änderungen widerzuspiegeln, und melden Sie dem Benutzer.

Parallelisierungs-Taxonomie

Jede Aufgabe muss eine Parallelisierungsklassifikation haben, die angibt, ob sie parallel zu anderen Aufgaben ausgeführt werden kann.

Klassifikation	Bedeutung	Beispiel
Parallel	Kann gleichzeitig mit anderen parallelen Aufgaben gestartet werden	Unabhängige UI-Komponenten
Blockiert	Wartet darauf, dass eine oder mehrere andere Aufgaben abgeschlossen sind	Frontend-Aufgabe, die auf Backend-API-Endpunkt wartet
Blockierend	Andere Aufgaben warten darauf, dass diese abgeschlossen ist	Datenbankschema-Erstellung
Serialisiert	Muss in einer bestimmten Reihenfolge mit anderen Aufgaben ausgeführt werden, aber nicht unbedingt blockiert (Pipeline)	Datenmigrationen

Weisen Sie jeder Aufgabe während Phase 4 oder 5 eine Klassifikation zu. Dokumentieren Sie sie im Aufgabenkopf.

Aufgabenlisten-Ziel

Standardmäßig schreibt get-tasks in tasks/<name>/. Dies ist das Standardziel für dateibasierte Aufgabenverfolgung.

Wenn der Benutzer einen externen Tracker bevorzugt (GitHub Issues, Jira, Linear usw.), geben Sie an, dass diese Integration außerhalb des Rahmens dieses Skills liegt, und schlagen Sie stattdessen eine manuelle Synchronisierung vor.

Bekannte Einschränkungen

Keine automatische Abhängigkeitsanalyse – der Graph wird manuell aus dem PRD erstellt. Für große Monolithen mit vielen impliziten Abhängigkeiten kann es schwierig sein, alle Kanten zu identifizieren.
Keine automatische Dimensionierung – die Schätzung der Aufgabengröße basiert auf dem Kontext des Agenten und der PRD-Klarheit. Ungenaue Schätzungen sind möglich.
Keine Integration mit externen Trackern – die Ausgabe sind reine Dateien; externe Tracker müssen manuell aktualisiert werden.
Erfordert ein genehmigtes PRD – dieser Skill erstellt keine Anforderungen; er setzt sie voraus.

rizqinrr/get-tasks

Was ist get-tasks?

In Ihrer bevorzugten KI fragen

Dokumentation