autonomous-loops

Skill für Autonome Schleifen (Autonomous Loops)

Kompatibilitätshinweis (v1.8.0): autonomous-loops wird für eine Version beibehalten. Der kanonische Skill-Name ist jetzt continuous-agent-loop. Neue Anleitungen für Schleifen sollten dort verfasst werden, während dieser Skill verfügbar bleibt, um bestehende Workflows nicht zu unterbrechen.

Muster, Architekturen und Referenzimplementierungen für den autonomen Betrieb von Claude Code in Schleifen. Deckt alles ab, von einfachen claude -p-Pipelines bis hin zu vollständigen RFC-gesteuerten Multi-Agent-DAG-Orchestrierungen.

Wann verwenden

• Einrichtung autonomer Entwicklungsworkflows, die ohne menschliches Eingreifen laufen
• Auswahl der richtigen Schleifenarchitektur für Ihr Problem (einfach vs. komplex)
• Aufbau von CI/CD-ähnlichen kontinuierlichen Entwicklungspipelines
• Ausführung paralleler Agenten mit Merge-Koordination
• Implementierung von Kontextpersistenz über Schleifeniterationen hinweg
• Hinzufügen von Qualitätskontrollen und Bereinigungsschritten zu autonomen Workflows

Spektrum der Schleifenmuster

Vom Einfachsten zum Raffiniertesten:

Muster	Komplexität	Am besten geeignet für
Sequenzielle Pipeline	Niedrig	Tägliche Entwicklungsschritte, scriptgesteuerte Workflows
NanoClaw REPL	Niedrig	Interaktive persistente Sitzungen
Unendliche Agentenschleife	Mittel	Parallele Inhaltsgenerierung, spezifikationsgesteuerte Arbeit
Kontinuierliche Claude-PR-Schleife	Mittel	Mehrtägige iterative Projekte mit CI-Gates
De-Sloppify-Muster	Add-on	Qualitätsbereinigung nach jedem Implementierungsschritt
Ralphinho / RFC-gesteuerter DAG	Hoch	Große Funktionen, parallele Arbeit mehrerer Einheiten mit Merge-Queue

---

1. Sequenzielle Pipeline (claude -p)

Die einfachste Schleife. Unterteilen Sie die tägliche Entwicklung in eine Folge von nicht-interaktiven claude -p-Aufrufen. Jeder Aufruf ist ein fokussierter Schritt mit einer klaren Eingabeaufforderung.

Kern-Einsicht

Wenn Sie sich so eine Schleife nicht vorstellen können, bedeutet das, dass Sie das LLM im interaktiven Modus nicht einmal dazu bringen können, Ihren Code zu reparieren.

Das claude -p-Flag führt Claude Code nicht-interaktiv mit einer Eingabeaufforderung aus und beendet sich, wenn der Vorgang abgeschlossen ist. Verketten Sie Aufrufe, um eine Pipeline zu erstellen:

#!/bin/bash
# daily-dev.sh — Sequenzielle Pipeline für einen Feature-Branch

set -e

# Schritt 1: Funktion implementieren
claude -p "Lesen Sie die Spezifikation in docs/auth-spec.md. Implementieren Sie OAuth2-Login in src/auth/. Schreiben Sie zuerst Tests (TDD). Erstellen Sie KEINE neuen Dokumentationsdateien."

# Schritt 2: Entschlacken (Bereinigungsschritt)
claude -p "Überprüfen Sie alle Dateien, die durch den vorherigen Commit geändert wurden. Entfernen Sie unnötige Typentests, übermäßig defensive Prüfungen oder Tests von Sprachfunktionen (z. B. Tests, ob TypeScript-Generics funktionieren). Behalten Sie echte Geschäftslogiktests. Führen Sie die Testsuite nach der Bereinigung aus."

# Schritt 3: Verifizieren
claude -p "Führen Sie den vollständigen Build, Lint, Typprüfung und Testsuite aus. Beheben Sie alle Fehler. Fügen Sie keine neuen Funktionen hinzu."

