4.3 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
Phase 7 – [B]-Issue schließen
- Kommentar mit Übersicht aller erstellten Tickets.
- Issue schließen.