---
description: Zerlegt eine grob definierte Aufgabe (Planungsticket [P]) in präzise, umsetzbare Arbeitspakete. Wird vom nextstep-Router für [P]-Tickets aufgerufen.
agent: agent
model: Claude Opus 4.6 (copilot)
tools: [read, edit, search, execute, agent, web, todo, browser, vscode]
---

# Workflow: Planung

Dieser Workflow wird aufgerufen, wenn der nextstep-Router ein `[P]`-Ticket identifiziert hat.

---

## Phase 1 – Kontext laden

1. Lies den vollständigen **Issue-Body** (Ziel, Scope, Akzeptanzkriterien).
2. Lies relevante Architekturdokumentation (falls vorhanden).
3. Identifiziere den **Aufgabentyp**: Neues Feature, Integration, Refactoring, oder anderes?
4. Prüfe `Depends on`-Tickets: Welche Vorarbeiten sind erledigt, welche noch offen?

## Phase 2 – Analyse

### Bestehenden Code verstehen

1. Durchsuche das Projekt nach bereits vorhandenen Klassen, Interfaces und Modulen die relevant sind.
2. Identifiziere Erweiterungspunkte und mögliche Konflikte.
3. Notiere bestehende Tests die angepasst werden müssen.

### Scope verfeinern

Aus dem groben Scope des P-Tickets eine **detaillierte Aufgabenliste** ableiten:

- Welche Dateien müssen neu erstellt werden?
- Welche bestehenden Dateien müssen geändert werden?
- Welche Tests müssen geschrieben werden?

## Phase 3 – Rückfragen

Falls Unklarheiten bestehen:

- Nummerierte Rückfragen mit Optionen
- **Auf Antwort warten**

## Phase 4 – Sub-Tickets erstellen

### Ticket-Reihenfolge

Erstelle [F]-Tickets in logischer Implementierungsreihenfolge:

1. **Datenmodell / Entities** zuerst (andere bauen darauf auf)
2. **Repository / Data Layer** (Zugriff auf Daten)
3. **Business Logic / Use Cases** (Verarbeitung)
4. **ViewModel** (State Management)
5. **UI / Composables** (Darstellung)
6. **Integration / Zusammenspiel** (alles zusammen)

### Ticket-Body-Template

```markdown
## Feature: <Beschreibung>

Part of: #<P-Nummer>
Depends on: #<vorheriges-Ticket> (falls zutreffend)

### Ziel

<Ein Satz: Was wird nach Abschluss funktionieren?>

### Scope

- <Aufgabe 1>
- <Aufgabe 2>

### Technische Hinweise

- <Relevante bestehende Klassen/Interfaces>
- <Architekturentscheidungen>

### Akzeptanzkriterien

- [ ] <Messbares Kriterium 1>
- [ ] <Messbares Kriterium 2>
- [ ] Tests: <was getestet wird>
```

Label: `feature`

### Board & Order (Pflicht für jedes neue Ticket)

Nach dem Anlegen jedes [F]-Tickets **sofort** ausführen:

```powershell
# 1. Ticket zum Board hinzufügen
gh project item-add 2 --owner jreinemann-euris --url "https://github.com/jreinemann-euris/krisenvorrat/issues/<N>"

# 2. Bestehende Order-Werte abfragen (höchsten Wert ermitteln)
& ".github/skills/gh-tickets/next-ticket.ps1" | Out-Null  # zeigt alle offenen Tickets mit Order

# 3. Order-Wert setzen: höchster_bestehender_Wert + 10
gh project item-edit --id <ITEM_ID> --field-id <ORDER_FIELD_ID> --project-id <PROJECT_ID> --number <ORDER_VALUE>
```

> Order-Konvention: 10er-Schritte (10, 20, 30 …). Jedes Ticket bekommt den höchsten bisher vergebenen Wert + 10.
> Skript-IDs und Field-IDs: siehe `.github/skills/gh-tickets/SKILL.md` → Abschnitt "Issue zum Board hinzufügen".

## Phase 5 – P-Ticket schließen

1. Kommentar mit Übersicht aller erstellten Sub-Tickets.
2. Issue schließen.