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

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

Nach dem Anlegen **jedes** [T]- und [P]-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/bollwerk/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 7 – [B]-Issue schließen

1. Kommentar mit Übersicht aller erstellten Tickets.
2. Issue schließen.
3. Board-Status auf "Done" setzen:
   ```powershell
   & ".github/skills/gh-tickets/set-board-status.ps1" -IssueNumber <N> -Status Done
   ```