Initial Commit
This commit is contained in:
@@ -0,0 +1,265 @@
|
||||
---
|
||||
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=<task_type>`. 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=<was wurde gesucht, wo>`. 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": "<immer>",
|
||||
"epic_id": "<immer>",
|
||||
"retry_count": <aus task.retry_count übernommen>,
|
||||
"artifacts_created": ["pfad1"],
|
||||
"artifacts_modified": ["pfad2", "pfad3"],
|
||||
"commits": [
|
||||
{"hash": "abc123", "message": "feat: …"}
|
||||
],
|
||||
"story_artifact_path": "<Pfad der Story-Datei – wichtig für Folge-Tasks>",
|
||||
"test_status": {
|
||||
"run": true|false,
|
||||
"passing": <zahl>,
|
||||
"failing": <zahl>,
|
||||
"added": <zahl>
|
||||
},
|
||||
"duration_seconds": <messen>,
|
||||
"opencode_session_id": "<aus OpenCode-Output>",
|
||||
"model_used": "<welches Modell gerade aktiv, für Audit>",
|
||||
"failure_reason": "<nur bei status=failed>"
|
||||
}
|
||||
```
|
||||
|
||||
## 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=<Frage>`.
|
||||
|
||||
**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=<was fehlt>`.
|
||||
|
||||
**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=<hook-output>`.
|
||||
|
||||
## 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=<beide Task-IDs>`.
|
||||
- **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.
|
||||
Reference in New Issue
Block a user