# Schritt 4: Committen
claude -p "Erstellen Sie einen Conventional Commit für alle gestagten Änderungen. Verwenden Sie 'feat: add OAuth2 login flow' als Nachricht."

Wichtige Entwurfsprinzipien

1. Jeder Schritt ist isoliert — Ein neues Kontextfenster pro claude -p-Aufruf bedeutet keine Kontextübertragung zwischen den Schritten.
2. Die Reihenfolge ist wichtig — Schritte werden nacheinander ausgeführt. Jeder baut auf dem vom vorherigen Schritt hinterlassenen Dateisystemzustand auf.
3. Negative Anweisungen sind gefährlich — Sagen Sie nicht „Teste keine Typsysteme“. Fügen Sie stattdessen einen separaten Bereinigungsschritt hinzu (siehe De-Sloppify-Muster).
4. Exit-Codes werden weitergegeben — set -e stoppt die Pipeline bei einem Fehler.

Variationen

Mit Modell-Routing:

# Recherche mit Opus (tiefes Denken)
claude -p --model opus "Analysieren Sie die Codebasis-Architektur und schreiben Sie einen Plan zum Hinzufügen von Caching..."

# Implementieren mit Sonnet (schnell, leistungsfähig)
claude -p "Implementieren Sie die Caching-Ebene gemäß dem Plan in docs/caching-plan.md..."

# Überprüfung mit Opus (gründlich)
claude -p --model opus "Überprüfen Sie alle Änderungen auf Sicherheitsprobleme, Race Conditions und Grenzfälle..."

Mit Umgebungskontext:

# Kontext über Dateien übergeben, nicht über die Prompt-Länge
echo "Schwerpunkte: Auth-Modul, API-Ratenbegrenzung" > .claude-context.md
claude -p "Lesen Sie .claude-context.md für Prioritäten. Arbeiten Sie sie der Reihe nach ab."
rm .claude-context.md

Mit --allowedTools-Einschränkungen:

# Nur-Lese-Analyseschritt
claude -p --allowedTools "Read,Grep,Glob" "Überprüfen Sie diese Codebasis auf Sicherheitslücken..."

# Nur-Schreib-Implementierungsschritt
claude -p --allowedTools "Read,Write,Edit,Bash" "Implementieren Sie die Korrekturen aus security-audit.md..."

---

2. NanoClaw REPL

ECC's eingebaute persistente Schleife. Ein sitzungsbasiertes REPL, das claude -p synchron mit vollständigem Gesprächsverlauf aufruft.

# Standardsitzung starten
node scripts/claw.js

# Benannte Sitzung mit Skill-Kontext
CLAW_SESSION=my-project CLAW_SKILLS=tdd-workflow,security-review node scripts/claw.js

Wie es funktioniert

1. Lädt den Gesprächsverlauf aus ~/.claude/claw/{session}.md
2. Jede Benutzernachricht wird mit dem vollständigen Verlauf als Kontext an claude -p gesendet
3. Antworten werden an die Sitzungsdatei angehängt (Markdown-als-Datenbank)
4. Sitzungen bleiben über Neustarts hinweg erhalten

Wann NanoClaw vs. Sequenzielle Pipeline

Anwendungsfall	NanoClaw	Sequenzielle Pipeline
Interaktive Erkundung	Ja	Nein
Scriptgesteuerte Automatisierung	Nein	Ja
Sitzungspersistenz	Eingebaut	Manuell
Kontextakkumulation	Wächst pro Runde	Neu pro Schritt
CI/CD-Integration	Schlecht	Ausgezeichnet

Siehe die /claw-Befehlsdokumentation für vollständige Details.

---

3. Unendliche Agentenschleife

Ein Zwei-Prompt-System, das parallele Unteragenten für spezifikationsgesteuerte Generierung orchestriert. Entwickelt von disler (Credit: @disler).

Architektur: Zwei-Prompt-System

