GravionLabs/deliver

Liefert die offenen PBIs und Bugs eines Issues (ein Arbeitselement = offener Issue mit label pbi oder bug; ein Bug durchläuft denselben Loop, Branch-Typ fix, Closes #<nr>) nacheinander: Ein Unteragent implementiert, ein Unteragent reviewt, diese Sitzung erstellt den PR, wartet auf CI und merged. Die gleichen Schritte auf jeder Plattform (Claude Code, OpenCode, Copilot CLI). Der Zustand lebt nur in GitHub (Issues, Sub-Issues, Branches, PRs), sodass ein Lauf jederzeit gestoppt werden kann und /deliver <nr> dort fortsetzt, wo er aufgehört hat. Die harte Schranke ist das Regelset auf release/next: ein roter oder fehlender erforderlicher Check blockiert den Merge unabhängig von dieser Sitzung.

Eingabe

help (oder --help, -h): gibt references/help.md unverändert aus, nichts weiter.

/deliver status --milestone <name>: gibt den Statusblock (## Status block) aus und stoppt, es wird nichts ausgeliefert.

/deliver <nr> [<nr> …] [--milestone <name>] [--unattended] [--inline] [--max <n>]: jede Zahl ist ein PBI, Bug, Feature oder Epic; --milestone <name> (ein Release, M<n> oder ein Legacy-Titel) fügt die offenen Arbeitselemente dieses Meilensteins hinzu (ein Batch-Lesevorgang des Meilensteins (pwsh <skill-dir>/../github-milestone/scripts/Get-Milestones.ps1 -Mode issues -Name <name> -State open: REST, alle Seiten, keine PRs; die github-milestone-Suche löst M4 zum Titel M4 oder, nach close, M4 (0.2.0) auf; filtere die zurückgegebene Liste nach Label: pbi, bug), plus die Arbeitselemente unterhalb der Features und Epics darin. Der milestone.title dieses Lesevorgangs ist der Titel für gh issue create --milestone; <key> ist sein M<n> oder die Unternummer M<n>.<m> (Legacy: der Titel) und benennt die Zustandsdatei und die Hinweise. Fehlend: einmal nachfragen. --max <n> stoppt nach n ausgelieferten, blockierten oder pausierten PBIs und gibt den Bericht aus (scripts/Invoke-DeliverLoop.ps1 verwendet --max 1 pro frischer Sitzung, references/loop.md).

• Interaktiv (Standard): eine Pausenregel fragt den Benutzer im Chat; ein blockiertes PBI fragt: erneut versuchen, überspringen oder eine Anweisung.
• Kontrollsitzung: interaktiv mit mehr PBIs als deliver.loopThreshold (Standard 3), z. B. jedes --milestone: liefere sie nicht hier aus, starte Invoke-DeliverLoop.ps1 und bleibe eine dünne Sitzung für Entscheidungen, interactive PBIs und Schritt 9 (references/control.md). --inline liefert sie alle in dieser Sitzung aus (Schritte 1 bis 9). --no-preflight überspringt Start 3.
• --unattended (claude -p, opencode run, copilot -p): niemals fragen. Eine Pause kommentiert den Issue, fügt das Label needs-decision hinzu und fährt mit dem nächsten PBI fort, das nicht davon abhängt.

Start

1. gh auth status funktioniert und das Repository hat release/next.
2. gh api repos/{owner}/{repo}/rules/branches/release/next --jq '.[].type': kein required_status_checks in der Ausgabe → warne, dass rote CI hier mergebar ist (Regelset von github-release), dann weiter.
3. Preflight (übersprungen durch --no-preflight): pwsh <skill-dir>/scripts/Test-DeliverPreflight.ps1 -Harness <claude|opencode|copilot> [-Unattended] -Text gibt eine Zeile pro Prüfung aus, ok / behoben / Aktion erforderlich: Skill-Stapel, Whitelist (git, gh, pwsh <skill-dir>/scripts/*, die Verifikationsbefehle von AGENTS.md; Einträge pro Plattform: references/permissions.md, sonst hängt ein unbeaufsichtigter Lauf an einer Eingabeaufforderung), veraltete Worktrees; Reaktionen in references/preflight.md. Schreibe Befehle ohne escapes $(…); die Berechtigungsprüfung kann nicht durch sie hindurchsehen.
4. Fortschrittsereignisse: ohne AGENT_EVENTS_RUN führe pwsh <skill-dir>/scripts/Report-Progress.ps1 -Type run.started -Source session aus und behalte die gedruckte Run-ID. Füge -Run <id> zu jedem späteren Aufruf hinzu (step.finished, attention, issue.finished, run.finished): Bash-Aufrufe teilen keinen Shell-Zustand, und AGENT_EVENTS_RUN als Präfix würde nicht zur Whitelist passen. Jede Fortschrittszeile, Aufmerksamkeitsgrund und das Ende gehen durch Report-Progress.ps1; es zeigt sie in dem Terminal an, in dem die Sitzung läuft (references/terminal-backends.md).

Schritte

Gib eine Zeile pro Schritt im Chat aus: #<nr> <step>: <result> (#12 review: 1 blocking → fix 1/2). Melde jede Zeile: pwsh <skill-dir>/scripts/Report-Progress.ps1 -Type step.finished -Issue <nr> -Step <step> -Result "<result>" [-Pr <url>]. Auch -Type attention (-Kind pr_opened mit -Pr <url> nach Schritt 6, review_fix wenn ein Review- oder CI-Durchlauf einen Fix-Durchlauf startet, ci_red wenn Schritt 7 rot ist; -Reason): die Benachrichtigungen der Schleife kommen nur von diesen Ereignissen. Eine Pause, ein blockiertes PBI oder ein Punkt, der den Benutzer benötigt: stattdessen -Type attention (-Kind paused, blocked oder needs_you, -Reason). Nach jedem PBI -Type issue.finished -Issue <nr> -Outcome <outcome>.

Jeder PR und Issue, den der Chat nennt, wird als vollständige URL geschrieben (https://github.com/<owner>/<repo>/pull/<n>, .../issues/<n>), nicht als bloßes #<n>: eine bloße Zahl ist im Terminal kein Link. Dies gilt für die Fortschrittszeilen, die Fragen an den Benutzer und den Bericht, insbesondere für den Release-PR (Schritt 9), den der Benutzer mergen muss. Hole die URL von gh (html_url), baue sie niemals aus dem Gedächtnis.

1. Auswählen. gh api repos/{owner}/{repo}/issues/<nr> --jq '{number,title,state,labels:[.labels[].name],body}' für jede Nummer und ihre Sub-Issues (github-issue references/sub-issues.md, rekursiv bis zu PBIs und Bugs). Sammle die offenen Arbeitselemente (pbi oder bug) aller Nummern und des Meilensteins, entferne Duplikate, behalte die ohne needs-decision (eines, dessen Body das ADR-Kriterium hat, wird gemeldet als #<nr> select: decision, write the ADR with adr); ordne sie nach ihren blocked-by-Links über alle hinweg, bei Gleichstand die Reihenfolge der Argumente. Mit --milestone wird ein PBI oder Bug, das über ein Feature oder Epic des Meilensteins erreicht wird, das keinen oder einen anderen Meilenstein hat, nicht ausgeliefert (#<nr> select: outside M<n>, skipped, Hinweis: setze den Meilenstein, github-issue references/milestones.md); /deliver <feature> ohne --milestone liefert alle seine PBIs aus. Ein PBI, dessen Blocker noch offen und nicht im Set ist, wartet und wird gemeldet (ein Blocker außerhalb des Meilensteins wird nie ausgeliefert). Ein PBI oder Bug mit needs-refinement, oder ein Bug ohne Reproduktions- oder Akzeptanzkriterien, wird übersprungen (#<nr> select: needs refinement, skipped, Hinweis planner refine <nr>); /deliver <nr> auf einem solchen Element lehnt es ab. Unattended wird ein PBI mit interactive übersprungen (#<nr> select: interactive, skipped, Hinweis /deliver <nr> in einer Sitzung); der interaktive Modus liefert es aus, auch über ein Feature, Epic oder einen Meilenstein. Ein offenes PBI mit release-test (der RC-Test des Meilensteins) wird nie als Arbeit ausgewählt, weder in den Schritten 1 bis 8 noch in der Kontrollsitzung, auch nicht mit interactive oder als explizites <nr>: #<nr> select: release test, left for step 9 (mit offenen Elementen davor: release test, waits for <n> open items; wartend, nicht needs you; references/loop.md). Es bleibt offen für Schritt 9 und den Menschen (der RC-Test läuft auf dem RC). Überspringe ein PBI, das eine andere Sitzung beansprucht hat (#<nr> select: claimed, skipped), übernehme einen veralteten Anspruch (references/claim.md); /deliver <nr> auf dem PBI selbst setzt es unabhängig vom Anspruch fort. Kündige das nächste PBI an und beanspruche es: gh issue edit <nr> --add-assignee @me; die Auswahlzeile nennt seine Stufe und Modell (#<nr> select: next (tier standard → sonnet/medium); ohne eine Tier:-Zeile tier from size M oder default; references/roles.md).
   • Ein Feature- oder Epic-Kind ohne PBIs: lade planner (interaktiv) und grill-me in dieser Sitzung, erstelle die Issues, wähle dann erneut aus. Unattended: kommentiere und label needs-decision stattdessen.
2. Fortsetzen. Branch <type>/<nr>-<slug> (github-issue). git ls-remote --heads origin <branch> und gh api "repos/{owner}/{repo}/pulls?head=<owner>:<branch>&state=open" --jq '.[].number' (der head benötigt das Owner-Präfix): ein vorhandener Branch wird fortgesetzt, ein vorhandener PR springt zu Schritt 7.
3. Implementieren. Ein Unteragent mit einem frischen Kontext: "Lade implementation, Rolle implement. Implementiere PBI # (ein Bug: lade zuerst diagnose, dann implementation) in deinem eigenen Worktree auf <branch> von origin/release/next (ein vorhandener Branch: wechsle zu ihm und rebase). Akzeptanzkriterien: . Commite, pushe, berichte in maximal 10 Zeilen: erledigt oder blockiert, Commits, Tests ausgeführt und notes[] (eine pro Zeile); ein passender specMap-Eintrag ohne Spec-Änderung gibt den Hinweis no spec change needed: <spec> — <reason> (implementation references/specs.md)."
4. Reviewen. Ein Unteragent mit einem frischen Kontext: "Lade code-review, Rolle review. Reviewe git diff origin/release/next...origin/<branch> gegen diese Akzeptanzkriterien: . Mit governance: führe Get-GovernanceMatches.ps1 -Head origin/<branch> aus; Issue-Labels und Implementierer notes[] . Read-only: kein stash, checkout, switch oder commit in einem vorhandenen Checkout; wenn du Dateien benötigst, verwende deinen eigenen temporären Worktree. Gib nur JSON zurück: das Ergebnis pro review.schema.json von code-review (blocking[] mit file, line, title, why; notes[], bis zu 5) plus unmet[] (nicht erfüllte Kriterien)." Nur blockierende Befunde und nicht erfüllte Kriterien zählen. Nach jedem Durchlauf dieser Sitzung (nicht dem Unteragenten) schreibe die Datei <git-common-dir>/.agents/state/review-<nr>.json (git rev-parse --git-common-dir, dieselbe Datei von jedem Worktree, niemals committet), überschreibe den vorherigen Durchlauf: { pbi, branch, sha, round, unmet, review }, sha = git rev-parse origin/<branch>, round = 1-basierter Review-Durchlauf, review = das Ergebnis des Unteragenten; Schema schema/deliver-review.schema.json. Auch pwsh <skill-dir>/../code-review/scripts/ConvertTo-Findings.ps1 -Review <result with unmet> -Sha <sha> -Worktree <pbi-worktree> schreibt <pbi-worktree>/.agents/state/findings.json für poimen (niemals committet, lokal ausgeschlossen; references/findings.md).
5. Fix. Etwas zählt: ein Unteragent mit einem frischen Kontext lädt implementation mit Rolle fix, wechselt seinen eigenen Worktree zu <branch> (git fetch origin <branch>, git switch -C <branch> origin/<branch>), erhält genau diese Befunde (blocking[] und unmet[]), committet und pusht. Dann Schritt 4 erneut. Maximal 2 Fix-Durchläufe pro PBI, geteilt von Review und CI; ein dritter ist eine Pause.
6. PR. github-pull-request (sein Titel ist der Issue-Titel ohne das Ebenen-Präfix, (#<nr>) angehängt) mit issue_number, branch: <branch> (die Arbeit wird von einem anderen Worktree gepusht, dieser Checkout bleibt wie er ist), review_notes (notes[] von Schritt 4), mit governance spec_notes (die Implementierer-notes[]-Zeilen, die mit no spec change needed: beginnen) und dem Testergebnis des Unteragenten.
7. CI. Führe gh pr checks <pr> --watch --required --interval 60 direkt aus (jeder Poll ist eine GraphQL-Abfrage; der Standard von 10 s verbraucht das Budget), ohne Pipe oder Ausgabefilter (wie tail, head oder grep), damit der Fortschritt des Watchs die Sitzung erreicht.
   • Rot durch diese Änderung (Test-, Lint- oder Build-Fehler in Dateien des Diffs): Fix-Durchlauf (Schritt 5), dann Schritt 4 und 7 erneut.
   • Rot aus einem anderen Grund (Flake, auch rot auf release/next): kommentiere auf dem PR, das PBI ist blockiert.
8. Mergen. Ohne Nachfrage, in beiden Modi: der letzte Review hatte keinen blockierenden Befund oder nicht erfülltes Kriterium und die erforderlichen Checks sind grün. gh pr merge <pr> --squash --delete-branch, dann gh issue close <nr> --comment "Delivered in #<pr>" (Closes feuert nicht auf release/next); offene Legacy-[Task]-Sub-Issues des PBI werden damit geschlossen (github-issue references/sub-issues.md, "Legacy Task issues"); dann gh issue edit <nr> --remove-assignee @me. Räume die Worktrees und Branches der Unteragenten mit dem Skript dieses Skills auf, scripts/Remove-PbiWorktrees.ps1 im Skill-Verzeichnis (~/.claude/skills/deliver/ global, .claude/skills/deliver/ Projektinstallation), ausgeführt im Repository: pwsh <skill-dir>/scripts/Remove-PbiWorktrees.ps1 -Pr <pr> -Issue <nr>; gib #<nr> cleanup: <n> removed aus und behalte seine left-Einträge (Pfad oder Branch, Grund, Befehl) für den Bericht. Nächstes PBI: Schritt 1.
9. Release. Nur mit --milestone, vor dem Bericht (auch nach --max), wenn kein PBI mehr auszuwählen ist. Lese den Meilenstein einmal, Get-Milestones.ps1 -Mode issues -Name <name> -State all (offen und geschlossen); die Offen-Arbeit-Prüfung, der Marker, die Rundenanzahl und die Kriterien der geschlossenen Issues kommen aus dieser Liste. Kein offener Issue mit Label pbi oder bug darin außer dem release-test-Issue (nichts blockiert, pausiert, wartend oder übersprungen); der RC-Test blockiert nie.
   • Ein geschlossenes PBI oder Bug des Meilensteins mit Label needs-decision ist der Pausenmarker eines Release-Reviews der dritten Runde: überspringe das Review, gib release: paused in round 3, waits for a decision aus.
   • Release Review (references/release-review.md): ein Unteragent mit einem frischen Kontext lädt code-review, Rolle review, auf git diff origin/main...origin/release/next mit den Akzeptanzkriterien der geschlossenen PBIs und Bugs des Meilensteins, Fokus auf Konsistenz über die PBIs hinweg, und gibt JSON pro review.schema.json zurück, read-only (kein stash, checkout, switch oder commit in einem vorhandenen Checkout; eigener temporärer Worktree, wenn er Dateien benötigt); diese Sitzung schreibt <git-common-dir>/.agents/state/release-review-<key>.json.
   • Blockierende Befunde: ein [Bug] fix: …-Issue pro Befund im Meilenstein (interaktiv: zeige sie und frage zuerst), kein Release-PR; gib release: <n> blocking → #a, #b aus. Maximal 2 Release-Review-Durchläufe pro Meilenstein; ein dritter mit blockierenden Befunden ist eine Pause, aufgezeichnet mit diesem Marker und einem Kommentar, der die beiden Wege benennt (references/release-review.md, "Pause marker").
   • Sauber (keine blockierenden): schneide den RC, poste ihn auf dem release-test-Issue und schließe ältere (references/release-review.md, "RC test"); release.test.gate: true stoppt dort mit needs you: RC test <issue URL> bis der Issue geschlossen ist. Ansonsten lade github-release und führe finish mit release_review_notes (die notes[], bis zu 5) aus: es erstellt den Release-PR von release/next in main (auto_merge: false) oder meldet den vorhandenen; es stoppt, wenn main kein Vorfahre von release/next ist (zuerst Back-Merge, github-release), melde diesen Stopp. Gib release: clean, <url> aus (der URL des Release-PRs).