bollwerkadmin/bollwerk
1
0
Fork 0
Code Issues 9 Pull requests Projects Releases Packages Wiki Activity Actions
bollwerk/.github/prompts/nextstep-block-planning.prompt.md
Jens Reinemann 5a26d6a85e refactor: rename workflow-*.prompt.md → nextstep-*.prompt.md 
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.
2026-05-18 09:26:36 +02:00

5.7 KiB
Raw Permalink Blame History

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)
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:

# 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: 
    & ".github/skills/gh-tickets/set-board-status.ps1" -IssueNumber <N> -Status Done