---
description: Grobplanung eines Projekts oder Problems – analysiert Anforderungen, klärt Unklarheiten, identifiziert Technologiebedarf und zerlegt das Projekt in thematisch abgegrenzte, einzeln testbare Blocks. Erstellt [T]-Tickets für Tech Decisions und [P]-Tickets für jeden Block. Wird vom nextstep-Router für [B]-Tickets aufgerufen.
agent: agent
model: Claude Opus 4.6 (copilot)
tools: [read, edit, search, execute, agent, web, todo, browser, vscode]
---

# Workflow: Grobplanung [B]

Dieser Workflow wird aufgerufen, wenn der nextstep-Router ein `[B]`-Ticket identifiziert hat.
Die Eingabe enthält: **Issue-Nummer**, **Titel** und **Issue-Body**.

**Ziel:** Ein grob beschriebenes Projekt oder Problem in thematisch abgegrenzte, unabhängig testbare Blocks zerlegen. Für jeden Block entsteht ein `[P]`-Ticket. Tech Decisions werden als `[T]`-Tickets vorangestellt.

---

## Aufgabenplanung

Erstelle zu Beginn eine TODO-Liste (`manage_todo_list`):

1. Issue lesen & Projekttyp bestimmen
2. Anforderungen/System analysieren
3. Unklarheiten klären (User-Interaktion)
4. Technologiebedarf identifizieren
5. Blocks & Abhängigkeitsgraph definieren
6. Tickets erstellen ([T] zuerst, dann [P])
7. [B]-Issue schließen

---

## Phase 1 – Issue lesen & Projekttyp bestimmen

1. Lies den vollständigen **Issue-Body** des [B]-Tickets.
2. Bestimme den **Projekttyp**:

   | Typ | Kennzeichen |
   |---|---|
   | **Neuentwicklung** | Neues System von Grund auf |
   | **Feature-Erweiterung** | Bestehendes System um größeren Bereich erweitern |
   | **Architektur-Refactoring** | Größere Strukturumbauten am bestehenden System |

3. Notiere: Zielplattform, grober Scope, vorhandener Code.

---

## Phase 2 – Anforderungen/System analysieren

1. Lies relevante **Architekturdokumente** (falls vorhanden).
2. Analysiere den Ist-Zustand (vorhandener Code, Schnittstellen, Datenmodelle).
3. Identifiziere Abhängigkeiten zu bestehenden Modulen.

Erstelle intern eine **Subsystem-Liste** mit:
- Name und Kurzbeschreibung
- Geschätzte Komplexität: S / M / L / XL
- Externe Abhängigkeiten / unbekannte Technologien
- Abhängigkeiten zu anderen Subsystemen

---

## Phase 3 – Unklarheiten klären

Prüfe für jede Kategorie, ob Klarheit besteht:

1. **Scope-Abgrenzung:** Was ist enthalten / nicht enthalten?
2. **Zielplattform und -Technologie:** Vollständig definiert?
3. **Externe Systeme:** APIs, Server, Datenbanken?
4. **Datenmodell:** Kern-Entitäten und Beziehungen klar?
5. **Offline-Verhalten:** Muss das System offline funktionieren?
6. **Testing-Anforderungen:** Welcher Testgrad?
7. **Prioritäten:** Was ist MVP?

**Falls Unklarheiten:** Nummerierte Rückfragen mit Optionen → **auf Antwort warten**.

---

## Phase 4 – Technologiebedarf identifizieren

Identifiziere alle offenen **Technologieentscheidungen**:

- Persistenzlösungen
- Externe Server oder Backend-Systeme
- Neue Frameworks oder SDKs
- Sync-/Auth-Protokolle

Für jede offene Entscheidung notiere: Was, Warum, welche Blocks davon abhängen.

---

## Phase 5 – Blocks & Abhängigkeitsgraph definieren

### Was ist ein Block?

Ein **Block** ist eine thematisch abgegrenzte Implementierungseinheit:
- Eigenständig testbar
- Klare fachliche Grenze
- Größenordnung: 1–4 Wochen

### Pflicht-Blöcke bei Neuentwicklungen

1. **Projektgerüst & Basisinfrastruktur** – lauffähiges Skeleton (App-Struktur, Navigation, DI, Logging)
2. **Querschnittsfunktionen** – Persistenz, Datenmodell, ggf. Auth, Netzwerkschicht

### Block-Tabelle

| Nr | Block-Name | Kurzbeschreibung | Abhängig von | Kompl. | Testbarkeit |
|---|---|---|---|---|---|
| B1 | Projektgerüst | App-Skeleton, Navigation, CI | – | M | Build + Smoke |
| B2 | Datenschicht | Room DB, Repository, Export/Import | B1 | M | Unit |
| … | … | … | … | … | … |

**Präsentiere die Block-Tabelle und warte auf Bestätigung** des Users.

---

## Phase 6 – Tickets erstellen

### [T]-Tickets für Tech Decisions (höchste Priorität)

Pro offene Tech Decision ein Ticket. Label: `tech-decision`.

### [P]-Tickets für jeden Block

Pro Block ein Ticket mit:
- Ziel (ein Satz)
- Scope (enthalten / ausgeschlossen)
- Abhängigkeiten (`Depends on: #N`)
- Akzeptanzkriterien
- Testing-Strategie

Label: `planning`

---

## Phase 7 – [B]-Issue schließen

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