36 lines
2.1 KiB
Markdown
36 lines
2.1 KiB
Markdown
---
|
||
description: Komplette Feature-Pipeline für ein Forgejo-Issue – Spec, Freigabe, Umsetzung, Tests, Review, Pull Request
|
||
argument-hint: <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
|
||
3. Subagent `architect` erstellt `docs/specs/$ARGUMENTS-<kurzname>.md` inkl. Aufgaben-Schnitt.
|
||
4. Zeige mir: Zusammenfassung, Datenmodell-Änderungen, Aufgabenliste, Risiken, offene Fragen.
|
||
5. **Warte auf meine Freigabe.** Änderungswünsche zurück an `architect`.
|
||
|
||
## Phase 3 – Umsetzung
|
||
6. Lege für die Tasks der Spec eine Task-Liste an.
|
||
7. `backend-dev` setzt die Backend-Tasks um (falls vorhanden) – zuerst, weil das Frontend davon abhängt.
|
||
8. Neue UI-Komponenten nötig? → `ui-designer` ergänzt das Design-System.
|
||
9. `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
|
||
10. `test-engineer` ergänzt Tests und erstellt die Abdeckungsmatrix. Fehler → zurück an den Entwickler-Agent (max. 3 Runden, dann mich fragen).
|
||
11. Alle Checks lokal grün: `dart format --set-exit-if-changed .`, `flutter analyze`, `flutter test`, ggf. `supabase test db`.
|
||
12. `code-reviewer` prüft den Branch. Blocker → zurück an den Entwickler-Agent, danach erneut Review.
|
||
|
||
## Phase 5 – Pull Request ⏸ Merge durch mich
|
||
13. Push des Branches und PR in Forgejo nach `.forgejo/pull_request_template.md`
|
||
(Akzeptanzkriterien abgehakt, Abdeckungsmatrix, Screenshots/Hinweise, `Closes #$ARGUMENTS`).
|
||
14. Review-Ergebnis als Kommentar an den PR, Label `status/ready-for-merge`.
|
||
15. 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.
|