# Playbook: Ein Driver
Das Playbook für Menschen, die einen Agenten die Runs für sich aufrufen lassen wollen. Ein **Driver** ist ein Agent, der
einen Run nach dem anderen aufruft, jeden in einem eigenen Subagenten und immer autonom, und jeden Merge Request
prüft, bevor er den nächsten aufruft. Gefragt wirst du nur, wo die Entscheidung bei dir liegt.
## Was ein Driver tut
```
Projekt prüfen → Run in einem Subagenten aufrufen → seinen Merge Request prüfen → mergen, Änderungen anfordern oder dich fragen → nächster Run
```
- **Jeder Run beginnt frisch.** Ein Run in einem Subagenten hat einen eigenen Kontext, also liest der hundertste Run
den Tracker so klar wie der erste. Der Driver hält keinen Zustand, den der Tracker nicht hält: was wartet,
was im Review ist und was abgelehnt wurde, findet jeder Run dort, wie jeder Run.
- **Der Driver gibt deinen Aufruf weiter.** Ein Track („Guardrails“) oder eine Einschränkung („nur die Rector-Tools“)
geht an jeden Run, zusammen mit „mach es selbst“. Ohne Track trifft jeder Run seine eigene Track-Wahl,
Investigation eingeschlossen.
- **Er nennt ein Ticket, um mit ihm weiterzumachen:** um einen Merge Request zu überarbeiten, an dem er Änderungen angefordert hat, für den nächsten
Teil eines Tickets, das in mehreren Merge Requests bearbeitet wird (eine PHPStan-Baseline, ein Rector-Set), für eine Frage,
die du beantwortet hast, oder wenn du nach einem fragst. Er nennt nie ein Ticket, das wartet oder blockiert ist: Es zu nennen,
hieße, es unabhängig von seinem Zustand zu bearbeiten.
- **Er prüft jeden Merge Request in einem eigenen Subagenten**, mit dem Review-Skill deines Projekts, wo es
einen gibt, sonst so, wie es ein engagierter menschlicher Reviewer täte: im Umfang seines Tickets, Verhalten erhalten,
Checks grün, die Beschreibung sagt, warum die Änderung sicher ist. Ein zweiter, unabhängiger Blick findet, was der
Run übersehen hat.
- **Er mergt, was besteht**, sobald die CI grün ist (wo es keine CI gibt, führt das Review die Checks aus), mit
der Merge-Methode deines Repositorys. Wählst du stattdessen **nur Review**, kommentiert der Driver, überlässt das
Mergen dir und macht mit dem nächsten Run weiter; er pausiert, sobald mehr als drei seiner Merge Requests
offen sind.
## Wo du ins Spiel kommst
Der Driver beantwortet nie selbst eine offene Frage, und er macht mit dem nächsten Ticket weiter, während eines auf
dich wartet.
| Was auf dich wartet | Wo es steht | Was du tust |
|---|---|---|
| Eine Frage, die beim Planen aufkam | ein `Open question`-Kommentar am Ticket, vom Run gepostet | auf dem Ticket antworten; der Driver nennt es, sobald du geantwortet hast |
| Eine Frage, die der Driver zu einem Merge Request hat | ein Kommentar am Merge Request | dort antworten; der Driver mergt oder ruft einen Run auf, der ihn überarbeitet |
| Ein Merge Request, der zweimal überarbeitet wurde, ohne zu bestehen | ein Kommentar am Merge Request | wie oben |
| Eine Änderung, die ein Run in deiner `AGENTS.md` will | die Nachricht des Drivers, mit dem Wortlaut | selbst vornehmen, oder nicht |
Der Driver sagt dir von jedem davon Bescheid, sobald es passiert — über die Benachrichtigung, die deine Umgebung
hat — und schreibt nach jedem Run eine Statuszeile in die Unterhaltung. Kommentare an wartenden
Tickets lässt er bleiben: jeder Kommentar dort würde als deine Antwort zählen (siehe
[bekannte Einschränkungen](https://continuous-refactoring.de/de/docs/known-limitations.md)).
## Wie er endet
Der Driver prüft vor jedem Run, ob er einen weiteren aufruft:
- **Fertig** — ein Run findet nichts Bearbeitbares, und nichts wartet. Der Driver meldet die gemergten
Merge Requests.
- **Pausiert** — ein Run findet nichts Bearbeitbares, aber Tickets warten, sind im Review oder blockiert. Der Driver
listet jedes mit dem auf, was es von dir braucht, und hält an. Starte ihn neu, sobald du geantwortet hast.
- **Etwas ist kaputt** — ein Run ist fehlgeschlagen, der Working Tree ist nach einem Run nicht sauber, oder zwei Runs nacheinander
endeten ohne Merge Request und ohne neues wartendes Ticket. Der Driver sagt, was er gesehen hat, und hält an.
- **Dein Ende** — eine Zahl von Runs, eine Zahl gemergter Merge Requests oder eine Uhrzeit, falls du eins festlegst.
## Bevor du startest
- **Das Projekt ist onboardet.** Das Onboarding stellt dir Fragen, und ein Run in einem Subagenten kann
niemanden fragen, also ruf `/continuous-refactoring` vorher einmal selbst auf. Ein Driver, der keinen
Abschnitt `## Refactoring operations` in `docs/agents/issue-tracker.md` findet, hält an und sagt das.
- **Die Regeln deiner `AGENTS.md` gehen vor.** Wo sie von den Voreinstellungen deiner Agenten-Umgebung abweichen — kein
KI-Trailer in Commits, etwa — gibt der Driver sie an jeden Run weiter.
- **Ein Log, wenn du eins willst.** Der Driver führt eine Zeile pro Run (Runde, Ticket, Merge Request, Urteil,
was auf dich wartet) in einer Datei, die dein Repository ignoriert, etwa einem Scratch-Ordner, den dein Projekt ohnehin hat. Das
Log ist für dich; seinen Zustand liest der Driver aus dem Tracker.
## Der Prompt
Kopiere ihn in eine Session im Zielprojekt und fülle die ersten Zeilen aus. Der Prompt bleibt englisch: der Driver
schreibt alles auf der Forge auf Englisch.
```text
You are the Driver of continuous-refactoring runs on this project.
Call:
End:
Merge:
Log:
Before the first run, check that docs/agents/issue-tracker.md has a "## Refactoring operations"
section; if not, stop and ask me to run the onboarding myself. Read AGENTS.md: rules there override
your environment's defaults, and you hand them to every run.
Each round:
1. Check the end I set. Make sure the working tree is clean and the default branch checked out and
pulled.
2. Call a run in a subagent of its own (foreground): "Invoke the continuous-refactoring skill with the
call `, do it yourself` and follow it to its end. Then return its Status and Next lines
verbatim, the ticket worked, the merge request URL if any, whether the run ended because nothing was
workable, and every open ticket it found with its state (workable, waiting, in review,
blocked)." Name a ticket in the call only to rework its merge request, for its next part, for a
question I answered, or when I ask — never one that waits or is blocked.
3. Review the merge request in a second subagent that returns only a verdict — merge, request changes,
or ask the human — with its reasons. It uses the project's review skill where there is one;
otherwise it judges as an engaged human reviewer: in scope of its ticket, behaviour kept, checks
green (run them where there is no CI), the description says why the change is safe.
4. Act on the verdict:
- merge → wait for green CI where there is one, merge with the repository's merge method (with
"review only": leave the merge to me), pull the default branch, delete the merged local branch.
- request changes → post the review on the merge request, describing the problem and its cause,
then call a run naming its ticket. After two such runs without a mergeable result: ask the human.
- ask the human → post the question on the merge request and notify me; go on with the next round.
5. Post one status line here; add a line to the log, if there is one (round, ticket, merge request, verdict, what waits for me); notify me of everything that now waits for me:
open questions on tickets, your questions on merge requests, a change a run wants in AGENTS.md
(with its wording).
Never answer an open question yourself and never comment on a ticket that waits. Write everything on
the forge in English and so that it reads without this conversation.
Stop when:
- a run finds nothing workable and nothing waits → report the merged merge requests;
- a run finds nothing workable but tickets wait, are in review or are blocked → list each with what it
needs from me;
- a run failed, the tree is not clean after a run, or two runs in a row ended without a merge request
and without a new waiting ticket → say what you saw;
- with "review only", more than three of your merge requests are open;
- the end I set is reached.
```