5a26d6a85e
Namenskonvention für Genome Engine Verbund-Erkennung: Router <name>.prompt.md + Sub-Prompts <name>-*.prompt.md ermöglicht rein pfadbasierte Trait-Zuordnung ohne Content-Parsing.
162 lines
5.7 KiB
Markdown
162 lines
5.7 KiB
Markdown
---
|
||
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
|
||
```
|