5a26d6a85e
Namenskonvention für Genome Engine Verbund-Erkennung: Router <name>.prompt.md + Sub-Prompts <name>-*.prompt.md ermöglicht rein pfadbasierte Trait-Zuordnung ohne Content-Parsing.
118 lines
3.2 KiB
Markdown
118 lines
3.2 KiB
Markdown
---
|
||
description: Implementiert einen einzelnen Arbeitsschritt vollständig (Implementierung → Tests → Review → Abschluss). Wird vom nextstep-Router für [F]-Tickets aufgerufen.
|
||
agent: agent
|
||
model: Claude Opus 4.6 (copilot)
|
||
tools: [read, edit, search, execute, agent, web, todo, browser, vscode]
|
||
---
|
||
|
||
# Workflow: Implementierung [F]
|
||
|
||
Dieser Workflow wird aufgerufen, wenn der nextstep-Router ein `[F]`-Ticket identifiziert hat.
|
||
Die Eingabe enthält: **Issue-Nummer**, **Titel** und **Issue-Body**.
|
||
|
||
---
|
||
|
||
## Aufgabenplanung
|
||
|
||
Erstelle zu Beginn eine TODO-Liste (`manage_todo_list`) mit allen Phasen:
|
||
|
||
1. Kontext lesen
|
||
2. Klarheitsprüfung & Rückfragen
|
||
3. Implementierung
|
||
4. Build & Tests
|
||
5. Code Review
|
||
6. Fortschritt dokumentieren & Issue schließen
|
||
|
||
---
|
||
|
||
## Phase 1 – Kontext lesen
|
||
|
||
1. Lies den vollständigen **Issue-Body** (Scope, Akzeptanzkriterien, Referenzen, `Part of`, `Depends on`).
|
||
2. Lies relevante **Architekturdokumentation** (falls vorhanden).
|
||
3. Prüfe `Depends on`-Tickets: Sind alle Abhängigkeiten als Done markiert?
|
||
4. Lies das **Eltern-P-Ticket** (`Part of: #N`) für übergeordneten Kontext.
|
||
|
||
---
|
||
|
||
## Phase 2 – Klarheitsprüfung & Rückfragen
|
||
|
||
Prüfe anhand des Issue-Bodys:
|
||
|
||
1. **Fehlende Details:** Gibt es Scope-Punkte ohne klare Spezifikation?
|
||
2. **Mehrdeutige Architektur:** Gibt es mehrere gleichwertige Umsetzungswege?
|
||
3. **Unklare Abgrenzung:** Was ist Teil dieses Tickets, was gehört in ein späteres?
|
||
|
||
**Falls Unklarheiten bestehen:** Stelle nummerierte Rückfragen mit Optionen und **warte auf Antwort**.
|
||
|
||
---
|
||
|
||
## Phase 3 – Implementierung
|
||
|
||
Rufe den Subagenten **`android-implementer`** auf. Übergib ihm:
|
||
|
||
- **Titel und Ziel** (ein Satz aus dem Issue)
|
||
- **Vollständige Scope-Liste**
|
||
- **Technische Hinweise** aus dem Ticket
|
||
- **Testkriterien** – welche Tests mindestens zu schreiben sind
|
||
- **Coding Conventions** aus `.github/kotlin-conventions.instructions.md`
|
||
- **Bestehende Dateien**, die erweitert werden müssen (vorher lesen lassen)
|
||
- Hinweis: Kein `git commit`, kein `git push`
|
||
|
||
---
|
||
|
||
## Phase 4 – Build & Tests
|
||
|
||
```
|
||
./gradlew assembleDebug test
|
||
```
|
||
|
||
**Bei Fehlern:** android-implementer mit Korrekturanweisung → erneut testen (max. 3 Zyklen).
|
||
|
||
---
|
||
|
||
## Phase 5 – Code Review
|
||
|
||
Rufe den Subagenten **`code-reviewer`** auf. Übergib ihm:
|
||
|
||
- **Titel und Scope** aus dem Issue
|
||
- **Geänderte Dateien** aus Phase 3
|
||
|
||
**Bewertung:**
|
||
- ✅ Abgenommen → Phase 6
|
||
- ⚠️ Kleinere Korrektionen → android-implementer → Phase 4 → Phase 5 (max. 2 Zyklen)
|
||
- ❌ Wesentliche Mängel → wie oben, dann Fehlerbericht an User
|
||
|
||
---
|
||
|
||
## Phase 6 – Fortschritt dokumentieren & Issue schließen
|
||
|
||
### Abschluss-Kommentar
|
||
|
||
```
|
||
## Abgeschlossen (<heute>)
|
||
|
||
**Zyklen:** <Anzahl Implementierungszyklen>
|
||
**Tests:** ✅ <N> Tests, 0 Fehler
|
||
|
||
### Implementierte Artefakte
|
||
- ✅ <Artefakt 1>: <kurze Beschreibung>
|
||
- ✅ <Artefakt 2>: <kurze Beschreibung>
|
||
|
||
### Abweichungen
|
||
<keine / oder konkrete Abweichungen>
|
||
```
|
||
|
||
### Issue schließen
|
||
|
||
```
|
||
gh issue close <ISSUE_NUMBER>
|
||
```
|
||
|
||
---
|
||
|
||
## Wichtige Regeln
|
||
|
||
- **`git commit` ist autonom erlaubt; `git push` muss kurz angekündigt werden**
|
||
- **Verboten ohne User-Bestätigung:** `git reset --hard`, `git rebase`, `git push --force`
|
||
- Lies Dateien immer vor dem Bearbeiten
|
||
- Halte dich an die Kotlin Coding Conventions
|