| name | implement-feature |
| description | Implement the next feature from the roadmap or a specific feature by name |
| disable-model-invocation | false |
| argument-hint | [feature-name] |
Feature implementieren
Implementiere ein neues Feature für ReadyStackGo.
Feature: $ARGUMENTS
Phasen- und Branch-Konzept
Jede Roadmap-Version (z.B. v0.18) ist eine Phase mit mehreren Features. Die Branch-Struktur:
main
└── integration/<phase-name> (langlebig, mehrere Tage)
├── feature/<feature-name> (kurzlebig, max 1 Tag)
├── feature/<feature-name> (kurzlebig, max 1 Tag)
└── feature/<feature-name> (kurzlebig, max 1 Tag)
- Integration Branch:
integration/<phase-name> – Sammelbranch für alle Features einer Phase
- Feature Branches:
feature/<name> – Einzelne Features, werden in den Integration Branch gemerged
- Branch-Namen OHNE Versionsnummern (z.B.
integration/init-container-ux, nicht integration/v0.18)
- Feature Branches nutzen das Prefix
feature/ damit der Auto-Labeler sie korrekt als feature labelt
Auto-Labeler Regeln (Release Drafter)
feature/* → Label feature
refactor/* → Label enhancement
fix/*, bugfix/*, hotfix/* → Label bug
chore/* → Label maintenance
Schritt 1: Kontext erfassen
-
GitHub Project Board lesen um das nächste Feature zu identifizieren:
gh project item-list 6 --owner Wiesenwischer --format json --limit 50
- Falls
$ARGUMENTS angegeben wurde, suche dieses spezifische Feature in den Issues.
- Falls
$ARGUMENTS leer ist, nimm das Feature mit der höchsten Priorität (niedrigste Priority-Nummer) im Status "Todo".
- Alternativ:
gh issue list --label epic --state open --json number,title,milestone
-
Lies die Projektrichtlinien (CLAUDE.md) für Branch-Konventionen, Commit-Regeln und Test-Anforderungen.
-
Prüfe ob bereits eine Specification/Plan-Datei existiert in docs/Plans/:
- Das Epic Issue enthält einen Link zur PLAN-Datei (z.B. "See PLAN-xyz.md")
- Falls vorhanden: Lies die Spec VOLLSTÄNDIG – sie enthält Architektur-Entscheidungen, Feature-Aufteilung, betroffene Dateien, Abhängigkeiten und Test-Anforderungen
- Die Spec ist die primäre Quelle für den Implementierungsplan. Erstelle keinen neuen Plan wenn eine Spec existiert – nutze sie als Basis
- Falls keine Spec existiert: Erstelle eine neue Planungsdatei in Schritt 2
-
Lies relevante bestehende Implementierungen um Patterns und Architektur zu verstehen (die Spec referenziert Pattern-Vorbilder mit Dateipfaden).
-
PFLICHT — Board-Status auf "In Progress" setzen (SOFORT, BEVOR irgendetwas anderes passiert):
PROJECT="PVT_kwHOAKdwzc4BR2Bg"
STATUS_FIELD="PVTSSF_lAHOAKdwzc4BR2Bgzg_jRfE"
IN_PROGRESS_ID="9e4cff0c"
ITEM_ID=$(gh project item-list 6 --owner Wiesenwischer --format json --limit 200 --jq ".items[] | select(.content.number == <ISSUE_NUMBER>) | .id")
gh project item-edit --project-id $PROJECT --id "$ITEM_ID" --field-id $STATUS_FIELD --single-select-option-id $IN_PROGRESS_ID
Wenn dieser Schritt vergessen wird, ist das ein Fehler. Immer zuerst ausführen.
Schritt 2: Phasen-Planung & Implementierungsplan erstellen
Bevor irgendwelcher Code geschrieben wird, muss eine Planungsdatei für die Phase erstellt werden.
Planungsdatei anlegen: docs/Plans/PLAN-<phase-name>.md
Beispiel: docs/Plans/PLAN-init-container-ux.md
Die Planungsdatei enthält:
# Phase: <Phasen-Titel> (v0.XX)
## Ziel
<Kurze Beschreibung was diese Phase erreichen soll>
## Analyse
<Zusammenfassung der Codebase-Analyse: bestehende Patterns, betroffene Dateien, Abhängigkeiten>
## Features / Schritte
Reihenfolge basierend auf Abhängigkeiten und logischem Aufbau:
- [ ] **Feature 1: <Name>** – <Kurzbeschreibung>
- Betroffene Dateien: ...
- Abhängig von: -
- [ ] **Feature 2: <Name>** – <Kurzbeschreibung>
- Betroffene Dateien: ...
- Abhängig von: Feature 1
- [ ] **Feature 3: <Name>** – <Kurzbeschreibung>
- Betroffene Dateien: ...
- Abhängig von: -
- [ ] **Dokumentation & Website** – Wiki, Public Website, Roadmap
- [ ] **Phase abschließen** – Alle Tests grün, PR gegen main
## Offene Punkte
- [ ] <Frage oder Unklarheit>
- [ ] <Technische Entscheidung die geklärt werden muss>
## Entscheidungen
| Entscheidung | Optionen | Gewählt | Begründung |
|---|---|---|---|
| <Thema> | A, B, C | B | <Warum B gewählt wurde> |
Fortschritts-Tracking
Status-Markierungen für Features/Schritte:
[ ] – Offen (noch nicht begonnen)
[x] – Erledigt (erfolgreich implementiert)
[-] – Übersprungen (bewusst nicht implementiert, mit Begründung)
Aktualisiere die Planungsdatei nach jedem abgeschlossenen Feature!
Schritt 3: Offene Punkte klären
Bevor du mit der Implementierung beginnst:
- Identifiziere Unklarheiten und Entscheidungen die getroffen werden müssen
- Dokumentiere diese in der Planungsdatei unter "Offene Punkte"
- Frage den User explizit nach offenen Punkten
- Kläre technische Ansätze wenn es mehrere Möglichkeiten gibt
- Dokumentiere getroffene Entscheidungen in der Tabelle "Entscheidungen"
- Stelle sicher, dass der Scope klar definiert ist
Implementiere NICHTS bevor alle Fragen geklärt sind!
Schritt 4: Branches erstellen
WICHTIG: Jedes Epic/Phase bekommt IMMER einen eigenen Integration Branch!
- Ein Epic darf NIEMALS auf dem Integration Branch eines anderen Epics aufbauen
- Auch wenn mehrere Epics in der gleichen Release-Version geplant sind, hat jedes seinen eigenen Integration Branch
- Der Integration Branch wird IMMER von
main abgeleitet
Prüfe ob ein Integration Branch für dieses Epic existiert:
git checkout main && git pull
git branch -a | grep integration/<epic-name>
Falls kein Integration Branch für dieses Epic existiert:
git checkout main
git checkout -b integration/<epic-name>
git push -u origin integration/<epic-name>
Feature Branch vom Integration Branch ableiten:
git checkout integration/<epic-name>
git checkout -b feature/<feature-name>
Schritt 5: Feature-Implementierung planen
Nutze den Plan Mode um für das aktuelle Feature einen detaillierten Implementierungsplan zu erstellen:
- Identifiziere alle betroffenen Dateien
- Plane die Reihenfolge der Änderungen
- Berücksichtige bestehende Patterns im Codebase
- Plane die Test-Strategie
Schritt 6: Tests schreiben
Für jedes Feature müssen drei Test-Ebenen abgedeckt werden:
Unit Tests (xUnit + FluentAssertions)
- Pfad:
tests/ReadyStackGo.UnitTests/
- Nicht nur Happy-Path! Edge Cases und Fehler-Cases sind das Wichtigste
- Teste ungültige Inputs, null-Werte, leere Collections
- Teste State-Transitions und ungültige Übergänge
- Teste Filterlogik explizit
Integration Tests (TestContainers)
- Pfad:
tests/ReadyStackGo.IntegrationTests/
- Teste Zusammenspiel von Services
- Teste Datenbankzugriffe und Persistenz
- Teste API-Endpoints end-to-end
E2E Tests (Playwright)
Schritt 7: Feature implementieren
Schritt 8: AMS UI Impact-Check
WICHTIG: Jedes Feature das @rsgo/core Types, Hooks oder API-Endpunkte ändert, muss auf AMS UI Auswirkungen geprüft werden!
Das AMS UI (C:\proj\ReadyStackGo.Ams) ist ein separates privates Repo das @rsgo/core via File-Link konsumiert und eigene UI-Komponenten (React + AMS Component Library) hat.
Prüfschritte:
-
Betroffene @rsgo/core Exports identifizieren:
- Welche Types/Interfaces wurden geändert oder erweitert? (z.B.
HealthTransitionDto)
- Welche Hooks wurden geändert? (z.B.
useHealthTransitionsStore)
- Welche API-Funktionen wurden geändert? (z.B.
getHealthTransitions)
-
AMS UI durchsuchen nach Nutzung dieser Exports:
cd C:\proj\ReadyStackGo.Ams
grep -r "HealthTransitionDto\|useHealthTransitionsStore\|getHealthTransitions" packages/
-
Falls AMS UI betroffen ist:
- Entsprechende AMS-Komponenten identifizieren (z.B.
packages/ui-ams/src/components/health/)
- AMS-Anpassungen als separaten Task dokumentieren
- Den User fragen ob die AMS-Anpassung jetzt oder als Follow-up erfolgen soll
-
Falls AMS UI NICHT betroffen ist:
- Im PR dokumentieren: "AMS UI: nicht betroffen (keine Nutzung von [geänderte Exports])"
Typische Bereiche mit AMS UI Overlap:
- Health-Komponenten (
packages/ui-ams/src/components/health/)
- Dashboard-Widgets (
packages/ui-ams/src/components/dashboard/)
- Deployment-Detail-Seiten (
packages/ui-ams/src/pages/)
- Hooks (
packages/ui-ams/src/hooks/)
Diesen Schritt NIEMALS überspringen! Vergessene AMS-Anpassungen führen zu veralteten oder inkompatiblen UI-Varianten.
Schritt 9: Verifizierung
ALLE Tests müssen grün sein bevor ein PR erstellt wird!
- Unit Tests ausführen:
dotnet test tests/ReadyStackGo.UnitTests/
- Integration Tests ausführen:
dotnet test tests/ReadyStackGo.IntegrationTests/
- E2E Tests ausführen:
cd src/ReadyStackGo.WebUi && npx playwright test
- Docker Container testen:
docker compose build && docker compose up -d
Anwendung auf http://localhost:8080 prüfen.
Schritt 10: Feature-PR erstellen
- Alle Änderungen committen (kurze, prägnante Commit-Messages, KEIN Footer)
- Branch pushen
- PR erstellen gegen den Integration Branch (nicht gegen main!):
gh pr create --base integration/<phase-name> --title "..." --body "..." --milestone "<Milestone>"
- Falls das Feature ein eigenes GitHub Issue hat:
Closes #NNN im PR Body verwenden
- Das verknüpft den PR mit dem Issue und schließt es automatisch beim Merge
- KEIN Footer in PR-Beschreibungen
- CI-Checks abwarten
- PR mergen und Feature Branch löschen
Board-Status auf "Review" setzen (PFLICHT)
Nach PR-Erstellung das Issue auf Review setzen — NICHT auf Done.
Der User reviewed und testet den PR. Erst nach seiner Bestätigung wird auf Done gesetzt.
PROJECT="PVT_kwHOAKdwzc4BR2Bg"
STATUS_FIELD="PVTSSF_lAHOAKdwzc4BR2Bgzg_jRfE"
REVIEW_ID="f25a5d7c"
ITEM_ID=$(gh project item-list 6 --owner Wiesenwischer --format json --limit 200 --jq ".items[] | select(.content.number == <ISSUE_NUMBER>) | .id")
gh project item-edit --project-id $PROJECT --id "$ITEM_ID" --field-id $STATUS_FIELD --single-select-option-id $REVIEW_ID
WICHTIG: Setze Issues NIEMALS selbst auf "Done". Done wird nur gesetzt wenn:
- Der User den PR reviewed und getestet hat
- Der User explizit bestätigt ("merge", "sieht gut aus", "passt")
- Dann: PR mergen + Board auf Done setzen
DONE_ID="c631b3e2"
gh project item-edit --project-id $PROJECT --id "$ITEM_ID" --field-id $STATUS_FIELD --single-select-option-id $DONE_ID
Board Status IDs (ReadyStackGo Roadmap):
| Status | ID |
|---|
| Backlog | 56c4cbb9 |
| Todo | af3283ef |
| In Progress | 9e4cff0c |
| Review | f25a5d7c |
| Done | c631b3e2 |
Schritt 11: Planungsdatei aktualisieren
Nach jedem abgeschlossenen Feature die Planungsdatei aktualisieren:
- Feature als
[x] markieren
- Eventuelle Erkenntnisse oder Abweichungen dokumentieren
- Übersprungene Features als
[-] markieren mit Begründung
Wiederhole Schritte 5-11 für jedes Feature der Phase.
Schritt 13: Dokumentation & Website (pro Phase)
Wenn alle Features einer Phase implementiert sind, folgende Schritte durchführen:
Wiki / Dokumentation (docs/)
- Neue oder geänderte Features dokumentieren (Deutsch mit englischen Fachbegriffen)
- Bestehende Seiten aktualisieren wenn sich Verhalten ändert
- Wird automatisch ins GitHub Wiki synchronisiert (
.github/workflows/wiki.yml)
Public Website (src/ReadyStackGo.PublicWeb/)
- Neue Features in der Feature-Übersicht auflisten
- User-Dokumentation erweitern (Astro/Starlight, bilingual DE/EN)
- Content-Pfad:
src/ReadyStackGo.PublicWeb/src/content/docs/
- Deutsche Docs:
de/
- Englische Docs:
en/
Release History aktualisieren
- Feature in
docs/Reference/Release-History.md unter der entsprechenden Version eintragen
- Release-Datum hinzufügen
Schritt 14: Phase abschließen
Wenn alle Features, Docs und Website-Updates fertig sind:
- Alle Tests nochmal ausführen (Unit, Integration, E2E) – alles muss grün sein
- PR vom Integration Branch gegen main erstellen:
gh pr create --base main --title "<Phase-Titel>" --body "..." --milestone "<Milestone>"
Closes #NNN im Body für das Epic Issue → schließt das Epic automatisch
- CI-Checks abwarten
- PR mergen und Integration Branch löschen
- Milestone schließen wenn alle zugeordneten Issues erledigt sind:
gh api repos/Wiesenwischer/ReadyStackGo/milestones/<NUMBER> --method PATCH -f state=closed
→ Löst den milestone-release Workflow aus → Release wird automatisch veröffentlicht
Checkliste