Projekt ausliefern

Was macht Projekt ausliefern?

Führe das Backlog bis zum Merge auf main aus. Jedes Ticket wird zu einem PR, der von der GitHub-Review-Automatisierung und von Menschen überprüft wird. Ihre Aufgabe ist es, den Workflow am Laufen zu halten: Starten Sie Tickets, sobald sie starten können, halten Sie jeden PR gesund, reagieren Sie auf Review-Feedback, das es wert ist, umgesetzt zu werden, halten Sie gestapelte Branches rebased, während ihre Eltern gemergt werden, und halten Sie die Ticket-Status auf dem neuesten Stand.

Sie sind der Orchestrator. Sie lesen den Zustand, entscheiden, delegieren und führen die Bücher. Agents schreiben den gesamten Code, lösen Konflikte und pushen. Sie bearbeiten keinen Code und führen keine Rebases in diesem Checkout durch, damit das Hauptprojektordner sauber bleibt und jede Änderung nachvollziehbar ist.

Eingabe

$ARGUMENTS

• Tasks-Datei: die lokale *.tasks.md aus /task-breakdown (nicht versioniert, normalerweise in einem git-ignorierten Ordner wie .rfcs/). Wenn keine angegeben ist, suchen Sie dort und in docs/rfcs/; falls mehrere existieren, fragen Sie nach.
• --parallel N: maximale Anzahl gleichzeitig arbeitender Agents aller Art. Standard: 3.
• --max-stack N: maximale Tiefe eines PR-Stapels. Standard: 3. Tiefere Stapel entsperren mehr Arbeit, vervielfachen aber Rebases, wenn sich ein Elternteil ändert.
• --auto-merge: wenn ein PR auf main den Status pr-ready hat, aktivieren Sie GitHub Auto-Merge dafür (gh pr merge --auto mit der üblichen Merge-Methode des Repos). GitHub erzwingt weiterhin Branch-Schutz und erforderliche Genehmigungen. Standardmäßig deaktiviert: Menschen mergen.
• --once: führen Sie einen einzelnen Durchlauf aus und beenden Sie ihn. Verwenden Sie dies, um die Auslieferung nach einem Zeitplan auszuführen, z. B. /loop 15m /deliver-project <tasks-file> --once, anstatt eine lange Sitzung offen zu halten.

Wo der Zustand lebt

• Tracker (Linear, Jira, GitHub Issues, …), für Tickets, die veröffentlicht sind (sie haben einen Tracker:-Schlüssel in der Aufgaben-Datei). Es ist die Quelle der Wahrheit dafür, ob ein Ticket existiert und gewünscht ist: Ein dort storniertes, gelöschtes oder neu zugewiesenes Ticket wird übersprungen. Verschieben Sie Tracker-Issues durch ihre Status, während die Tickets fortschreiten, es sei denn, die GitHub-Integration des Trackers macht das bereits (überprüfen Sie dies nach dem ersten geöffneten PR und kämpfen Sie nicht dagegen an).
• Lokale Aufgaben-Datei, im Hauptprojektordner. Sie ist die Quelle der Wahrheit für den Auslieferungszustand, und Sie sind ihr einziger Schreiber während des Laufs: Agents lesen sie, bearbeiten sie aber nie. Status: open → in progress → pr-draft → pr-open → pr-ready → pr-merged → done, plus blocked und canceled mit einem Grund. Spikes gehen open → in progress → decision-proposed → decided → done. Halten Sie Branch / PR: (oder Decision: für Spikes) ausgefüllt.
• GitHub, für den PR-Zustand: offen, gemergt, Checks, Reviews, Merge-Fähigkeit. Eine Abhängigkeit ist gemergt, wenn ihr PR gemergt ist, unabhängig davon, was in einer Datei steht.
• Branches identifizieren die PRs dieses Laufs: Jeder Branch ist <username>/<project-slug>/<task-branch>, daher sind die PRs dieses Laufs die PRs des Benutzers, deren Head-Branch mit <username>/<project-slug>/ beginnt. So findet ein neugestarteter Lauf alles wieder.
• Laufprotokoll, <rfc-name>.run.md neben der Aufgaben-Datei (lokal, nicht versioniert), für das, was kein Ticket-Status ist: laufende Agents, Parent Head SHA jedes gestapelten Branches, behandelte Kommentar-IDs, Feedback-Runden, CI-Fix-Versuche, Eskalationen, Folgemaßnahmen. Verwenden Sie templates/run-log.md. Wenn es verloren ist, bauen Sie es aus GitHub neu auf.

