Menu
Implement the next feature from the roadmap or a specific feature by name
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.
Check which feature plans are fully implemented and archive completed ones
Fix a bug from a GitHub Issue using the Red-Green test approach
Plan a new feature, add it to the roadmap, and create a specification document
Report a bug as a GitHub Issue with description, reproduction steps, and initial analysis
Create E2E tests with screenshots and build step-by-step documentation for the public website
Build and start ReadyStackGo container for manual testing
Based on SOC occupation classification
| 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] |
Implementiere ein neues Feature für ReadyStackGo.
Feature: $ARGUMENTS
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/<phase-name> – Sammelbranch für alle Features einer Phasefeature/<name> – Einzelne Features, werden in den Integration Branch gemergedintegration/init-container-ux, nicht integration/v0.18)feature/ damit der Auto-Labeler sie korrekt als feature labeltfeature/* → Label featurerefactor/* → Label enhancementfix/*, bugfix/*, hotfix/* → Label bugchore/* → Label maintenanceGitHub Project Board lesen um das nächste Feature zu identifizieren:
gh project item-list 6 --owner Wiesenwischer --format json --limit 50
$ARGUMENTS angegeben wurde, suche dieses spezifische Feature in den Issues.$ARGUMENTS leer ist, nimm das Feature mit der höchsten Priorität (niedrigste Priority-Nummer) im Status "Todo".gh issue list --label epic --state open --json number,title,milestoneLies 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/:
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.
Bevor irgendwelcher Code geschrieben wird, muss eine Planungsdatei für die Phase erstellt werden.
docs/Plans/PLAN-<phase-name>.mdBeispiel: 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> |
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!
Bevor du mit der Implementierung beginnst:
Implementiere NICHTS bevor alle Fragen geklärt sind!
WICHTIG: Jedes Epic/Phase bekommt IMMER einen eigenen Integration Branch!
main abgeleitetgit checkout main && git pull
git branch -a | grep integration/<epic-name>
git checkout main
git checkout -b integration/<epic-name>
git push -u origin integration/<epic-name>
git checkout integration/<epic-name>
git checkout -b feature/<feature-name>
Nutze den Plan Mode um für das aktuelle Feature einen detaillierten Implementierungsplan zu erstellen:
Für jedes Feature müssen drei Test-Ebenen abgedeckt werden:
tests/ReadyStackGo.UnitTests/tests/ReadyStackGo.IntegrationTests/src/ReadyStackGo.WebUi/e2e/await page.screenshot({ path: `screenshots/<test-name>-step-01-<beschreibung>.png` });
docker compose build
docker compose up -d
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.
Betroffene @rsgo/core Exports identifizieren:
HealthTransitionDto)useHealthTransitionsStore)getHealthTransitions)AMS UI durchsuchen nach Nutzung dieser Exports:
cd C:\proj\ReadyStackGo.Ams
grep -r "HealthTransitionDto\|useHealthTransitionsStore\|getHealthTransitions" packages/
Falls AMS UI betroffen ist:
packages/ui-ams/src/components/health/)Falls AMS UI NICHT betroffen ist:
packages/ui-ams/src/components/health/)packages/ui-ams/src/components/dashboard/)packages/ui-ams/src/pages/)packages/ui-ams/src/hooks/)Diesen Schritt NIEMALS überspringen! Vergessene AMS-Anpassungen führen zu veralteten oder inkompatiblen UI-Varianten.
ALLE Tests müssen grün sein bevor ein PR erstellt wird!
dotnet test tests/ReadyStackGo.UnitTests/
dotnet test tests/ReadyStackGo.IntegrationTests/
cd src/ReadyStackGo.WebUi && npx playwright test
docker compose build && docker compose up -d
gh pr create --base integration/<phase-name> --title "..." --body "..." --milestone "<Milestone>"
Closes #NNN im PR Body verwendenNach 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:
# Erst NACH User-Bestätigung:
DONE_ID="c631b3e2"
gh project item-edit --project-id $PROJECT --id "$ITEM_ID" --field-id $STATUS_FIELD --single-select-option-id $DONE_ID
| Status | ID |
|---|---|
| Backlog | 56c4cbb9 |
| Todo | af3283ef |
| In Progress | 9e4cff0c |
| Review | f25a5d7c |
| Done | c631b3e2 |
Nach jedem abgeschlossenen Feature die Planungsdatei aktualisieren:
[x] markieren[-] markieren mit BegründungWiederhole Schritte 5-11 für jedes Feature der Phase.
Wenn alle Features einer Phase implementiert sind, folgende Schritte durchführen:
docs/).github/workflows/wiki.yml)src/ReadyStackGo.PublicWeb/)src/ReadyStackGo.PublicWeb/src/content/docs/
de/en/docs/Reference/Release-History.md unter der entsprechenden Version eintragenWenn alle Features, Docs und Website-Updates fertig sind:
gh pr create --base main --title "<Phase-Titel>" --body "..." --milestone "<Milestone>"
Closes #NNN im Body für das Epic Issue → schließt das Epic automatischgh api repos/Wiesenwischer/ReadyStackGo/milestones/<NUMBER> --method PATCH -f state=closed
milestone-release Workflow aus → Release wird automatisch veröffentlichtCloses #NNN