assemble (DigiAye/agent-skills)

assemble

Vier Modelle, eine Antwort, viele Runden. Jeder Zug liest die aktuelle beste Antwort, kritisiert sie aus einer bestimmten Rolle und schreibt eine verbesserte Version. Der Fortschritt lebt in Dateien, nicht im Gesprächsverlauf, sodass jeder Zug mit frischem Kontext beginnt (die Ralph-Wiggum-Technik).

Befehle

Befehl	Aktion
assemble <aufgabe>	Startet einen Lauf mit dem Standardplan (36 Züge).
assemble --quick <aufgabe>	Ein Block mit 2 Durchgängen x 4 Modelle (8 Züge).
assemble resume [<slug>]	Setzt den letzten (oder benannten) unfertigen Lauf fort.
assemble cancel [<slug>]	Setzt status: cancelled in der Zustandsdatei und stoppt.
assemble status	Zeigt Iteration, Block, offene MUST-Punkte und verwendete Modelle an.

Vor dem Start

1. .assemble/config.json laden, falls vorhanden, sonst assets/config.example.json.
2. Den Modelladapter (siehe unten) auswählen und dem Benutzer mitteilen, welche vier Modelle laufen werden und wohin der Aufgabentext gesendet wird. Falls ein Modell nicht in allowedModels enthalten ist oder localOnly true ist und ein Modell remote ist, dieses entfernen und Bescheid geben.
3. Die Aufgabe und die Akzeptanzkriterien in einem kurzen Absatz wiederholen. Falls die Aufgabe unklar ist, den Benutzer vor dem Start von Runden fragen.
4. .assemble/<slug>/ mit task.md, answer.md (leer) und state.md erstellen, wie in references/state-format.md beschrieben. Sicherstellen, dass .assemble/ in .gitignore steht.

Der Zeitplan

Ein Zug ist eine Modellrunde. Ein Durchgang umfasst alle vier Modelle, die nacheinander je einen Zug machen.

Block	Durchgänge	Züge	Gesamtsumme
1	4	16	16
2	3	12	28
3	2	8	36

Nach Zug 36 den Bericht anzeigen und den Benutzer fragen, ob ein weiterer Block laufen soll. Niemals ohne Nachfrage über 36 hinausgehen.

Die Rollen rotieren in jedem Durchgang, sodass jedes Modell jede Rolle spielt: in Durchgang p (0-basiert) spielt Modell m die Rolle roles[(m + p) % 4] aus references/roles.md.

Jeder Zug

Den Zug-Prompt nur aus Dateien erstellen, unter Verwendung von references/handoff-format.md:

• task.md
• die aktuelle answer.md
• die Kritik des vorherigen Zuges (aus der neuesten round-NN.md)
• die Rollenkarte für diesen Zug

Frühere Runden nicht einbeziehen und nicht sagen, welches Modell die aktuelle Antwort geschrieben hat. Dann:

1. Den Prompt mit dem gewählten Adapter an das Modell für diesen Zug senden.
2. Die Antwort in eine Kritik (jeder Punkt mit MUST oder NICE gekennzeichnet), eine überarbeitete Antwort und ein Urteil parsen.
3. Falls die Aufgabe Code ist und checks konfiguriert sind, die überarbeitete Antwort in einer temporären Kopie anwenden, die Prüfungen ausführen und alle Fehlschläge als MUST-Punkte zur Kritik hinzufügen.
4. round-NN.md schreiben (Rolle, Modell-ID, Kritik, Prüfergebnisse, Urteil, Zeilen-Diff-Größe) und answer.md mit der überarbeiteten Antwort überschreiben.
5. state.md aktualisieren: Iteration, Block, Durchgang, Anzahl offener MUST-Punkte und die Serie ohne Änderungen.
6. Dem Benutzer eine einzeilige Fortschrittsnotiz geben: Runde 7/36 · Skeptiker · 2 MUST, 1 NICE · Diff 14 Zeilen.

Falls ein Modell einen Fehler meldet oder eine Zeitüberschreitung auftritt, in round-NN.md protokollieren, den Zug überspringen und fortfahren. Falls zwei Modelle hintereinander ausfallen, anhalten und den Benutzer informieren.

Stoppen

Ein Zug gilt als keine Änderung, wenn er keine MUST-Punkte erhebt und weniger als noChangeLines Zeilen in answer.md ändert.

Vorzeitig stoppen, wenn:

• vier Züge in Folge (ein voller Durchgang) keine Änderung sind, oder
• ein Zug mit <promise>CONVERGED</promise> endet und der nächste Zug dies ohne MUST-Punkte bestätigt.

Falls die Anzahl offener MUST-Punkte einen ganzen Block lang nicht gesunken ist, stoppen und eine kurze „festgefahren“-Notiz schreiben: Was blockiert, was versucht wurde und welche Entscheidung der Benutzer treffen könnte, um die Blockade zu lösen.

Bericht

Wenn der Lauf endet, .assemble/<slug>/report.md schreiben und anzeigen:

• die endgültige Antwort
• durchgeführte Runden und Grund für das Stoppen
• die wichtigsten Änderungen in jedem Block
• alle offenen NICE-Punkte
• verwendete Modelle mit Fehlern
• eine grobe Token- und Kostenschätzung (Summe der Prompt- und Antwortgrößen, multipliziert mit Preisen aus der Konfiguration, falls vorhanden)

Modelladapter

Den ersten verfügbaren verwenden und dem Benutzer mitteilen, welcher ausgewählt wurde.

1. Tool-interne Subagenten. Falls der Host Subagenten starten und deren Modell auswählen kann, einen pro Zug verwenden. Cursor kann Anbieter mischen. Claude Code und Kiro bieten hier nur Claude-Modelle an, daher sind die vier Claude-Varianten.
2. Anbieter-CLIs. scripts/run-model.sh <modell-id> <prompt-datei> einmal pro Zug ausführen. Dies ist die echte Multi-Anbieter-Option. Vor dem Start prüfen, ob jede CLI existiert (command -v).
3. Einzelnes Modell. Jeden Zug selbst ausführen, wobei die Rolle für diesen Zug gespielt wird. Nur die Dateien des Zuges lesen und jeden Zug als Neustart behandeln.

Optionale toolspezifische Helfer, z. B. ein Claude-Code-Stopp-Hook für unbeaufsichtigte Läufe, befinden sich im adapters/-Ordner des Repos.