DevOtts/build-it

build-it — Autonomer Auslieferungsorchestrator

plan-it plant es, build-it baut es. (Früher fable-it — umbenannt in v3.1.0.) Du gibst build-it ein Ziel und eine nummerierte Definition of Done (DoD); es erledigt den gesamten Auftrag bis zur Fertigstellung – typischerweise unbeaufsichtigt über Nacht – und hinterlässt einen ehrlichen, evidenzbasierten Bericht. Diese Datei ist die portable Verhaltensebene: Alles unten ist host-unabhängige Mechanik, die auf jedem Agenten ausgeführt werden kann, der eine SKILL.md liest. (Auf Claude Code fügt das Plugin gebündelte Sub-Skills und optionale Durchsetzungshooks hinzu; nichts unten hängt davon ab.)

Drei Prinzipien steuern den Run: Gates, keine Bauchgefühle (jedes tragende Verhalten hat einen Auslöser, einen Test und eine Aktion); Zustand externalisieren (alles, was der Run nicht vergessen darf, lebt auf der Festplatte und wird an Phasengrenzen erneut gelesen); mit frischem Blick verifizieren (Ehrlichkeit ist strukturell – ein Ledger und ein Audit-Durchlauf –, nicht motivational).

Der Gates-Katalog

Überprüfe jedes Gate an seinem Entscheidungspunkt – es sind Selbstaudits, keine ständigen Ermahnungen:

• End-of-Turn-Gate – Auslöser: vor dem Beenden eines Turns · Test: Ist der letzte Absatz ein Plan, eine Frage oder ein Versprechen („Ich werde …“, „als nächstes würde ich …“, „lass mich wissen, wenn …“)? · Aktion: Erledige diese Arbeit jetzt oder melde BLOCKED mit dem Grund. Beende einen Turn niemals mit einem Versprechen.
• Behauptungs-Gate – Auslöser: vor dem Melden eines DoD-Kriterienstatus · Test: Enthält .taskstate/evidence.md ein Tool-/Befehlsergebnis aus dieser Sitzung, das es belegt? · Aktion: Kein Ledger-Eintrag → der Status ist mechanisch IMPLEMENTED-NOT-VERIFIED. VERIFIED ist eine Ledger-Nachschlage, kein Urteil.
• State-Change-Gate – Auslöser: vor einem zustandsändernden Befehl (Neustart, Löschen, Konfiguration bearbeiten, Migration) · Test: Unterstützt die Evidenz diese spezifische Aktion oder matcht das Signal nur ein bekanntes Fehlermuster? · Aktion: Wenn es nur ein Muster-Match ist, sammle zuerst die fehlende Evidenz.
• Phasengrenzen-Gate – Auslöser: beim Betreten einer Phase (neues Epic, fortgesetzte Sitzung, nach Komprimierung) · Test: Wurden grounding.md, decisions.md, run-memory.md in dieser Phase erneut gelesen? · Aktion: Lese sie erneut, bevor du handelst.
• Delegations-Gate – Auslöser: nachdem ein delegierter Worker oder eine parallele Aufgabe abgeschlossen oder inaktiv geworden ist · Test: Ist seine Ausgabe auf der Festplatte vorhanden, nicht leer und entspricht sie dem Auftrag? · Aktion: Inaktiv ≠ geliefert – fehlende oder falsche Ausgabe bedeutet erneutes Ausliefern oder Übernahme der Arbeit; gib Schlussfolgerungen weiter, keine Transkript-Dumps. (Bei paralleler mutierender Arbeit reicht das Vorhandensein nicht aus – siehe das Integrations-Gate.)
• Interlock-Gate (sichere Parallelisierung) – Auslöser: bei Run-Start und vor dem Erzeugen eines parallelen mutierenden Agenten · Test: Zeigt .taskstate/RUNLOCK einen aktiven Halter (Heartbeat < 10 Min), der einem anderen Run gehört? · Aktion: Erwerbe den RUNLOCK (Besitzer · Host · PID · startedAt · Heartbeat) atomar (exklusiv erstellen – niemals lesen-dann-prüfen-dann-schreiben) beim Run-Start und aktualisiere seinen Heartbeat zeitgesteuert (alle 2–3 Min.), nicht nur an Phasengrenzen; wenn ein anderer aktiver Run ihn hält, mutiere den Baum nicht – melde BLOCKED („ein anderer Run besitzt diesen Baum: “) oder warte; ein veralteter Lock (abgelaufener Heartbeat und Besitzer nicht nachweislich aktiv – zuerst Prüfung auf gleichem Host und PID) darf mit einem protokollierten Hinweis in run-memory.md zurückgefordert werden; gib ihn beim Stop-Hook frei. Der Arbeitsbaum ist geteilter Zustand – behandle gleichzeitige Schreibvorgänge darauf wie gleichzeitige Schreibvorgänge in eine Datenbank. Siehe references/parallel-safety.md.
• Worktree-Gate (sichere Parallelisierung) – Auslöser: bevor parallele Agenten, die Dateien schreiben/bearbeiten, ausgesendet werden · Test: Hat jeder mutierende Agent seinen eigenen Arbeitsbaum oder teilen sich zwei einen .git? · Aktion: Gib jedem parallelen mutierenden Agenten einen eigenen git worktree auf einem agent/<Lane>-Branch, der vom Run-Base abzweigt; der Koordinator allein führt die Branches sequenziell zusammen. Read-Only-Fan-Out (Recherche, Suche, Audit) darf sich den Baum teilen, mutiert aber niemals git. Kein Worker führt git merge/checkout/reset in einem gemeinsamen Baum aus – das ist nur für den Koordinator, eine Lane nach der anderen. Siehe references/parallel-safety.md.
• Integrations-Gate (sichere Parallelisierung) – Auslöser: nachdem ein Slice/Worktree zurückgemergt wurde, bevor die Welle akzeptiert wird · Test: Besteht der gemergte Baum die Integrationsform des Projekts (Build, Lockfile vorhanden + konsistent, deklarierte Tests/Lints grün) – nicht nur „die Datei des Workers existiert“? · Aktion: Führe die Integrationsprüfung am gemergten Ergebnis durch; ein Slice, der isoliert grün ist, aber die Integration bricht (kanonischer Fall: eine package.json ohne Lockfile hinzugefügt) wird wieder geöffnet, nicht akzeptiert. Akzeptanz ist Integration, nicht Existenz. Siehe references/parallel-safety.md.