PROMPT 1 (Orchestrator)              PROMPT 2 (Unteragenten)
┌─────────────────────┐             ┌──────────────────────┐
│ Spezifikationsdatei   │             │ Vollständigen Kontext  │
│ analysieren           │             │ empfangen               │
│ Ausgabeverzeichnis    │  setzt ein  │ Zugewiesene Nummer     │
│ scannen               │────────────│ lesen                   │
│ Iteration planen      │  N Agenten  │ Spezifikation genau    │
│ Kreative Richtungen   │             │ befolgen               │
│ zuweisen              │             │ Einzigartige Ausgabe   │
│ Wellen verwalten      │             │ generieren             │
│                        │             │ Im Ausgabeverzeichnis  │
└─────────────────────┘             │ speichern               │
                                     └──────────────────────┘

Das Muster

1. Spezifikationsanalyse — Der Orchestrator liest eine Spezifikationsdatei (Markdown), die definiert, was generiert werden soll
2. Verzeichniserkundung — Scannt vorhandene Ausgaben, um die höchste Iterationsnummer zu finden
3. Parallele Bereitstellung — Startet N Unteragenten, jeder mit:
   • Der vollständigen Spezifikation
   • Einer einzigartigen kreativen Richtung
   • Einer bestimmten Iterationsnummer (keine Konflikte)
   • Einem Snapshot vorhandener Iterationen (für Einzigartigkeit)
4. Wellenmanagement — Für den unendlichen Modus, setzt Wellen von 3-5 Agenten ein, bis der Kontext erschöpft ist

Implementierung über Claude Code Befehle

Erstellen Sie .claude/commands/infinite.md:

Analysieren Sie die folgenden Argumente aus $ARGUMENTS:
1. spec_file — Pfad zur Spezifikations-Markdown-Datei
2. output_dir — Verzeichnis, in dem Iterationen gespeichert werden
3. count — Ganzzahl 1-N oder "unendlich"

PHASE 1: Lesen und tiefgehendes Verständnis der Spezifikation.
PHASE 2: Liste output_dir, finde höchste Iterationsnummer. Beginne bei N+1.
PHASE 3: Plane kreative Richtungen — jeder Agent erhält ein ANDERES Thema/Ansatz.
PHASE 4: Setze Unteragenten parallel ein (Task-Tool). Jeder erhält:
  - Vollständigen Spezifikationstext
  - Aktuellen Verzeichnis-Snapshot
  - Ihre zugewiesene Iterationsnummer
  - Ihre einzigartige kreative Richtung
PHASE 5 (unendlicher Modus): Schleife in Wellen von 3-5, bis der Kontext niedrig ist.

Aufruf:

/project:infinite specs/component-spec.md src/ 5
/project:infinite specs/component-spec.md src/ infinite

Batch-Strategie

Anzahl	Strategie
1-5	Alle Agenten gleichzeitig
6-20	Batches von 5
unendlich	Wellen von 3-5, fortschreitende Raffinesse

Kern-Einsicht: Einzigartigkeit durch Zuweisung

Verlassen Sie sich nicht darauf, dass Agenten sich selbst unterscheiden. Der Orchestrator weist jedem Agenten eine bestimmte kreative Richtung und Iterationsnummer zu. Dies verhindert doppelte Konzepte über parallele Agenten hinweg.

---

4. Kontinuierliche Claude-PR-Schleife

Ein produktionsreifes Shell-Skript, das Claude Code in einer kontinuierlichen Schleife ausführt, PRs erstellt, auf CI wartet und automatisch merged. Erstellt von AnandChowdhary (Credit: @AnandChowdhary).

Kern-Schleife

