cschlaefke/Shuffle
1
0
Fork 0
Code Issues 33 Pull requests 2 Projects Releases Packages Wiki Activity Actions
Shuffle/.claude/commands/feature.md
cschlaefke 317634dac5
Some checks are pending
CI / flutter (push) Waiting to run
Details
CI / supabase (push) Waiting to run
Details
CI / supabase-tests (push) Waiting to run
Details
chore: initial project kit
2026-11-02 12:14:09 +01:00

2.1 KiB
Raw Blame History

description argument-hint
Komplette Feature-Pipeline für ein Forgejo-Issue – Spec, Freigabe, Umsetzung, Tests, Review, Pull Request <issue-nr>

Setze Issue #$ARGUMENTS um. Du bist der Orchestrator: du koordinierst die Subagents, hältst den Überblick und berichtest mir an den Freigabepunkten. Schreibe selbst möglichst keinen Code.

Phase 1 – Vorbereitung

  1. Lade das Issue über Forgejo. Hat es needs-clarification? → Stopp, offene Fragen nennen.
  2. Branch anlegen: git switch -c feature/$ARGUMENTS-<kurzname> von aktuellem main.

Phase 2 – Spec ⏸ Freigabe

  1. Subagent architect erstellt docs/specs/$ARGUMENTS-<kurzname>.md inkl. Aufgaben-Schnitt.
  2. Zeige mir: Zusammenfassung, Datenmodell-Änderungen, Aufgabenliste, Risiken, offene Fragen.
  3. Warte auf meine Freigabe. Änderungswünsche zurück an architect.

Phase 3 – Umsetzung

  1. Lege für die Tasks der Spec eine Task-Liste an.
  2. backend-dev setzt die Backend-Tasks um (falls vorhanden) – zuerst, weil das Frontend davon abhängt.
  3. Neue UI-Komponenten nötig? → ui-designer ergänzt das Design-System.
  4. flutter-dev setzt die Frontend-Tasks um. Unabhängige Tasks dürfen parallel laufen (eigener Worktree je Agent), abhängige nacheinander.

Phase 4 – Qualität

  1. test-engineer ergänzt Tests und erstellt die Abdeckungsmatrix. Fehler → zurück an den Entwickler-Agent (max. 3 Runden, dann mich fragen).
  2. Alle Checks lokal grün: dart format --set-exit-if-changed ., flutter analyze, flutter test, ggf. supabase test db.
  3. code-reviewer prüft den Branch. Blocker → zurück an den Entwickler-Agent, danach erneut Review.

Phase 5 – Pull Request ⏸ Merge durch mich

  1. Push des Branches und PR in Forgejo nach .forgejo/pull_request_template.md (Akzeptanzkriterien abgehakt, Abdeckungsmatrix, Screenshots/Hinweise, Closes #$ARGUMENTS).
  2. Review-Ergebnis als Kommentar an den PR, Label status/ready-for-merge.
  3. Abschlussbericht an mich: was umgesetzt wurde, was offen ist, wie ich es lokal teste.

Nach dem Merge (durch mich) kann docs-writer die Outline-Seite unter „30 Features“ anlegen.