/continuous-refactoring.de

Playbook: Der Driver

Das Playbook für Menschen, die wollen, dass die Suite von selbst weitermacht. /continuous-refactoring ist der Driver: Er arbeitet eine Runde nach der anderen ab, mit einem Rhythmus dazwischen, bis zu einem Ende. Gefragt wirst du nur, wo die Entscheidung bei dir liegt.

Eine Runde ist ein Run, das Review seines Merge Requests und eventuell Nacharbeit:

Projekt prüfen → ein Run in einem Subagenten → seinen Merge Request prüfen → erledigt, oder Nacharbeit → den Rhythmus abwarten → nächste Runde

Der Aufruf

Er startet, ohne zu fragen, und sagt in einem Satz zurück, was er verstanden hat. Alles hat einen Standard; sag es in eigenen Worten anders.

Einstellung Standard Du kannst sagen
Merge nur Review: er kommentiert, und du mergst mergen
Ende fünf Runden eine Anzahl Runden, gemergter Merge Requests, eine Uhrzeit, „bis nichts mehr bearbeitbar ist“
Rhythmus 30 Minuten zwischen den Runden eine andere Dauer, „keine Pause“
Aufruf keiner: Jeder Run trifft seine eigene Track-Wahl, Investigation eingeschlossen ein Track („Guardrails“), eine Einschränkung („nur die Rector-Tools“)
Log keins eine Datei, die dein Repository ignoriert, eine Zeile pro Runde. Das Log ist für dich; der Driver liest seinen Zustand aus dem Tracker

Für einen einzelnen Run, ein genanntes Ticket oder ein eigenes Pack rufst du /continuous-refactoring-run auf. Bekommt der Driver eines davon, gibt er es weiter.

Was eine Runde tut

  • 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. Er ist immer autonom, und die Regeln deiner AGENTS.md gehen mit.
  • Er nennt ein Ticket, um mit ihm weiterzumachen: um einen Merge Request zu überarbeiten, an dem er oder du Änderungen angefordert hast, für den nächsten Teil eines Tickets, das in mehreren Merge Requests bearbeitet wird, für eine Frage, die du beantwortet hast, oder wenn du darum bittest. 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.
  • Nacharbeit bleibt in der Runde. Eine Bitte um Änderungen wird am Merge Request gepostet, und ein Run beantwortet sie sofort, ohne Rhythmus dazwischen. Nach zwei Nacharbeiten ohne mergebares Ergebnis geht der Merge Request an dich. Eine Runde enthält bis zu drei Runs und zählt als eine.
  • Mit mergen wartet er auf grüne CI und nutzt die Merge-Methode deines Repositorys. Vor dem Löschen des Branchs prüft er, ob ein Merge Request darauf gestapelt ist, und dass der Merge den Inhalt des Branchs wirklich übernommen hat. Wenn nicht, hält er an: Die Korrektur ist ein gewöhnlicher Merge Request, nie ein Umschreiben der Historie.

Der Rhythmus

Er wird vom Ende der vorigen Runde an gezählt. Der Driver wartet in seiner Sitzung, wo deine Umgebung einen Timer hat. Sonst endet er und sagt, wann die nächste Runde fällig ist, und der nächste Aufruf arbeitet die nächste Runde ab. Ein kurzer Rhythmus ist alles, was eine Sitzung hält; einen längeren, etwa einmal am Tag, richtest du mit deinem eigenen Scheduler ein. Siehe bekannte Einschränkungen.

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 und erneut aufrufen
Ein Merge Request, der zweimal überarbeitet wurde, ohne zu bestehen ein Kommentar am Merge Request wie oben
Ein mergebarer Merge Request, bei nur Review ein Kommentar am Merge Request mergen, oder dort Änderungen anfordern: Die nächste Runde überarbeitet ihn
Eine Änderung, die ein Run in deiner AGENTS.md will die Nachricht des Drivers, mit dem Wortlaut selbst vornehmen, oder nicht

Er sagt dir von jedem davon Bescheid, sobald es passiert, über die Benachrichtigung, die deine Umgebung hat, und schreibt nach jeder Runde eine Statuszeile. Kommentare an wartenden Tickets lässt er in Ruhe: Jeder Kommentar dort würde als deine Antwort zählen.

Wann er endet

  • Fertig: Ein Run findet nichts Bearbeitbares, und nichts wartet.
  • Pausiert: Ein Run findet nichts Bearbeitbares, aber Tickets warten, sind im Review oder blockiert; oder, bei nur Review, sind mehr als drei Merge Requests offen. Er listet auf, was jedes braucht. Ruf erneut auf, sobald du dich darum gekümmert hast.
  • Etwas ist kaputtgegangen: Ein Run ist fehlgeschlagen, das Arbeitsverzeichnis ist nach einem Run nicht sauber, ein Merge ist nicht gelandet, oder zwei Runs in Folge endeten ohne Merge Request und ohne neues wartendes Ticket.
  • Dein Ende: standardmäßig die fünfte Runde.

Wer ihn startet

Du oder ein Zeitplan, mit seinem Namen. Ein Agent, der Refactoring erledigt haben will, ruft /continuous-refactoring-run auf; ein Driver, der in einem Subagenten gestartet wird, bricht ab und sagt das.

Der erste Aufruf

Auf einem Projekt ohne Abschnitt ## Refactoring operations stellt dir das Onboarding Fragen, und ein Run in einem Subagenten kann niemanden fragen. Also führt der erste Aufruf das Onboarding direkt in deiner Sitzung aus und hält dann an: Committe, was es geschrieben hat, und ruf erneut auf.