f52724ce0c
Beide Workflow-Prompts erstellten Sub-Tickets per gh issue create, setzten aber weder Board-Zugehörigkeit (gh project item-add) noch Order-Wert (gh project item-edit). Das führte dazu, dass neue Tickets auf dem Board ohne Order-Wert blieben und von next-ticket.ps1 nicht gefunden wurden. Lösung: In workflow-planning.prompt.md (Phase 4) und workflow-block-planning.prompt.md (Phase 6) einen neuen Pflichtabschnitt 'Board & Order' ergänzt mit den konkreten gh-Befehlen und Verweis auf SKILL.md.
5.7 KiB
| description | agent | model | tools | |||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 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 | Claude Opus 4.6 (copilot) |
|
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):
- Issue lesen & Projekttyp bestimmen
- Anforderungen/System analysieren
- Unklarheiten klären (User-Interaktion)
- Technologiebedarf identifizieren
- Blocks & Abhängigkeitsgraph definieren
- Tickets erstellen ([T] zuerst, dann [P])
- [B]-Issue schließen
Phase 1 – Issue lesen & Projekttyp bestimmen
-
Lies den vollständigen Issue-Body des [B]-Tickets.
-
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 -
Notiere: Zielplattform, grober Scope, vorhandener Code.
Phase 2 – Anforderungen/System analysieren
- Lies relevante Architekturdokumente (falls vorhanden).
- Analysiere den Ist-Zustand (vorhandener Code, Schnittstellen, Datenmodelle).
- 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:
- Scope-Abgrenzung: Was ist enthalten / nicht enthalten?
- Zielplattform und -Technologie: Vollständig definiert?
- Externe Systeme: APIs, Server, Datenbanken?
- Datenmodell: Kern-Entitäten und Beziehungen klar?
- Offline-Verhalten: Muss das System offline funktionieren?
- Testing-Anforderungen: Welcher Testgrad?
- 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
- Projektgerüst & Basisinfrastruktur – lauffähiges Skeleton (App-Struktur, Navigation, DI, Logging)
- 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:
# 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 7 – [B]-Issue schließen
- Kommentar mit Übersicht aller erstellten Tickets.
- Issue schließen.
- Board-Status auf "Done" setzen:
& ".github/skills/gh-tickets/set-board-status.ps1" -IssueNumber <N> -Status Done