┌─────────────────────────────────────────────────────┐
│  KONTINUIERLICHE CLAUDE-ITERATION                   │
│                                                     │
│  1. Branch erstellen (continuous-claude/iteration-N)│
│  2. claude -p mit erweitertem Prompt ausführen      │
│  3. (Optional) Überprüfungsschritt — separater       │
│     claude -p                                       │
│  4. Änderungen committen (Claude generiert Nachricht)│
│  5. Pushen + PR erstellen (gh pr create)            │
│  6. Auf CI-Prüfungen warten (gh pr checks abfragen)│
│  7. CI-Fehler? → Auto-Korrekturschritt (claude -p)  │
│  8. PR mergen (squash/merge/rebase)                 │
│  9. Zurück zu main → wiederholen                    │
│                                                     │
│  Begrenzung durch: --max-runs N | --max-cost $X     │
│            --max-duration 2h | Abschlusssignal       │
└─────────────────────────────────────────────────────┘

Installation

Warnung: Installieren Sie continuous-claude aus seinem Repository, nachdem Sie den Code überprüft haben. Leiten Sie keine externen Skripte direkt an bash weiter.

Verwendung

# Einfach: 10 Iterationen
continuous-claude --prompt "Füge Unit-Tests für alle ungetesteten Funktionen hinzu" --max-runs 10

# Kostenbegrenzt
continuous-claude --prompt "Behebe alle Linter-Fehler" --max-cost 5.00

# Zeitlich begrenzt
continuous-claude --prompt "Verbessere die Testabdeckung" --max-duration 8h

# Mit Code-Review-Schritt
continuous-claude \
  --prompt "Füge Authentifizierungsfunktion hinzu" \
  --max-runs 10 \
  --review-prompt "Führe npm test && npm run lint aus, behebe alle Fehler"

# Parallel über Worktrees
continuous-claude --prompt "Füge Tests hinzu" --max-runs 5 --worktree tests-worker &
continuous-claude --prompt "Refaktoriere Code" --max-runs 5 --worktree refactor-worker &
wait

Cross-Iteration-Kontext: SHARED_TASK_NOTES.md

Die entscheidende Neuerung: Eine SHARED_TASK_NOTES.md-Datei bleibt über Iterationen hinweg bestehen:

## Fortschritt
- [x] Tests für Auth-Modul hinzugefügt (Iteration 1)
- [x] Randfall bei Token-Erneuerung behoben (Iteration 2)
- [ ] Noch erforderlich: Ratenbegrenzungstests, Fehlergrenztests

## Nächste Schritte
- Als nächstes auf Ratenbegrenzungsmodul konzentrieren
- Das Mock-Setup in tests/helpers.ts kann wiederverwendet werden

Claude liest diese Datei zu Beginn der Iteration und aktualisiert sie am Ende der Iteration. Dies überbrückt die Kontextlücke zwischen unabhängigen claude -p-Aufrufen.

CI-Fehlerbehebung

Wenn PR-Prüfungen fehlschlagen, führt Continuous Claude automatisch Folgendes aus:

1. Holt die fehlgeschlagene Run-ID über gh run list
2. Startet einen neuen claude -p mit CI-Korrekturkontext
3. Claude inspiziert Logs über gh run view, behebt Code, committed, pusht
4. Wartet erneut auf Prüfungen (bis zu --ci-retry-max Versuche)

Abschlusssignal

Claude kann signalisieren, dass es fertig ist, indem es einen magischen Satz ausgibt:

continuous-claude \
  --prompt "Behebe alle Fehler im Issue-Tracker" \
  --completion-signal "CONTINUOUS_CLAUDE_PROJECT_COMPLETE" \
  --completion-threshold 3  # Stoppt nach 3 aufeinanderfolgenden Signalen

Drei aufeinanderfolgende Iterationen, die den Abschluss signalisieren, stoppen die Schleife und verhindern so unnötige Läufe bei abgeschlossener Arbeit.

Wichtige Konfiguration

