Continuous Claude – Workflow-Tool zur wiederholten Ausführung von Claude Code und zur Automatisierung von PR-Erstellung, Checks und Merge

• Ein CLI-Tool, um wiederkehrende mehrstufige Entwicklungsaufgaben wie bei der Umsetzung großer Projekte mit einer AI-Agent-Loop zu verarbeiten
• Ruft Claude Code per Bash-Skript fortlaufend auf und führt dabei in jeder Iteration kleine Codeänderungen aus
  • Erstellt einen neuen Branch, ändert den Code und führt anschließend automatisch Commit und Push aus
  • Erstellt über die GitHub CLI einen PR und überwacht mit gh pr checks den CI-Status sowie die Review-Ergebnisse
  • Wenn alle festgelegten Checks und Reviews bestanden sind, wird gemergt; bei Fehlschlägen wird der PR geschlossen und Branch sowie Änderungen verworfen – dieser Zyklus wird wiederholt
• Um den Kontext zwischen den Iterationen zu erhalten, wird eine gemeinsam genutzte Markdown-Datei wie SHARED_TASK_NOTES.md als externer Speicher verwendet
  • Fasst in jeder Iteration zusammen, was erledigt wurde und was als Nächstes ansteht, und dokumentiert dies im Stil eines „Staffellaufs“
  • Beispiel: Wird eine Notiz wie „In Funktion Y muss null-Eingabe behandelt werden“ hinterlassen, priorisiert die nächste Iteration dies und bildet so eine selbstverbessernde Schleife
  • Statt unnötig langer Logs sind die Prompts so gestaltet, dass ein Handover-Paket entsteht, das spätere Entwickler und Agenten sofort verstehen können
• Bietet eine vollständig automatisierte Pipeline, die den gesamten PR-Lifecycle abdeckt
  • Branch-Erstellung → Ausführung von Claude Code → Commit → PR-Erstellung → Warten auf CI und Reviews → bei Erfolg Merge → Aktualisierung des Main-Branches → Aufräumen und nächste Iteration
  • Nutzt bestehende Code-Owner-Regeln, Pflicht-Checks und Preview-Umgebungen eines Repos unverändert weiter und bindet menschliche Reviews natürlich in den Workflow ein
• Mit verschiedenen Flags zur Ausführungssteuerung lassen sich Kosten, Zeit und Anzahl der Versuche begrenzen
  • Mit --max-runs wird die maximale Zahl der Iterationen festgelegt; bei 0 läuft eine Endlosschleife
  • Mit --max-cost lässt sich eine Kostenobergrenze in US-Dollar setzen, mit --max-duration ein Zeitlimit wie 2h oder 30m
  • Mehrere Angaben können kombiniert werden, um zusammengesetzte Bedingungen wie „höchstens 10 Durchläufe, höchstens 5 Dollar, höchstens 1 Stunde“ zu definieren
• Unterstützt über Integrationsoptionen mit GitHub auch eine feinere Steuerung von Branch-Strategie und Repository-Struktur
  • Mit --merge-strategy kann zwischen squash / merge / rebase gewählt werden
  • Mit --git-branch-prefix lässt sich die Branch-Benennungsregel festlegen, etwa feature/ statt continuous-claude/
  • Mit den Flags --owner und --repo kann ein Repository explizit angegeben werden, auch wenn das Remote nicht GitHub ist oder sich nicht automatisch erkennen lässt
• Die Art der Kontextspeicherung und die Abbruchbedingungen lassen sich anpassen
  • Mit --notes-file kann statt SHARED_TASK_NOTES.md ein anderer Dateiname verwendet werden
  • Über --completion-signal und --completion-threshold ist ein vorzeitiger Abbruch möglich, wenn Agenten die Formulierung „Projekt abgeschlossen“ eine bestimmte Anzahl von Malen ausgeben
• Enthält Safe Mode- und Dry-Run-Funktionen für Tests, Debugging und Experimente
  • Mit --disable-commits werden echte Commits, PR-Erstellung und Merge deaktiviert, sodass sich nur lokale Änderungen testen lassen
  • Mit --dry-run wird der gesamte Ablauf simuliert, und im Log ist sichtbar, welche Befehle ausgeführt würden
• Unterstützt mithilfe von git worktree eine Struktur, um mehrere Aufgaben parallel laufen zu lassen
  • Mit --worktree <name> und --worktree-base-dir werden unabhängige Worktrees erzeugt, damit etwa Tests und Dokumentationsarbeit in verschiedenen Verzeichnissen gleichzeitig laufen können
  • Mit --cleanup-worktree lässt sich ein Worktree nach Abschluss aufräumen, und mit --list-worktrees können aktuell aktive Worktrees angezeigt werden
• Erfordert als Abhängigkeiten Claude Code CLI, GitHub CLI und jq; mit einem einfachen Installationsskript lässt sich die Umgebung schnell einrichten
  • Über ein Einzeilen-Installationsskript kann continuous-claude zur Nutzung in ~/.local/bin oder /usr/local/bin installiert werden
• Praktische Einsatzszenarien: geeignet für stark wiederkehrende Aufgaben wie Ausbau der Testabdeckung, große Refactorings oder automatisches Reparieren von Code nach Dependency-Updates
  • Während Dependabot nur Versionsupdates behandelt, erstellt dieses Tool auf Basis von Release Notes und fehlgeschlagenen Tests auch nachgelagerte Fix-PRs automatisch – wie eine „verstärkte Dependabot-Version“
  • Kann auch für Langläufer-Aufgaben genutzt werden, bei denen mehr als 20 PRs nacheinander erstellt und gemergt werden, etwa beim Aufteilen einer monolithischen Codebasis in mehrere Module oder beim Umstellen von Callbacks auf async/await
• Das Konzept ähnelt der Continuous AI·agentics-Forschung von GitHub Next und ist auch für die gleichzeitige Nutzung mehrerer spezialisierter Agenten ausgelegt
  • Unterstützt Muster, bei denen Agenten mit unterschiedlichen Rollen – etwa für Tests, Refactoring oder Feature-Erweiterungen – parallel laufen und mehrere Bereiche eines Monorepos gleichzeitig voranbringen
  • Selbst wenn einzelne Ausführungen scheitern, lassen sich Experimente mit einer iterativen, Verschwendung tolerierenden Strategie durchführen, die auf einer „Wahrscheinlichkeitsverteilung mit korrekter Richtung“ und sinkenden Kosten basiert
• Insgesamt ist es ein Tool, das die PR-basierte Arbeitsweise menschlicher Entwickler beibehält, während eine Agenten-Schicht für AI die wiederkehrenden Aufgaben und Restarbeiten übernimmt und sich direkt in reale Arbeits-Repositories integrieren lässt

[crawler]

War der teuerste Tarif von Claude Code nicht 100 $?
Das ist wohl ein Programm, um das Maximum daraus herauszusaugen.

[cjinzy]

Es kostet 200 Dollar.

Die Nutzung wird jede Woche zurückgesetzt, daher überlege ich, es vor dem Reset einmal auszuprobieren.

[shakespeares]

Es scheint, als würde eine solche Automatisierung die Entwicklung weiter beschleunigen, sodass gar kein Mensch mehr eingebunden sein muss. Bei Projekten, die auch bei häufigen Änderungen und Deployments unproblematisch sind, mag das egal sein, aber gerade bei Tests zwischendurch gibt es doch sicher Punkte, die von Menschen geprüft werden müssen – ich frage mich, wie Sie das lösen.