references/github.md enthält die gh-Befehle zum Lesen des PR-Zustands, von Review-Threads und Checks.

1. Preflight (nur erster Durchlauf)

Stoppen Sie mit einer klaren Nachricht, wenn einer der folgenden Punkte fehlschlägt:

1. Tasks-Datei ist in Ordnung: IDs, Status, vorhandene Abhängigkeiten, Abnahmekriterien, ein Project slug:, keine Abhängigkeitszyklen.
2. Tracker erreichbar: Wenn ein Ticket einen Tracker-Schlüssel hat, muss der Connector des Trackers verfügbar sein, da Sie ihn benötigen, um Stornierungen zu überprüfen und Status zu aktualisieren. Wenn nicht, geben Sie an, welcher Connector aktiviert werden muss, und bieten Sie an, nur mit der lokalen Datei fortzufahren.
3. Repo ist bereit: sauberer Arbeitsbaum, ein Remote, gh authentifiziert mit Push- und PR-Rechten, und main baut und besteht Tests. Ermitteln Sie <username> (das Präfix der vorhandenen Branches des Benutzers, andernfalls gh api user --jq .login) und das Branch-Präfix.
4. Agents können unbeaufsichtigt arbeiten: Hintergrund-Agents zeigen jede Berechtigungsabfrage in dieser Sitzung an, sodass eine Abfrage das Team aufhält. Empfehlen Sie den Auto-Modus oder erlauben Sie Regeln für git (einschließlich push --force-with-lease), gh, die Test-, Lint- und Build-Befehle des Repos und den Tracker-Connector.
5. Skills verfügbar: implement-task und spike-task sind installiert, wo Agents sie laden können, und task-breakdown steht Ihnen zur Verfeinerung nach Entscheidungen zur Verfügung.
6. Review-Automatisierung: Finden Sie den GitHub-Workflow, der PRs überprüft, und notieren Sie seinen Check-Namen und Bot-Login, damit Sie wissen, wann sein Review abgeschlossen ist und welche Kommentare seine eigenen sind.

Zeigen Sie dann den Plan und holen Sie eine Bestätigung ein: Ticketanzahl, was jetzt starten kann und was gestapelt wird, Parallelität, maximale Stapeltiefe, ob Auto-Merge aktiviert ist, und einen ehrlichen Hinweis, dass jeder Agent eine vollständige Sitzung ist und der Lauf erhebliche Nutzung verursacht. Danach läuft er unbeaufsichtigt.

2. Jeder Durchlauf

Führen Sie diese in der angegebenen Reihenfolge aus. „Bottom-of-stack first“ ist wichtig: Eine Korrektur oder ein Merge eines Elternteils ändert, was seine Kinder tun müssen.

a. Synchronisieren

Führen Sie git fetch durch. Listen Sie die PRs dieses Laufs (nach Branch-Präfix) mit Status, Basis, Head-SHA, Checks, Review-Entscheidung und Merge-Fähigkeit auf. Aktualisieren Sie veröffentlichte Tickets aus dem Tracker und überspringen Sie stornierte. Sammeln Sie die Berichte von Agents, die seit dem letzten Durchlauf fertig geworden sind (jeder endet mit einem RESULT-Block). Gleichen Sie ab: Wenn GitHub und die Aufgaben-Datei sich widersprechen, gewinnt GitHub für den PR-Zustand; korrigieren Sie die Datei.

b. Merges behandeln