Flag	Zweck
--max-runs N	Stoppen nach N erfolgreichen Iterationen
--max-cost $X	Stoppen nach Ausgabe von $X
--max-duration 2h	Stoppen nach verstrichener Zeit
--merge-strategy squash	squash, merge oder rebase
--worktree <name>	Parallele Ausführung über git Worktrees
--disable-commits	Trockenlauf-Modus (keine Git-Operationen)
--review-prompt "..."	Überprüfungsschritt pro Iteration hinzufügen
--ci-retry-max N	CI-Fehler automatisch beheben (Standard: 1)

---

5. Das De-Sloppify-Muster

Ein Add-on-Muster für jede Schleife. Fügen Sie nach jedem Implementierungsschritt einen dedizierten Bereinigungs-/Refaktorisierungsschritt hinzu.

Das Problem

Wenn Sie ein LLM bitten, mit TDD zu implementieren, nimmt es „schreibe Tests“ zu wörtlich:

• Tests, die das Typsystem von TypeScript überprüfen (Testen von typeof x === 'string')
• Übermäßig defensive Laufzeitprüfungen für Dinge, die das Typsystem bereits garantiert
• Tests für Framework-Verhalten anstelle von Geschäftslogik
• Übermäßige Fehlerbehandlung, die den eigentlichen Code verschleiert

Warum keine negativen Anweisungen?

Das Hinzufügen von „teste keine Typsysteme“ oder „füge keine unnötigen Prüfungen hinzu“ zum Implementierungs-Prompt hat nachgelagerte Auswirkungen:

• Das Modell wird zögerlich bei ALLEN Tests
• Es überspringt legitime Randfalltests
• Die Qualität verschlechtert sich unvorhersehbar

Die Lösung: Separater Durchlauf

Anstatt den Implementierer einzuschränken, lassen Sie ihn gründlich sein. Fügen Sie dann einen fokussierten Bereinigungsagenten hinzu:

# Schritt 1: Implementieren (lassen Sie es gründlich sein)
claude -p "Implementieren Sie die Funktion mit vollständiger TDD. Seien Sie gründlich mit den Tests."

# Schritt 2: Entschlacken (separater Kontext, fokussierte Bereinigung)
claude -p "Überprüfen Sie alle Änderungen im Arbeitsverzeichnis. Entfernen Sie:
- Tests, die Sprach-/Framework-Verhalten anstelle von Geschäftslogik verifizieren
- Redundante Typprüfungen, die das Typsystem bereits erzwingt
- Übermäßig defensive Fehlerbehandlung für unmögliche Zustände
- Console.log-Anweisungen
- Auskommentierten Code

Behalten Sie alle Geschäftslogiktests. Führen Sie die Testsuite nach der Bereinigung aus, um sicherzustellen, dass nichts kaputt geht."

Im Schleifenkontext

for feature in "${features[@]}"; do
  # Implementieren
  claude -p "Implementieren Sie $feature mit TDD."

  # Entschlacken
  claude -p "Bereinigungsschritt: Änderungen überprüfen, Test-/Code-Überschuss entfernen, Tests ausführen."

  # Verifizieren
  claude -p "Build + Lint + Tests ausführen. Fehler beheben."

  # Committen
  claude -p "Commit mit Nachricht: feat: $feature hinzufügen"
done

Kern-Einsicht

Anstatt negative Anweisungen hinzuzufügen, die nachgelagerte Qualitätsauswirkungen haben, fügen Sie einen separaten Entschlackungs-Durchlauf hinzu. Zwei fokussierte Agenten übertreffen einen eingeschränkten Agenten.

---

6. Ralphinho / RFC-gesteuerter DAG-Orchestrierung

Das anspruchsvollste Muster. Eine RFC-gesteuerte Multi-Agent-Pipeline mit einem Merge-Queue-Mechanismus für parallele Arbeiten. Entwickelt von "ralphinho" (Credit: @ralphinho).

Das Kern-Konzept

Anstatt Befehle an Agenten zu erteilen, beginnt jeder Zyklus mit einem RFC-Dokument (Request for Comments), das definiert:

• Das Ziel der Iteration
• Die zu ändernden Dateien
• Die Architektur-/Designentscheidungen
• Abhängigkeiten zwischen Aufgaben

