| name | plan-phase |
| description | Nächste nicht-ausgearbeitete Phase finden und detailliert ausarbeiten. Erstellt Phase-Ordner mit README und Schritt-Dateien. |
| disable-model-invocation | true |
Nächste Phase ausarbeiten
Dieser Befehl findet die nächste Phase, die noch nicht detailliert ausgearbeitet ist, und erstellt die vollständige Dokumentation dafür.
Anweisungen
1. Master-Plan lesen
Lies die Datei docs/implementation/README.md und identifiziere:
- Alle Epics und ihre Phasen
- Welche Phasen als
✅ (ausgearbeitet) und welche als ❌ (nicht ausgearbeitet) markiert sind
- Welche Phasen als
Offen, In Arbeit oder Abgeschlossen markiert sind
- Abhängigkeiten zwischen Phasen (siehe Abhängigkeiten-Diagramm)
2. Kandidaten ermitteln
Eine Phase kommt als nächste in Frage wenn:
- Sie als
❌ (nicht ausgearbeitet) markiert ist
- Alle ihre Abhängigkeiten (vorherige Phasen) bereits ausgearbeitet ODER abgeschlossen sind
- Sie nicht bereits in Arbeit ist
WICHTIG: Die Epics haben keine feste Reihenfolge. Es können Phasen aus verschiedenen Epics gleichzeitig als Kandidat in Frage kommen.
3. User wählen lassen
Falls mehrere Phasen als Kandidat in Frage kommen:
- Zeige dem User die Kandidaten gruppiert nach Epic
- Für jeden Kandidaten: Phase-Nummer, Name, Epic-Zugehörigkeit
- Frage den User welche Phase ausgearbeitet werden soll
- Empfehle eine Phase basierend auf Abhängigkeiten und Vollständigkeit des Epics
Falls nur eine Phase in Frage kommt:
- Informiere den User und fahre direkt fort
4. Phase-Ordner prüfen
Für die gewählte Phase prüfen ob bereits Dateien existieren:
docs/implementation/phase-X-*/
├── README.md # Phase-Übersicht
├── X.1-step-name.md # Schritt 1
├── X.2-step-name.md # Schritt 2
└── ...
Eine Phase gilt als nicht ausgearbeitet wenn:
- Der Ordner nicht existiert
- Der Ordner leer ist
- README.md fehlt
- Schritt-Dateien fehlen
5. Bestehende Spezifikationen lesen (PFLICHT)
Bevor die Phase ausgearbeitet wird:
- Lies die im Master-Plan verlinkten Spezifikationen für diese Phase und das zugehörige Epic
- Lies die Haupt-Spezifikation des Epics (falls vorhanden)
- Lies weitere relevante Spezifikationen in
docs/specs/
- Verstehe die Architektur und bestehenden Code
- Prüfe Abhängigkeiten zu vorherigen Phasen
WICHTIG: Die Spezifikationen sind bindend. Die Phase-Dokumentation muss den Spezifikationen entsprechen.
5b. Impact-Analyse auf aktive Phasen
Prüfe ob die neue Phase Auswirkungen auf bereits ausgearbeitete oder in Arbeit befindliche Phasen hat.
Prüfschritte:
- Identifiziere alle Phasen mit Status
In Arbeit oder Offen + ✅ Ausgearbeitet
- Lies deren Detail-Dokumentation (README.md + Schritt-Dateien)
- Prüfe ob die neue Phase:
- Interfaces/Klassen erweitert, die in einer aktiven Phase definiert werden
- Neue Anforderungen an bestehende Komponenten stellt
- Architektur-Entscheidungen beeinflusst, die in einer aktiven Phase getroffen wurden
Falls Auswirkungen gefunden werden:
-
Impact Note in der aktiven Phase hinterlegen
-
Adaptierungsschritt in der neuen Phase einplanen
- Falls die neue Phase Änderungen an bestehenden Interfaces/Klassen braucht, einen expliziten Schritt am Anfang der Phase einplanen (z.B. "X.1 Interface-Erweiterung aus Phase Z")
- Dieser Schritt dokumentiert exakt welche Anpassungen nötig sind
-
User warnen bei kritischen Auswirkungen
- Falls eine Auswirkung bereits implementierte Schritte brechen könnte → User explizit warnen
- Empfehlung geben: Erst aktive Phase abschließen, oder Anpassung jetzt einbauen
Falls keine Auswirkungen: Weiter mit Schritt 5c.
5c. Editor-UI-Analyse (PFLICHT)
Prüfe ob die neue Phase Auswirkungen auf bestehende Editor-Tools und Wizards hat.
Relevante Editor-Tools im Projekt:
AnimationWizard — FBX-Slot-Liste, Auto-Erkennung, Animator-Controller-ZuweisungCharacterControllerSetupWizard — Character Model Setup, Prefab-ErstellungAnimatorControllerCreator — Programmatische Animator-State-ErstellungPlaygroundSceneCreator — Test-Szene mit UmgebungTestSceneCreator — Player in aktuelle Szene platzierenIKSetupWizard — IK-Komponenten auf Player PrefabCameraSetupEditor — Third-Person Camera Setup
Prüfschritte:
- Erweitert die Phase ein Enum (z.B.
CharacterAnimationState)? → AnimationWizard, AnimatorControllerCreator betroffen
- Fügt die Phase neue Animationen hinzu? → AnimationWizard braucht neue FBX-Slots, Auto-Erkennung, Clip-Zuweisung
- Fügt die Phase neue Components hinzu? → Setup-Wizards ggf. erweitern
- Ändert die Phase Config-Parameter? → Inspector-Darstellung prüfen
- Braucht die Phase ein eigenes Editor-Tool (neuer Wizard/Inspector)?
Falls Editor-UI betroffen:
- Einen expliziten Schritt in der Phase einplanen für Editor-UI-Anpassungen
- Im Schritt dokumentieren: Welche Dateien, welche Änderungen (neue Slots, neue States, neue Menüpunkte)
- Bei AnimationWizard: Slot-Feld, Auto-Detect, ConfigureAnim-Aufruf, AssignClipsToController, CountAnimSlots/HasAnyAnimation aktualisieren
- Bei AnimatorControllerCreator: Neuen State + Transitions programmatisch anlegen
Falls keine Editor-UI betroffen: Weiter mit Schritt 6.
5d. Spec-zu-Schritt-Zuordnung erstellen (PFLICHT wenn Specs vorhanden)
Bevor die Schritt-Dateien erstellt werden, eine Zuordnungstabelle erstellen:
Für jeden geplanten Schritt identifizieren:
- Welche Spezifikations-Dokumente sind für diesen Schritt relevant?
- Welche konkreten Sektionen/Kapitel in diesen Docs sind relevant?
- Warum ist dieses Dokument für diesen Schritt wichtig?
Quellen für relevante Specs:
- Haupt-Spezifikation des Epics (im Master-Plan beim Epic verlinkt)
- Phase-spezifische Spezifikationen (in der Phase-README verlinkt)
- Weitere Specs in
docs/specs/ und Unterordnern die thematisch passen
- Übergeordnete Architektur-Docs die Kontext liefern
Regeln für die Zuordnung:
- Jeder Schritt bekommt nur die Specs die für IHN relevant sind (nicht alle Specs der Phase)
- Kritische Schritte (Kern-Architektur, komplexe Integration) bekommen MEHR Referenzen
- Einfache Schritte (Cleanup, Config-Änderung) bekommen WENIGER Referenzen
- Konkrete Sektionsnamen angeben, nicht nur "gesamtes Dokument" (es sei denn wirklich alles relevant ist)
Beispiel-Zuordnung:
Schritt 10.1 (Package-Struktur):
→ Konsolidierte Spec Kap. 4 (Packages) — Package-Schnitt und Abhängigkeiten
→ Master Architecture — Package-Konventionen
Schritt 10.5 (CatalogProvider):
→ Konsolidierte Spec Kap. 6 (Katalog-Runtime) — API-Design, Lazy Loading
→ Konsolidierte Spec Kap. 8 (Addressables) — Async Loading Pattern
6. Phase-Dokumentation erstellen
Erstelle für die Phase:
README.md mit:
- Integration-Branch-Name (Format:
integration/phase-X-beschreibung)
- Epic-Zugehörigkeit
- Abhängigkeiten (welche Phasen müssen vorher abgeschlossen sein)
- Ziel der Phase
- Relevante Spezifikationen (Links zu Haupt-Specs des Epics und der Phase)
- Tabelle aller Schritte mit Commit-Messages und empfohlenem Feature-Branch-Typ
- Voraussetzungen
- Erwartetes Ergebnis
- Link zur nächsten Phase im selben Epic
Für jeden Schritt eine eigene Datei mit:
- Commit-Message
- Empfohlener Branch-Name und -Typ (z.B.
feat/cc-appearance-model)
- Relevante Spezifikationen (aus der Zuordnung in Schritt 5d, als Tabelle mit Dokument, relevante Sektionen, und warum relevant)
- Ziel des Schritts
- Detaillierte Anweisungen
- Code-Beispiele (falls relevant)
- Verifikations-Checkliste
- Erwartete Dateien nach dem Schritt
- Link zum nächsten Schritt
Format für ## Relevante Spezifikationen in Schritt-Dateien:
## Relevante Spezifikationen
Vor der Implementierung **PFLICHT** lesen:
| Dokument | Relevante Sektionen | Warum relevant |
|----------|---------------------|----------------|
| [Spec Name](../../specs/pfad.md) | "Kapitel X", "Abschnitt Y" | Kurze Begründung |
| [Andere Spec](../../specs/pfad.md) | Gesamtes Dokument | Kurze Begründung |
Hinweis zum Branch-Modell:
- Die Phase hat einen langlebigen
integration/-Branch
- Jeder Schritt (oder 2-3 zusammengehörige Schritte) bekommt einen kurzlebigen Feature-Branch
- Feature-Branches gehen per PR in den Integration-Branch
- Am Phase-Ende geht der Integration-Branch per PR in main
7. Offene Fragen klären
Falls Unklarheiten bestehen:
- Liste die offenen Punkte auf
- Frage den User nach Klärung
- Warte auf Antwort bevor die Dokumentation finalisiert wird
8. Ausarbeitungsstatus aktualisieren
In docs/implementation/README.md:
- In der Phasen-Übersicht Tabelle:
❌ → ✅ für "Ausgearbeitet"
- In der Phasen-Übersicht Tabelle:
— → [Features](phase-X-.../README.md) für die Features-Spalte
- Bei der Phase selbst:
**Ausgearbeitet:** ❌ Nein → **Ausgearbeitet:** ✅ Ja — [Detail-Dokument](phase-X-.../README.md)
- Schritte mit Links versehen:
- [ ] X.Y Name → - [ ] [X.Y Name](phase-X-.../X.Y-name.md)
9. Commit erstellen
Nach Erstellung der Dokumentation:
git add docs/implementation/
git commit -m "docs: Arbeite Phase X aus - [Phasen-Name]"
WICHTIG: Kein Claude-Footer in der Commit-Message!
Beispiel-Ausgaben
Beispiel 1: Ohne Auswirkungen
Nicht-ausgearbeitete Phasen mit erfüllten Abhängigkeiten:
Epic "Character Creator & Ausrüstung":
→ Phase 10: CC Core Data Model & Catalogs (keine Abhängigkeiten)
Welche Phase soll ausgearbeitet werden?
→ Phase 10
Impact-Analyse: Keine Auswirkungen auf aktive Phasen.
Erstelle Dokumentation für Phase 10: CC Core Data Model & Catalogs
- docs/implementation/phase-10-cc-data-model/README.md
- docs/implementation/phase-10-cc-data-model/10.1-package-structure.md
- ...
Beispiel 2: Mit Auswirkungen auf aktive Phase
Ausarbeitung: Phase 4 (Ability System)
Impact-Analyse:
⚠ Phase 3 (Animation-Integration, ✅ ausgearbeitet, Status: Offen)
Auswirkung: IAnimationController braucht neue Methode PlayAbilityAnimation(string)
Betrifft: IAnimationController.cs (definiert in Phase 3, Schritt 3.1)
→ Adaptierungsschritt 4.1 eingeplant: "IAnimationController um Ability-Methoden erweitern"
→ Impact Note in Phase 3 README hinterlegt
Keine kritischen Konflikte (Phase 3 noch nicht implementiert).
Erstelle Dokumentation für Phase 4: Ability System
- docs/implementation/phase-4-ability-system/README.md
- docs/implementation/phase-4-ability-system/4.1-animation-interface-extension.md
- docs/implementation/phase-4-ability-system/4.2-iability-interface.md
- ...
