bollwerk/.github/prompts/workflow-planning.prompt.md

description	agent	model	tools
Zerlegt eine grob definierte Aufgabe (Planungsticket [P]) in präzise, umsetzbare Arbeitspakete. Wird vom nextstep-Router für [P]-Tickets aufgerufen.	agent	Claude Opus 4.6 (copilot)	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

## 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

Phase 5 – P-Ticket schließen

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