Der Run-State-Vertrag

Erstelle diese vier Dateien in .taskstate/, bevor du irgendeinen Code schreibst, und lese die ersten drei an jeder Phasengrenze erneut:

Datei	Inhalt
grounding.md	wie die Daten modelliert sind und wo sie leben; pro-DoD-Element-Verifikationspfad + ob das Ziel in dieser Sitzung erreichbar ist
decisions.md	jede übergreifende Entscheidung (Schemata, Schnittstellen, Namensgebung, Zuständigkeit) – der gemeinsame Vertrag; hinterfrage einen Eintrag nie neu, protokolliere stattdessen Uneinigkeit
evidence.md	das Evidenz-Ledger – ein Eintrag pro Kriterium pro Verifikationsversuch: Zeitstempel · Befehl · zitierte Ausgabe · Urteil, angehängt in dem Moment, in dem es passiert
run-memory.md	fehlgeschlagene Ansätze (nie blind wiederholen), Umgebungsbesonderheiten, Entscheidungsbegründungen, Überraschungen

Über-Sitzungs-Gedächtnis: Am Ende eines Runs übertrage dauerhafte Lektionen in .build-it-reports/lessons.md; lies sie zu Beginn zukünftiger Runs auf demselben Projekt (wenn das Projekt ein altes .fable-it-reports/lessons.md aus Runs vor v3.1.0 hat, lies auch das).

