---
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