Dieses RFC wird dann von mehreren spezialisierten Agenten parallel umgesetzt, die über einen zentralen Merge-Queue-Mechanismus koordiniert werden.

Wie es funktioniert: DAG-Orchestrierung

┌─────────────────────────────────────────────────────────┐
│  DAG-SCHLEIFE                                            │
│                                                         │
│  1. RFC-Generierung — Claude erstellt eine               │
│     RFC-Datei, die das Ziel, die Dateien und die          │
│     Abhängigkeiten definiert                              │
│  2. Aufgabenzerlegung — RFC wird in N unabhängige         │
│     oder abhängige Aufgaben zerlegt                      │
│  3. Parallele Ausführung — Aufgaben werden an             │
│     separate Claude-Instanzen verteilt                   │
│  4. Merge-Queue — Jede abgeschlossene Aufgabe wird an      │
│     eine Merge-Queue gesendet (z. B. gh pr merge --auto) │
│  5. Abhängigkeitsauflösung — Aufgaben mit                 │
│     Abhängigkeiten warten auf Vorgänger                   │
│  6. Abschluss — Alle Aufgaben sind erledigt oder          │
│     die Schleife bricht aufgrund eines Fehlers ab         │
└─────────────────────────────────────────────────────────┘

Beispiel-RFC

## Ziel
Füge Ratenbegrenzung zur API hinzu

## Dateien
- src/middleware/rateLimiter.ts — Implementierung
- src/tests/middleware/rateLimiter.test.ts — Tests
- docs/rate-limiting.md — Dokumentation

## Architektur
Verwende ein Token-Bucket-Verfahren. Konfigurierbar über Umgebungsvariablen.

## Abhängigkeiten
- Keine (parallele Arbeit möglich)

Merge-Queue-Integration

# Jede Aufgabe erstellt einen PR mit gh pr create
# gh pr merge --auto stellt sicher, dass PRs mergen, sobald CI bestanden ist
# Ein zentraler Controller überwacht den Fortschritt

# Controller-Skript (Pseudocode)
for task in ${tasks[@]}; do
  if dependencies_resolved $task; then
    claude -p "Implementiere Aufgabe: $task" &
  fi
done
wait

Wann Ralphinho verwenden

• Große Funktionen, die mehrere Änderungen in verschiedenen Modulen erfordern
• Parallele Arbeit, die unabhängige Agenten erfordert
• Szenarien, in denen Abhängigkeiten zwischen Aufgaben bestehen (DAG)
• Teams, die CI/CD für kontinuierliche Bereitstellung verwenden

Vergleich mit anderen Mustern

Merkmal	Ralphinho (DAG)	Continuous PR Loop
Parallelität	Hoch	Niedrig (sequenziell)
Abhängigkeitsmanagement	Explizit (DAG)	Keines
Merge-Strategy	Auto-Merge-Queue	Manuell / automatisiert
Komplexität	Hoch	Mittel
Am besten für	Große Funktionen	Iterative Verbesserungen

---

Musterauswahl-Leitfaden

Ihr Bedarf	Empfohlenes Muster
Einfaches, scriptgesteuertes Setup	Sequenzielle Pipeline
Interaktive Erkundung mit Verlauf	NanoClaw REPL
Parallel Content Generation	Unendliche Agentenschleife
Produktions-PR-Workflow	Kontinuierliche Claude-PR-Schleife
Qualitätsbereinigung	De-Sloppify-Muster
Große Multi-Agent-Projekte	Ralphinho / RFC-DAG

Über diese Skill

Hinweis: Ab v1.8.0 wird diese Skill durch continuous-agent-loop ersetzt. Neue Funktionen und Anleitungen werden dort veröffentlicht. Diese Skill bleibt erhalten, um bestehende Workflows nicht zu unterbrechen.

Weitere Informationen finden Sie in der Dokumentation zu continuous-agent-loop.