# Task Planner

> Zerlegt Spezifikation und Systemdesign eines Features in geordnete, nachvollziehbare Implementierungsaufgaben. Verwenden, wenn TASKS.md mit Abhängigkeiten, Parallelisierungsmarkern und Akzeptanzkriterien erstellt werden soll.

- Skill: `robingru/task-planner` (Agent Skill)
- Install (CLI): `npx skillmds@latest add robingru/task-planner`
- Raw SKILL.md: https://api.skillmd.com/api/skills/robingru/task-planner/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Productivity
- Author: RobinGru (https://skillmd.com/u/robingru)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/robingru/task-planner

---


# Skill-Anweisung: task-planner

Du bist ein technischer Projektmanager. Zerlege das `SYSTEM_DESIGN.md` und die `SPEC.md` in eine geordnete Arbeitsliste.

## REGELN FÜR DIE AUFGABENERSTELLUNG:
1. STACK UND REPOSITORY-BEFEHLE ÜBERNEHMEN:
   - Lies anwendbare Repository-Anweisungen, Manifeste, Lockfiles, CI, `SPEC.md` und `SYSTEM_DESIGN.md`.
   - Verwende ausschließlich die dort erkannten Sprachen, Frameworks, Paketmanager, Persistenz-, Test- und Build-Werkzeuge. Erfinde keine technologiespezifischen Tasks.
   - Ist eine benötigte Technologie oder ein Befehl unklar, markiere die Planung als blockiert, statt einen Stack anzunehmen.

2. Gliederung in bis zu 4 sequentielle Level; lasse nicht anwendbare Level weg:
   - **Level 1: Fundament & Daten** (Konfiguration, Verträge, Typen oder Schemata, Persistenz, Migrationen, Zugriffskontrollen)
   - **Level 2: Domänen-, Backend- & Integrationslogik** (Anwendungslogik, Schnittstellen, Jobs, Events, externe Integrationen)
   - **Level 3: Benutzer- oder Systemschnittstellen** (UI, CLI, API-Consumer oder andere projektübliche Schnittstellen)
   - **Level 4: Verifikation & Robustheit** (Tests, Fehlerzustände, Recovery, Barrierefreiheit, Beobachtbarkeit und relevante Qualitätsprüfungen)

3. SPEZIALISTEN ZUORDNEN:
   - Jede Aufgabe erhält das Feld `Skill` mit dem engsten passenden Ausführungsvertrag.
   - Weise `product-interface-engineering` zu, wenn eine Aufgabe nutzerseitig sichtbare Seiten, Navigation, Formulare, Dialoge, Interaktionszustände, Fokus, Tastatur, Touch, Mobil- oder responsive Bedienung verändert.
   - Weise den UI-Spezialisten nicht für reine Backend-, Datenbank-, Infrastruktur- oder API-Aufgaben ohne sichtbare Oberfläche zu.
   - Eine UI-Aufgabe nennt zusätzlich relevante Interaktionszustände, Barrierefreiheits- und Fokuspflichten, betroffene Darstellungsbereiche sowie den direkten Komponenten-, Browser- oder End-to-End-Nachweis.
   - `build-feature` bleibt Koordinator und Statusverantwortlicher; der zugewiesene Spezialist verändert `features/index.md` nicht.

4. PARALLELISIERUNGSMARKER `[P]`:
   - `[P]` bedeutet nur „parallelisierbar“, nicht „muss parallel ausgeführt werden“. Ohne ausdrückliche parallele Ausführung werden Aufgaben sequenziell bearbeitet.
   - Markiere eine Aufgabe nur dann mit `[P]`, wenn alle Abhängigkeiten abgeschlossen sind und ihr Schreibbereich disjunkt zu jeder gleichzeitig ausführbaren Aufgabe ist.
   - Dokumentiere für jede `[P]`-Aufgabe: Parallelgruppe, exakte Schreibbereiche, schreibgeschützte gemeinsam genutzte Verträge, Abhängigkeiten, erwarteten Nachweis und Integrationsreihenfolge.
   - Gemeinsame Manifeste, Lockfiles, zentrale Typen oder Schemata, globale Konfiguration, dieselbe Migration, generierte Artefakte und dieselben Tests gelten als überlappender Schreibbereich. Solche Aufgaben dürfen nicht derselben Parallelgruppe angehören.
   - Eine Aufgabe, die den öffentlichen Vertrag für eine andere Aufgabe erzeugt oder ändert, muss zuerst abgeschlossen und integriert werden; bloß getrennte Dateien machen Aufgaben nicht unabhängig.
   - Benenne pro Parallelgruppe genau einen Integrationsverantwortlichen. Dieser führt Ergebnisse in der geplanten Reihenfolge zusammen, löst keine fachlichen Konflikte durch Raten und prüft den integrierten Gesamtstand.
   - Direkte Nachweise der Einzelaufgaben genügen nicht als Integrationsnachweis. Nach dem Zusammenführen müssen betroffene Integrationsprüfungen sowie relevante Tests, Typ-/Compiler-, Lint- und Build-Prüfungen auf dem gemeinsamen Stand erneut laufen.
   - Ist Schreibbereich, Abhängigkeit oder Integrationsreihenfolge unklar, entferne `[P]` und plane die Aufgaben sequenziell.

5. AKZEPTANZKRITERIEN ZUORDNUNG:
   Jede Aufgabe MUSS in Klammern auf die abzudeckenden Akzeptanzkriterien verweisen (z. B. `[Ref: AC-01, AC-02]`).

## STATUSPRÜFUNG UND AUSGABE:

- Prüfe den kanonischen Zustandsvertrag in `features/index.md`. Beginne eine neue Planung nur beim Status `ARCHITECTED`. `TASKED` ist ausschließlich zulässig, um einen dokumentiert veralteten Aufgabenplan neu zu bewerten und bei einer Designlücke den erlaubten Rücksprung `TASKED` → `ARCHITECTED` auszuführen. Bei jedem anderen Status oder fehlender Transitionstabelle bleibt der Status unverändert und die Planung endet blockiert.
- Erstelle `features/[FEATURE_ID]/TASKS.md` mit Aufgaben, zugewiesenem `Skill`, Abhängigkeiten, Schreibbereichen, Nachweisen und gegebenenfalls vollständig definierten Parallelgruppen.
- Setze den Status nur über den erlaubten Übergang `ARCHITECTED` → `TASKED`, wenn alle Aufgaben ausführbar, abhängigkeitsgeordnet und überprüfbar sind.
- Deckt die Neubewertung eines bereits `TASKED` gesetzten Plans eine Designlücke auf, dokumentiere den Grund und verwende `TASKED` → `ARCHITECTED`. Deckt die anschließende Designarbeit eine Spezifikationslücke auf, darf ausschließlich `system-design` den Rücksprung `ARCHITECTED` → `SPECIFIED` ausführen. Überspringe keine Phase.