Für jeden PR, der seit dem letzten Durchlauf gemergt wurde: Setzen Sie sein Ticket auf pr-merged und verschieben Sie das Tracker-Issue auf „erledigt“, es sei denn, die Integration hat das bereits getan. Setzen Sie es auf done, sobald der Tracker anzeigt, dass es geschlossen ist, und alle Rollout-Schritte im Ticket abgeschlossen sind. Jeder PR, der direkt auf den gemergten PR gestapelt ist, muss auf main rebased und seine Basis auf main geändert werden: Starten Sie einen Restack-Agent pro betroffenem Stapel (siehe references/stacks.md; geben Sie dem Agent den absoluten Pfad ${CLAUDE_SKILL_DIR}/references/stacks.md).

c. Entscheidungen voranbringen

Spikes blockieren die Tickets hinter ihnen, und nur der Benutzer genehmigt eine Entscheidung, weil Entscheidungen den Plan ändern.

• Halten Sie für jeden Spike im Status decision-proposed sicher, dass der Benutzer ihn gesehen hat: Setzen Sie ihn an den Anfang Ihres Updates mit der Frage, der Empfehlung und dem Vertrauen, den vorgeschlagenen Backlog-Änderungen in einer Zeile und dem Pfad des Entscheidungsprotokolls. Bitten Sie ihn, ihn zu genehmigen, eine andere Option zu wählen oder den Spike zu verlängern. Halten Sie alles andere in der Zwischenzeit am Laufen.
• Der Benutzer genehmigt, indem er es Ihnen in dieser Sitzung mitteilt oder zwischen --once-Durchläufen den Spike in der Aufgaben-Datei auf decided setzt (mit der gewählten Option im Protokoll). Wenn ein Spike decided wird: Notieren Sie die Genehmigung in der Zeile Status: des Entscheidungsprotokolls, verfeinern Sie dann das Backlog mit den Schritten des task-breakdown-Skills („Refining after a spike“) (die Genehmigung des Benutzers deckt die Tracker-Synchronisierung ab) und setzen Sie den Spike auf done. Seine Abhängigkeiten werden im nächsten Schritt startbar.
• Wenn der Benutzer sich für eine Verlängerung des Spikes entscheidet, setzen Sie ihn zurück auf open mit der eingegrenzten Frage im Feld Question:.

d. Offene PRs gesund halten

Arbeiten Sie die offenen PRs durch, zuerst den untersten jedes Stapels. Halten Sie höchstens einen Agent pro Branch oder Stapel gleichzeitig, damit niemand einen Branch rebased, während jemand anderes daran arbeitet. Solange Arbeit an einem PR aussteht, hat sein Ticket den Status pr-open.

1. Elternteil verschoben. Wenn ein gestapelter PR neue Commits von seinem Elternteil erhalten hat (sein Head-SHA weicht von dem für das Kind aufgezeichneten ab), rebasen Sie das Kind auf den neuen Head des Elternteils.
2. Konflikte mit der Basis. Wenn GitHub den PR als in Konflikt oder als veraltet meldet, wo der Branch-Schutz Aktualität erfordert, rebasen Sie ihn. Rebasen Sie nicht nur, weil main sich bewegt hat; das löst erneut CI und Review ohne Grund aus.
3. CI schlägt fehl. Lesen Sie die fehlgeschlagenen Logs. Wenn es flaky oder nicht mit dem PR zusammenhängend aussieht (Infrastruktur, ein Test, der auch auf main fehlschlägt), führen Sie die fehlgeschlagenen Jobs einmal erneut aus. Wenn der PR die Ursache ist, starten Sie einen Feedback-Agent mit dem Fehler als Element. Nach zwei fehlgeschlagenen Korrekturversuchen setzen Sie das Ticket auf blocked und eskalieren.
4. Review-Feedback. Warten Sie, bis der Check der Review-Automatisierung abgeschlossen ist. Sortieren Sie dann jeden ungelösten Review-Thread und jeden Kommentar, den Sie noch nicht bearbeitet haben (Abschnitt 3), und starten Sie einen Feedback-Agent pro PR mit den zu adressierenden Punkten und den zu postenden Antworten.
5. Bereit. Grüne Checks, Review-Automatisierung abgeschlossen, kein unbeantwortetes Feedback: Setzen Sie das Ticket auf pr-ready. Wenn seine Basis main ist und --auto-merge aktiviert ist, aktivieren Sie Auto-Merge; andernfalls listen Sie es als bereit für den menschlichen Merge in Ihrem Update auf.

