bollwerkadmin/bollwerk
1
0
Fork 0
Code Issues 11 Pull requests Projects Releases Packages Wiki Activity Actions
bollwerk/.github/prompts/workflow-implementation.prompt.md

3.2 KiB
Raw Blame History

description agent model tools
Implementiert einen einzelnen Arbeitsschritt vollständig (Implementierung → Tests → Review → Abschluss). Wird vom nextstep-Router für [F]-Tickets aufgerufen. agent Claude Opus 4.6 (copilot)
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