Menu
Aktuellen Fortschritt ermitteln und den nächsten Implementierungsschritt durchführen. Erstellt Feature-Branch, implementiert, testet und erstellt PR.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Neue Spezifikation analysieren, in Phasen aufteilen und in den Master-Implementierungsplan aufnehmen. Erkennt automatisch neue Spec-Dateien.
Nächste nicht-ausgearbeitete Phase finden und detailliert ausarbeiten. Erstellt Phase-Ordner mit README und Schritt-Dateien.
Zeigt den aktuellen Fortschritt und welcher Schritt als nächstes zur Implementierung ansteht. Keine Implementierung, nur Übersicht.
Alle aktiven Phasen (Integration-Branches) anzeigen und zu einer anderen Phase wechseln. Behandelt uncommitted Changes sicher.
| name | impl-next |
| description | Aktuellen Fortschritt ermitteln und den nächsten Implementierungsschritt durchführen. Erstellt Feature-Branch, implementiert, testet und erstellt PR. |
| disable-model-invocation | true |
Dieser Befehl ermittelt den aktuellen Fortschritt und implementiert den nächsten Schritt.
Lies docs/implementation/README.md und erstelle eine Übersicht:
- [x]) vs. offen (- [ ])?Prüfe zusätzlich den aktuellen Git-Branch:
git branch --show-current
Fall A: Auf einem Feature-Branch (z.B. feat/cc-appearance-model)
Fall B: Auf einem Integration-Branch (z.B. integration/phase-10-cc-data-model)
Fall C: Auf main, keine Phase in Arbeit
Fall D: Auf main, aber Integration-Branch(es) existieren
git branch -r --list "origin/integration/*"
Prüfe ob die aktuelle Phase vollständig ausgearbeitet ist:
docs/implementation/phase-X-*/
├── README.md
├── X.1-...md
├── X.2-...md
└── ...
STOPP falls Phase nicht ausgearbeitet ist:
/plan-phase auszuführenLies ZUERST die verlinkten Spezifikationen:
WICHTIG: Die Spezifikationen sind bindend. Implementierungen müssen den Spezifikationen entsprechen.
Lies die Dokumentation für den nächsten offenen Schritt:
docs/implementation/phase-X-*/X.Y-step-name.mdPrüfe ob die Schritt-Dokumentation einen ## Relevante Spezifikationen Abschnitt enthält.
Falls vorhanden:
Warum dieser Schritt existiert: Manche Phasen (z.B. Netzwerk, Character Platform) haben umfangreiche Spezifikations-Dokumente die kritisches Detailwissen enthalten. Die Schritt-Dokumentation allein reicht nicht — die Specs liefern den Kontext für warum etwas so gebaut wird und welche Fallstricke zu vermeiden sind.
Falls kein ## Relevante Spezifikationen Abschnitt vorhanden: Weiter mit Schritt 5b.
Prüfe ob die Phase-README einen ## Impact Notes Abschnitt enthält.
Falls Impact Notes vorhanden:
⚠ Impact Note gefunden:
Phase Y (Name) benötigt Änderungen an [Datei/Interface].
Wird in Phase Y, Schritt Y.Z adressiert.
Optionen:
→ Schritt normal implementieren (Änderung kommt in Phase Y)
→ Änderung jetzt vorziehen (Interface schon jetzt erweitern)
→ Schritt überspringen und erst Impact klären
Falls keine Impact Notes oder Schritt nicht betroffen: Weiter mit Schritt 6.
Bevor implementiert wird:
Neuen Feature-Branch vom Integration-Branch erstellen:
git checkout integration/phase-X-beschreibung
git pull origin integration/phase-X-beschreibung
git checkout -b <type>/fachliche-beschreibung
Branch-Typ passend zum Inhalt wählen:
feat/ — Neue Funktionalitätfix/ — Bugfixrefactor/ — Code-Umbautest/ — Testsdocs/ — Dokumentationchore/ — Setup, ConfigFalls bereits auf richtigem Feature-Branch:
Führe die Schritte aus der Dokumentation durch:
Für jede neue Klasse/Modul:
Packages/.../Tests/Runtime/ oder Tests/Editor/[TestFixture] Attributpowershell -Command "Get-Content 'C:\Users\marcu\AppData\Local\Unity\Editor\Editor.log' -Tail 100 | Select-String -Pattern 'error|CS\d{4}'"
Bei Fehlern: Beheben bevor Commit erstellt wird.
git add <geänderte-dateien>
git commit -m "feat(phase-X): X.Y Beschreibung"
WICHTIG:
Feature-Branches werden direkt in den Integration-Branch gemerged (kein PR nötig):
git checkout integration/phase-X-beschreibung
git merge <type>/fachliche-beschreibung
git push origin integration/phase-X-beschreibung
Danach Feature-Branch aufräumen:
git branch -d <type>/fachliche-beschreibung
Hinweis: PRs werden nur für Integration → main erstellt, nicht für Feature → Integration.
In docs/implementation/README.md:
- [ ] → - [x]In docs/implementation/phase-X-*/README.md:
git add docs/implementation/
git commit -m "docs: Markiere Schritt X.Y als abgeschlossen"
Informiere den User:
Aktueller Fortschritt:
Epic "Lebendige Charaktere — Animation Pipeline":
Phase 1: 4/4 ✅ | Phase 2: 0/5 | Phase 3: nicht ausgearbeitet
Epic "Character Creator & Ausrüstung":
Phase 10: 2/6 (in Arbeit) | Phase 11–16: nicht ausgearbeitet
Aktueller Branch: integration/phase-10-cc-data-model
Nächster Schritt: 10.3 EquipmentSlot Enum und Grundtypen
Erstelle Feature-Branch: feat/cc-equipment-types
Basis: integration/phase-10-cc-data-model
Implementiere Schritt 10.3...
[Implementierung]
Commit: feat(phase-10): 10.3 EquipmentSlot Enum und Grundtypen
Merge: feat/cc-equipment-types → integration/phase-10-cc-data-model (direkt)
Fortschritt Phase 10: 3/6 Schritte abgeschlossen
Nächster Schritt: 10.4 ScriptableObject-Kataloge
Wenn der letzte Schritt einer Phase abgeschlossen wurde:
gh pr create --base main --title "feat: Phase X - Beschreibung" --body "..."
PR-Body Format:
## Summary
**Epic:** [Epic-Name]
- Schritt X.1: ...
- Schritt X.2: ...
- ...
## Test plan
- [ ] Test 1
- [ ] Test 2
git checkout main && git pull origin main
git branch -d integration/phase-X-beschreibung
git push origin --delete integration/phase-X-beschreibung
AbgeschlossenWICHTIG: Keine Claude-Attribution in PRs!