e. Neue Tickets starten

Füllen Sie freie Agent-Slots mit Tickets, die starten können. Spikes zuerst, da sie andere Arbeit blockieren; dann Tickets auf dem kritischen Pfad.

• Spikes können starten, wenn sie open sind und ihre Abhängigkeiten erledigt sind. Starten Sie einen Spike-Agent mit dem Spike-Prompt in references/agent-prompts.md und setzen Sie das Ticket auf in progress. Spikes bekommen nie einen PR und nichts wird auf sie gestapelt.
• Ein Ticket kann starten, wenn es open ist, nicht im Tracker storniert, jeder Spike, von dem es abhängt, done ist und jede andere Abhängigkeit entweder gemergt ist oder einen offenen PR mit grünen Checks und keinen angeforderten Änderungen hat, wobei alle ungemergten Abhängigkeiten auf einer einzigen Stapellinie liegen. Basieren Sie es auf dem obersten ungemergten Abhängigkeits-Branch oder auf main, wenn alle gemergt sind. Überschreiten Sie nicht --max-stack.
• Wenn zwei ungemergte Abhängigkeiten auf verschiedenen Stapeln liegen, warten Sie, bis einer gemergt ist.
• Führen Sie nicht zwei Tickets gleichzeitig aus, deren Files: sich überschneiden.

Entscheiden Sie den Branch-Namen (<username>/<project-slug>/<task-branch>, mit dem Tracker-Schlüssel in task-branch, wenn veröffentlicht), setzen Sie das Ticket auf in progress (und das Tracker-Issue ebenfalls, es sei denn, die Integration macht das), und starten Sie den Implementierer mit dem Prompt in references/agent-prompts.md: einen Allzweck-Agent, im Hintergrund, mit isolation: "worktree" beim Agent-Aufruf, benannt wie impl-T-04. Wenn er einen PR meldet, setzen Sie das Ticket auf pr-open und notieren Sie Branch und PR.

f. Melden und warten

Wenn sich etwas geändert hat, geben Sie dem Benutzer ein kurzes Update: geöffnete PRs, gemergte, rebased, bearbeitetes Feedback, worauf auf Menschen gewartet wird und neue Eskalationen. Bleiben Sie ruhig, wenn sich nichts geändert hat.

Mit --once hier beenden. Andernfalls warten Sie etwa 5–10 Minuten vor dem nächsten Durchlauf, indem Sie die Planungs- oder Überwachungstools der Sitzung verwenden (z. B. einen Monitor auf einen gh-Polling-Befehl), anstatt in einer Schleife zu schlafen. Wachen Sie früh auf, wenn ein Agent fertig wird.

3. Review-Feedback priorisieren

Für jeden noch nicht bearbeiteten Kommentar oder Thread entscheiden Sie sich für eine von vier Optionen und notieren Sie die Kommentar-ID als bearbeitet:

• Adressieren, wenn er auf einen echten Fehler hinweist: einen Bug, ein verpasstes oder schwach getestetes Abnahmekriterium, ein Sicherheits- oder Datenverlustrisiko, eine gebrochene Repo-Konvention oder eine klare, konkrete Anfrage eines menschlichen Reviewers.
• Nachverfolgen, wenn er gültig, aber außerhalb des Ticket-Umfangs ist (neues Verhalten, breitere Refaktorisierung). Bauen Sie es nicht ein. Notieren Sie es im Laufprotokoll und im Abschlussbericht als Kandidaten-Ticket, und lassen Sie den Feedback-Agent mit einer Zeile antworten, dass es als Folgemaßnahme verfolgt wird.
• Ablehnen, wenn ein automatisierter Kommentar ein False Positive, Geschmackssache oder eine Anfrage nach zusätzlicher Struktur ist, die das Ticket nicht benötigt, da dies den Ansatz der kleinsten Änderung zunichtemachen würde. Lassen Sie den Feedback-Agent mit einer Zeile Begründung antworten. Lehnen Sie auf diese Weise nur automatisierte Kommentare ab.
• Eskalieren, wenn ein menschlicher Reviewer etwas verlangt, das Sie sonst ablehnen würden, oder Reviewer sich uneinig sind, oder der Kommentar das Design selbst in Frage stellt. Diskutieren Sie nicht mit Menschen in Threads; leiten Sie es mit dem Kommentar-Link an den Benutzer weiter.

