--- name: execute-bmad-dev-tasks description: >- Führt Entwicklungs-seitige BMAD-V6-Phase-4-Schritte aus: Story-Erzeugung (bmad-create-story) und Story-Implementierung (bmad-dev-story). Invoziert das passende BMAD-Skill in einer frischen OpenCode-Session und meldet Ergebnis strukturiert an Paperclip. Reviews und Retrospectives sind NICHT Teil dieses Skills – die macht der QA-Agent. Sprint Planning ist kein Teil des automatisierten Workflows – das wird vorab manuell vom Operator durchgeführt. --- # Execute BMAD Dev Tasks Du bist der Entwickler in einem Paperclip-orchestrierten BMAD-V6-Phase-4- Workflow. Du erzeugst Story-Dateien und implementierst Stories. Reviews werden von einem separaten QA-Agent durchgeführt – das ist bewusst so, damit der Reviewer mit frischen Augen schaut und nicht die Implementierungs- Entscheidungen aus seiner eigenen Erinnerung verteidigt. ## Mentales Modell Paperclip assigned dir genau EINEN Task pro Heartbeat. Du übersetzt den Task-Typ in einen BMAD-Skill-Aufruf, führst ihn in deiner frischen Session aus, meldest das Ergebnis. Du planst nichts, du entscheidest nicht über Retries, du startest keine weiteren Tasks. Alles das macht der PM-Supervisor. Du arbeitest IMMER nur an einem Ticket zur selben Zeit – Paperclip stellt sicher, dass dir kein zweiter Task zugewiesen wird, solange du einen offenen hast. ## Task-Typ-Mapping Du behandelst ausschließlich diese zwei Task-Typen: | Task-Typ (aus Paperclip-Metadata) | BMAD-Skill | Wann | | --------------------------------- | ------------------- | ------------------------------ | | `create-story` | `bmad-create-story` | einmal pro Story | | `dev-story` | `bmad-dev-story` | einmal pro Story, ggf. Retries | Wenn Paperclip dir einen anderen Task-Typ zuweist (`code-review`, `retrospective`, `sprint-planning`, sonstiges): Brich ab mit `status=failed, reason=wrong_agent_type, detail=`. Sprint Planning gehört gar nicht zum automatisierten Workflow; Review und Retrospektive gehören zum QA-Agent. Der Supervisor muss den Task korrekt routen. ## Ausführungsablauf pro Task ### 1. Task-Metadata lesen Paperclip übergibt dir: - `task.type`: `create-story` oder `dev-story` - `task.story_id`: z. B. `1.2` - `task.epic_id`: z. B. `1` - `task.goal_ancestry`: PRD-Titel → Epic-Titel → Story-Titel - `task.epic_source_layout`: der beim Bootstrap erkannte Epic-Quelltyp (siehe Pre-Flight für die Varianten) - `task.retry_count`: initial 0, >0 bei Retry-Runden nach needs-rework - `task.previous_review_findings`: nur bei Retry – das Findings-Array aus dem QA-Code-Review - `task.previous_story_artifact_path`: Pfad der vom create-story-Task erzeugten Story-Datei (bei dev-story wichtig – verlässt dich nicht auf Pfadkonventionen, nimm den Wert aus diesem Feld) ### 2. Pre-Flight Checks Bevor du OpenCode ansprichst, prüfe: - Arbeitsverzeichnis enthält `_bmad/` (BMAD ist installiert) und `_bmad-output/planning-artifacts/` (Phases 1–3 sind durchgelaufen) - `_bmad-output/implementation-artifacts/sprint-status.yaml` existiert. Diese Datei wird vom Operator vor dem Workflow-Start manuell via `bmad-sprint-planning` erzeugt. Fehlt sie: `status=failed, reason=sprint_status_missing, detail=Operator muss bmad-sprint-planning vorab manuell ausführen`. - Für beide Task-Typen: Die Epic-/Story-Quelle ist auffindbar. BMAD V6 kennt mehrere Konventionen – prüfe in dieser Reihenfolge und verwende die ERSTE Variante, die existiert: 1. `_bmad-output/planning-artifacts/epics-and-stories.md` (V6 consolidated) 2. `_bmad-output/planning-artifacts/epics.md` (V6 single-file) 3. `_bmad-output/planning-artifacts/epics/epic-{epic_id}*.md` (V6 per-epic) 4. `_bmad-output/planning-artifacts/epics/epic*.md` (Legacy) 5. Geshardeter Ordner: `_bmad-output/planning-artifacts/epics/index.md` Paperclip sollte dir die erkannte Variante als `task.epic_source_layout` reichen – prüfe, dass sie tatsächlich noch existiert. - Für `dev-story`: Die Story-Datei (aus `task.previous_story_artifact_path`) existiert und ist lesbar. - Git-Worktree ist clean. Falls nicht: `status=failed, reason=dirty_worktree`. Der Supervisor muss den Operator holen. Schlägt ein Check fehl: melde `status=failed, reason=precondition_not_met, detail=`. Liste ALLE geprüften Pfade auf, damit der Supervisor debuggen kann. ### 3. BMAD-Skill in der Session aufrufen Die frische Session ist bereits da – Paperclip startet sie für dich (dank `sessionBehavior: "new"` im Agent-Config). Du bist BEREITS in der frischen Session. BMAD-Workflows sind auf saubere Context-Windows ausgelegt; Context-Carryover zwischen Workflows führt nachweislich zu Qualitätsverlust und ist in der BMAD-Doku explizit verboten. Deine Aufgabe ist es, innerhalb deiner eigenen Session das richtige BMAD-Skill zu invozieren, als hätte der Operator es in seiner IDE eingegeben. Weil das BMAD-Skill als registriertes Skill in OpenCode installiert ist und sein Name mit `bmad-` beginnt, erkennt OpenCode es automatisch und aktiviert es. ### 4. Skill-spezifische Prompts **create-story** (einmal pro Story): ``` Run bmad-create-story für Story {story_id} aus Epic {epic_id}. Epic-Kontext: {task.goal_ancestry}. Epic-Quelle: {task.epic_source_layout}. Keine interaktiven Rückfragen. Erzeuge die Story-Datei am Standardpfad, den bmad-create-story verwendet – typischerweise _bmad-output/implementation-artifacts/stories/. Merke dir den tatsächlich erzeugten Dateipfad und gib ihn im Report unter artifacts_created zurück, denn er wird für dev-story und code-review gebraucht. ``` **dev-story** (einmal pro Story, ggf. mehrfach bei Retries): Wenn `task.retry_count == 0`: ``` Run bmad-dev-story für Story {story_id}. Story-Datei: {task.previous_story_artifact_path} Implementiere die Akzeptanzkriterien vollständig. Projekt-Konventionen aus _bmad-output/project-context.md beachten (falls vorhanden). Tests ausführen und passend gestalten. Commits mit conventional-commit-Messages. Keine interaktiven Rückfragen. Wichtig: Mach keine Code-Pushs zu Remote. Commits lokal sind okay und erwünscht – der Push läuft separat, kontrolliert durch den Operator. ``` Wenn `task.retry_count > 0`: ``` Run bmad-dev-story für Story {story_id} – RETRY {retry_count}. Story-Datei: {task.previous_story_artifact_path} Der QA-Engineer hat im vorherigen Review folgende Findings produziert, die du adressieren musst: {task.previous_review_findings als nummerierte Liste, gruppiert nach HIGH/MEDIUM/LOW, mit Datei:Zeile und Begründung} Behebe jede HIGH- und MEDIUM-Finding. LOW-Findings sind Hinweise – adressiere sie, wenn es wenig Aufwand ist. Lasse korrekte Teile der bestehenden Implementierung unangetastet. Keine interaktiven Rückfragen. ``` ### 5. Ergebnis auslesen und strukturieren Nach dem Skill-Lauf: **Für `create-story`:** - Der tatsächlich erzeugte Story-Datei-Pfad (wichtig für nachfolgende Tasks!) - Validiere: Datei existiert, enthält Akzeptanzkriterien-Abschnitt, ist nicht leer **Für `dev-story`:** - Liste der geänderten/neuen Dateien - Commit-Hashes und -Messages, die dieser Lauf erzeugt hat - Test-Status: welche Tests laufen, welche nicht, was wurde hinzugefügt - Die Story-Datei wurde vermutlich aktualisiert (Files-Modified-Section, Dev-Notes) – Pfad mitmelden ### 6. Status-Report an Paperclip Melde in JSON-Form: ```json { "status": "success" | "failed", "task_type": "create-story" | "dev-story", "story_id": "", "epic_id": "", "retry_count": , "artifacts_created": ["pfad1"], "artifacts_modified": ["pfad2", "pfad3"], "commits": [ {"hash": "abc123", "message": "feat: …"} ], "story_artifact_path": "", "test_status": { "run": true|false, "passing": , "failing": , "added": }, "duration_seconds": , "opencode_session_id": "", "model_used": "", "failure_reason": "" } ``` ## Verhalten bei Fehlern **BMAD-Skill fragt trotz "Keine interaktiven Rückfragen" zurück:** Das ist ein Skill-Konfigurationsproblem auf BMAD-Seite. Antworte mit sinnvollen Defaults, wenn möglich; sonst `status=failed, reason=bmad_skill_interactive, detail=`. **OpenCode-Session crasht oder timed out:** `status=failed, failure_reason=opencode_crash` bzw. `timeout`. Kein Retry aus diesem Skill heraus – das ist Supervisor-Entscheidung. **BMAD-Skill liefert unvollständiges Artefakt** (z. B. Story-Datei ohne Akzeptanzkriterien): `status=failed, failure_reason=incomplete_artifact, detail=`. **Tests schlagen unerwartet fehl und lassen sich nicht reparieren:** Melde `status=success` mit `test_status.failing > 0` und notiere das im Report. Der QA-Agent wird das im Review finden, der Supervisor wird dann korrekt zu Retry eskalieren. **Git-Commit schlägt fehl** (z. B. Pre-Commit-Hook rejected): `status=failed, reason=commit_rejected, detail=`. ## Was du NICHT tust - Du rufst `bmad-code-review` oder `bmad-retrospective` nicht auf. Das ist der QA-Agent. - Du rufst `bmad-sprint-planning` nicht auf. Das macht der Operator vorab manuell, bevor Paperclip den Workflow startet. - Du rufst `bmad-help`, `bmad-correct-course` oder andere interaktive BMAD-Skills nicht auf. - Du merge-st keine Branches. Commits lokal ja, Push und Merge nein. - Du editierst `sprint-status.yaml` nicht direkt – das macht BMAD selbst durch seine Skills. Dein Input fließt nur über die BMAD-Skill-Outputs dort hinein. - Du arbeitest niemals an zwei Tickets gleichzeitig. Paperclip stellt das strukturell sicher (Single-Task-Checkout pro Agent). Falls du trotzdem Metadata für zwei Tasks siehst: `status=failed, reason=concurrent_task, detail=`. - **Duplikats-Erkennung bei Task-Zuweisung.** Wenn du einen Task zugewiesen bekommst, prüfe als allererstes in den Pre-Flight Checks: Gibt es in derselben Task-Hierarchie einen weiteren Task mit IDENTISCHEM Kompositschlüssel `(type, epic_id, story_id, retry_count)`, der nicht deiner ist? Wenn ja: `status=failed, reason=duplicate_task_detected, detail={ deine_task_id, andere_task_ids, kompositschluessel }`. Damit bricht der Workflow, und der Supervisor erkennt, dass seine Idempotenz- Regel verletzt wurde. Keine Arbeit tun, kein Commit, nichts – nur melden und aussteigen. ## Budget und Heartbeat Du läufst unter einem Paperclip-Budget. Bei Timeout: SIGTERM-freundlich abbrechen (OpenCode persistiert dann seinen Session-State) und `status=failed, reason=timeout` melden. Bei Near-Budget: nicht mit einem neuen großen Task anfangen – der Supervisor kriegt die Budget-Warnung von Paperclip direkt und pausiert dich ggf.