So jagst du Issues durch — mit einem stur laufenden Coding-Loop plus Review-Gate.

Kurz, stur, effektiv. Wie Ralph.

Derselbe Prompt läuft wiederholt gegen Claude Code. Der Agent liest die offenen Issue-Files, pickt das nächste Ticket, implementiert es per TDD, committet, nächste Runde. Sieht beim nächsten Durchgang die eigenen letzten Commits und macht weiter, bis nichts mehr offen ist.

Der Name ist die Pointe: Ralph Wiggum aus den Simpsons. Dumm aber stur effektiv. Der Loop trifft keine grandiosen Entscheidungen, er pickt halt das nächste Ticket. Weil er das tausendmal hintereinander macht, ist das Feature am Ende fertig.

# once.sh — eine Iteration
issues=$(cat issues/*.md)
commits=$(git log -n 5 --format="%H%n%ad%n%B---" --date=short)
prompt=$(cat ralph/prompt.md)
claude --permission-mode acceptEdits "Previous commits: $commits Issues: $issues $prompt"

Das ist alles. In prompt.md steht: pick Issue, TDD, vor Commit alle Tests grün, fertiges Ticket nach issues/done/ verschieben. Done-State per File-Move, kein Status-Flag. Sehr clean.

Genau das ist auch sein Limit. Matt selbst sagt's im Workshop ehrlich: "I don't honestly know what the answer to this yet. We just need to be ready to be doing more code review." Der Loop produziert Code schneller als man ihn lesen kann. Bei Wegwerf-Prototypen egal — bei Software, die echte Leute nutzen sollen, ist Code-Review der Bottleneck. Genau da setzt mein Wrapper an.

So läuft mein getunter Ralph in der Praxis.

Der Loop ist nicht das ganze Projekt — er ist der Entwicklungs-Pass pro Issue. Eine Phase (bei mir z.B. "Spurwert MVP") besteht aus 15–25 Issues. Jeder Issue durchläuft den gleichen Pass. Wie die Issues vor der Phase entstehen — Strategie, PRD, Issue-Schnitt — ist eine andere Geschichte und nicht Thema hier.

Die Update-Tasklist aus der Session: sieben Schritte Ralph-Core, eingerahmt von vier Wrapper-Schritten.

Was ich anders mache und warum.

Pro Dimension einmal Standard-Ralph, einmal mein Setup, einmal Sand Castle. Damit man's wirklich vergleichen kann statt drei Listen nebeneinander lesen zu müssen.

Wave Auto im Live-Test. Sand Castle als Premium-Upgrade.

Den sequenziellen Pass aus Sektion 03 fahre ich inzwischen über mein /wave-Skill — es kapselt Branch-pro-Issue und Review-Gate, statt dass ich wrapper.sh von Hand starte. Seit dem 30. Mai 2026 ist dort der neue Modus Wave Auto der Default: statt mehrere Issues manuell sequenziell oder in parallelen Chats abzuarbeiten, läuft jetzt ein Master-Prompt in einem Chat, der N Subagenten spawnt — hands-off, mit Self-Fix-Loop und einem Compliance-Check, der pro Subagent prüft, ob PR gemerged und Report geschrieben ist.

Das Muster ist nachbaubar, auch ohne mein Skill: 1 Master-Prompt → N Subagenten, jeder bekommt genau ein file-disjunktes Issue (TDD → PR → Self-Review → Merge → kurzer Report). Der Master wartet auf alle Reports, prüft jeden gegen Ground-Truth (PR wirklich gemerged? Report wirklich da?) und fixt in einem Self-Fix-Loop nach, was rot zurückkommt. Das ist die echte Weiterentwicklung des parallelen Swarms, den ich vorher nur angedeutet hatte. Daneben gibt's /swarm als Auto-Mode und /wave parallel, wenn ich N Chats lieber selbst babysitte. Voraussetzung bleibt: file-disjunkte Issues, sonst Merge-Hölle.

Wer's als fertiges Produkt haben will: Sand Castle von Matt Pocock (v0.7.0, Mai 2026, ~5,7k Stars) ist die durchgetestete Industrie-Variante — provider-agnostisch (Docker/Podman/Vercel), Multi-Agent, Merger-Pipeline eingebaut. Aufwendigeres Setup, mehr Token-Kosten, dafür nichts selbst zu warten. Aktuell für mich nicht das richtige Verhältnis — solange ich allein baue, ist Wave Auto nah dran am Effekt ohne den Overhead. Bleibt im Auge für den Tag, an dem Issue-Menge oder Review-Last das rechtfertigen.

Stand Juni 2026 — wird hier aktualisiert, wenn sich was ändert.