Begrenzen Sie automatisiertes Review auf drei Feedback-Runden pro PR. Wenn die Review-Automatisierung danach weiterhin neue Punkte aufwirft, eskalieren Sie anstatt eine Schleife zu wiederholen.

4. Wenn ein Agent berichtet

• done: Ein PR eines Implementierers ist offen, oder Feedback- oder Restack-Arbeit wurde gepusht. Aktualisieren Sie den Ticket-Status und das Laufprotokoll; überprüfen Sie den PR im nächsten Durchlauf erneut.
• decision-proposed (Spike): Setzen Sie den Spike auf decision-proposed, füllen Sie Decision: mit dem Pfad des Protokolls und leiten Sie es an den Benutzer weiter (Schritt 2c).
• inconclusive (Spike): Setzen Sie ebenfalls decision-proposed und leiten Sie es als nicht schlüssig mit dem empfohlenen nächsten Schritt des Agents weiter (ein engerer Spike oder ein umkehrbarer Standard, um fortzufahren).
• already-met: Überprüfen Sie die Behauptung anhand des Codes und der Kriterien. Wenn sie zutrifft, teilen Sie dem Benutzer mit, dass das Ticket als bereits erledigt geschlossen werden kann; wenn nicht, setzen Sie den Agent mit SendMessage fort und sagen Sie, was fehlt.
• needs-split oder blocked: Setzen Sie das Ticket auf blocked mit dem Grund, notieren Sie eine Eskalation mit den Notizen des Agents und dem vorgeschlagenen Split und fahren Sie mit anderer Arbeit fort. Wenden Sie Splits nicht selbst an.
• Kein RESULT-Block oder ein Absturz: Setzen Sie den Agent einmal mit SendMessage fort; wenn das auch fehlschlägt, eskalieren Sie.

5. Stopp und Abschluss

Stoppen Sie das Starten neuer Arbeit, lassen Sie laufende Agents beenden, und melden Sie, wenn:

• jedes Ticket pr-merged oder done ist (Erfolg), oder
• nichts ohne menschliches Eingreifen weitergehen kann (alles Übrige wartet auf Review, Merges, Entscheidungen oder Eskalationen). Sagen Sie genau, worauf von wem gewartet wird; ein späterer Lauf oder der nächste --once-Durchlauf setzt von dort aus fort, oder
• main nach einem Merge rot ist. Starten Sie einen Agent, um es als ungeplantes Ticket zu beheben (als solches protokolliert), und halten Sie neue Tickets zurück, bis main wieder grün ist, oder
• der Benutzer Ihnen sagt, Sie sollen aufhören.

Der Abschlussbericht umfasst: gemergte Tickets von der Gesamtzahl, offene PRs und worauf jeder wartet, auf Genehmigung wartende Entscheidungen, Folgemaßnahmen-Kandidaten aus Reviews, ungeplante Korrekturen und Eskalationen mit der jeweils benötigten Entscheidung.

Regeln für den Lauf

• Pushen Sie niemals auf main, mergen Sie nichts selbst und genehmigen Sie keine PRs. Mergen gehört Menschen oder GitHub Auto-Merge mit --auto-merge.
• Force-Push nur mit --force-with-lease und nur auf Branches dieses Laufs (das Branch-Präfix).
• Bearbeiten Sie niemals Abnahmekriterien, markieren Sie kein Ticket als gemergt, das nicht gemergt ist, und schließen Sie keine PRs, Branches oder Tracker-Issues, die dieser Lauf nicht erstellt oder besitzt.
• Commiten Sie niemals RFCs, Notizen, Aufgaben- oder Laufprotokoll-Dateien; sie bleiben lokal.
• Nur der Benutzer ändert den Plan: Genehmigung von Splits

…

[gekürzt für die Übersetzung]