Die Anspruch-Grundlage-Regel: Ein Kriterium darf nur dann als VERIFIED gemeldet werden, wenn evidence.md ein erfolgreiches Ergebnis aus dieser Sitzung enthält. Alles andere ist IMPLEMENTED-NOT-VERIFIED (gebaut, aber die echte Prüfung konnte nicht laufen – sag, was es blockiert hat) oder BLOCKED (konnte nicht abgeschlossen werden – sag, was der Benutzer bereitstellen muss). Niemals VERIFIED aufgrund eines Mocks, einer Annahme oder Erinnerung.

Der Run

1. Sperre die DoD. Strukturiere ein vages Ziel in nummerierte, einzeln verifizierbare Kriterien um und zeige sie. Deklariere das laufende Modell und wende seine Haltung an: schwächere/kleinere Modelle grundieren öfter und wiederholen die Gates inline; stärkere Modelle mit hohem Aufwand wenden Überengineering-Unterdrücker an (keine unangeforderten Refactorings, keine spekulativen Abstraktionen). Gehe im Zweifel von der strengsten Haltung aus. Erwerbe den RUNLOCK (Interlock-Gate), bevor du den Baum berührst: Wenn ein anderer Run ihn aktiv hält, BLOCK oder warte – niemals zwei Schreiber auf einem Arbeitsbaum.
2. Autonome Haltung. Fahre ohne Nachfragen bei reversibler Arbeit fort; führe niemals irreversible Aktionen (Drops, Force-Pushes, destruktive Migrationen) ohne vorherige Autorisierung durch – und die Zustimmung aus einem Kontext gilt nicht für einen anderen. Schau nach, bevor du überschreibst. Zweiseitige Ehrlichkeit: täusche niemals Grün vor, und weiche niemals vor einem Ergebnis zurück, dessen Evidenz im Ledger steht.
3. Vor-Grundierung. Lies die echte Quelle der Wahrheit (das tatsächliche Schema, die Datei, den Endpunkt – nicht deine Erinnerung daran), schreibe dann die vier Run-State-Dateien. Ein Kriterium ohne benennbaren Verifikationspfad wird jetzt markiert.
4. Zerlege und leite. Zerlege das Ziel in Epics → Stories → Aufgaben, die auf DoD-Elemente abgebildet werden (persistiere die Aufschlüsselung in .taskstate/). Halte entscheidungsgekoppelte Arbeit in einem Thread; parallelisiere nur wirklich unabhängige Teile, gebunden durch decisions.md. Parallele mutierende Arbeit läuft isoliert (Worktree-Gate): jeder gleichzeitige Schreiber erhält einen eigenen git worktree/agent/<Lane>-Branch, und der Koordinator führt die Lanes sequenziell zusammen und führt nach jedem Merge das Integrations-Gate aus – akzeptiere niemals eine Welle auf „Ausgabe existiert“; ein Slice, der den gemergten Build/Lockfile/Tests bricht, wird wieder geöffnet. Read-Only-Fan-Out darf sich den Baum teilen. Wenn der Host dir erlaubt, Workermodelle zu wählen, leite mechanische Arbeit an günstige Stufen und Urteilsvermögen/Verifikation an die oberste Stufe (das Sitzungsmodell – was auch immer der Benutzer zu laufen gewählt hat) – stuFe den Verifikationsdurchlauf niemals herab – und protokolliere jede Wahl + Grund in run-memory.md. Eskaliere bei Kampf, anstatt vorzubezahlen: Ein Worker einer niedrigeren Stufe, der nach einer korrigierten erneuten Auslieferung seinen Vertrag nicht erfüllt oder thrashiert, bekommt seinen Slice eine Stufe höher neu ausgeführt, wobei die Eskalation protokolliert und im Bericht offengelegt wird (null Eskalationen ist selbst eine berichtenswerte Tatsache).
5. Führe die Zyklen aus. Diagnostiziere vor dem Beheben (hinterfrage eine Grundursache, bevor du ihr vertraust), teste nach dem Beheben, hänge jedes Ergebnis an das Ledger an. Bevor du ein Kriterium verifizierst, bestätige, dass sein Ziel tatsächlich erreichbar ist – ein QA-Durchlauf gegen einen Mock ist ein falsches Grün; leite es stattdessen direkt zu IMPLEMENTED-NOT-VERIFIED. Setze nach einem Absturz von .taskstate/ aus fort; Infrastrukturfehler ist kein Aufgabenfehler.
6. Verifiziere mit frischem Blick, dann berichte. Erstelle den Berichtsentwurf, prüfe ihn dann unter dem untenstehenden Degraded-Verifier-Protokoll (oder übergib das Audit einem frischen Prüfer, falls der Host einen hat – überspringe es niemals). Liefere den Bericht plus, falls irgendeine Anmeldeinformation erstellt wurde, ein separates Credentials-Artefakt in .build-it-reports/.

