diff --git a/.github/prompts/workflow-block-planning.prompt.md b/.github/prompts/workflow-block-planning.prompt.md index 2f57f1d..4398092 100644 --- a/.github/prompts/workflow-block-planning.prompt.md +++ b/.github/prompts/workflow-block-planning.prompt.md @@ -33,11 +33,11 @@ Erstelle zu Beginn eine TODO-Liste (`manage_todo_list`): 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 | + | 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. @@ -50,6 +50,7 @@ Erstelle zu Beginn eine TODO-Liste (`manage_todo_list`): 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 @@ -91,6 +92,7 @@ Für jede offene Entscheidung notiere: Was, Warum, welche Blocks davon abhängen ### Was ist ein Block? Ein **Block** ist eine thematisch abgegrenzte Implementierungseinheit: + - Eigenständig testbar - Klare fachliche Grenze - Größenordnung: 1–4 Wochen @@ -102,11 +104,11 @@ Ein **Block** ist eine thematisch abgegrenzte Implementierungseinheit: ### 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 | -| … | … | … | … | … | … | +| 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. @@ -121,6 +123,7 @@ 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`) @@ -129,9 +132,31 @@ Pro Block ein Ticket mit: 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/krisenvorrat/issues/" + +# 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 --field-id --project-id --number +``` + +> 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 -Status Done + ``` diff --git a/.github/prompts/workflow-planning.prompt.md b/.github/prompts/workflow-planning.prompt.md index e6f0823..a798b06 100644 --- a/.github/prompts/workflow-planning.prompt.md +++ b/.github/prompts/workflow-planning.prompt.md @@ -29,6 +29,7 @@ Dieser Workflow wird aufgerufen, wenn der nextstep-Router ein `[P]`-Ticket ident ### 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? @@ -36,6 +37,7 @@ Aus dem groben Scope des P-Tickets eine **detaillierte Aufgabenliste** ableiten: ## Phase 3 – Rückfragen Falls Unklarheiten bestehen: + - Nummerierte Rückfragen mit Optionen - **Auf Antwort warten** @@ -61,17 +63,21 @@ Part of: # Depends on: # (falls zutreffend) ### Ziel + ### Scope + - - ### Technische Hinweise + - - ### Akzeptanzkriterien + - [ ] - [ ] - [ ] Tests: @@ -79,6 +85,24 @@ Depends on: # (falls zutreffend) Label: `feature` +### Board & Order (Pflicht für jedes neue Ticket) + +Nach dem Anlegen jedes [F]-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/krisenvorrat/issues/" + +# 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 --field-id --project-id --number +``` + +> 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 5 – P-Ticket schließen 1. Kommentar mit Übersicht aller erstellten Sub-Tickets.