Menu
Implement the next feature from the roadmap or a specific feature by name
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
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
Baseado na classificação ocupacional SOC
| 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