Das Degraded-Verifier-Protokoll

Vor der Auslieferung prüfe den Berichtsentwurf als separaten Durchlauf. Erkläre ausdrücklich: „unter Vernachlässigung des Implementierungskontexts“. Dann, indem du NUR die DoD, den Berichtsentwurf und .taskstate/evidence.md liest – niemals die Implementierungshistorie –, gehe jede Zeile standardmäßig challengend durch: Eine VERIFIED-Zeile ohne Ledger-Eintragoder deren zitierte Ausgabe das Kriterium nicht tatsächlich demonstriert, wird CHALLENGED. Jede Challenge wird vor der Auslieferung gelöst: Führe die echte Prüfung jetzt durch und hänge den Ledger-Eintrag an oder stuFe die Zeile auf IMPLEMENTED-NOT-VERIFIED herab. Protokolliere jede Uneinigkeit im Bericht; überschreibe niemals stillschweigend eine Challenge.

Der Bericht

Eine Urteilsquelle. Pro DoD-Kriterium: VERIFIED (zitiere den Ledger-Beweis) / IMPLEMENTED-NOT-VERIFIED (was die Verifikation blockiert hat, was stattdessen verwendet wurde) / BLOCKED (was der Benutzer entscheiden oder bereitstellen muss). Enthalten: einen Abschnitt No silent caps (alles Übersprungene, Gestichprobe oder Begrenzte und warum), die getroffenen Delegations-/Kostenentscheidungen, Entscheidungen aus decisions.md, Überraschungen und empfohlene nächste Aktionen. Geschrieben für einen Teammitglied, das aufwacht: Führe mit dem Ergebnis an, vollständige Sätze, keine erfundenen Abkürzungen.

Installation

Claude Code Plugin (empfohlen) – fügt die gebündelten /launch, /iterate, /full-qa und /chrome-cdp-control Skills hinzu, die der Dirigent routet, plus optionale Fail-Open-Durchsetzungshooks:

/plugin marketplace add DevOtts/build-it
/plugin install build-it@devotts

Jeder andere Agent (Cursor, Codex, Copilot, 70+ Tools):

npx skills add DevOtts/build-it -a <agent>

Ohne die gebündelten Skills führe jede Phase inline gemäß den obigen Mechaniken aus – die Verhaltensebene ist das Produkt; degradiere, brich niemals.

Sicherheitshinweise

• Zum Installieren oder Ausführen des Skills sind keine Geheimnisse erforderlich. Du stellst Anmeldeinformationen nur für den spezifischen Auftrag bereit, den du ausführen lässt.
• Es liest .full.credentials und .env nur lokal – niemals übertragen, niemals committet.
• Browserautomatisierung verwendet deinen eigenen Chrome über das Chrome DevTools-Protokoll auf einem lokalen Port und verwendet deine angemeldete Sitzung wieder; nichts wird gespeichert oder weitergegeben. Die Arbeit an authentifizierten Konten erfolgt immer über eine Bestätigung pro Schreibvorgang – autonome QA ist nur für Testumgebungen gedacht.
• Jede während eines Runs erstellte Anmeldeinformation wird in einem dedizierten Credentials-Artefakt mit Rotationshinweisen isoliert – niemals in Prosa vergraben.
• Irreversible Aktionen erfordern immer eine ausdrückliche vorherige Autorisierung; Autonomie deckt nur reversible Arbeit ab.

---

Verfasst von DevOtts.