claude-shiploop: Ein wiederholbarer Workflow für Softwareprojekte mit Claude

Veröffentlicht am 23. Oktober • Ursprünglich erschienen auf hrekov.dev

Jede Fallstudie auf dieser Website durchläuft denselben Kreislauf: die Anfrage klassifizieren, die Spezifikation schreiben, nach der Spezifikation bauen, das Ergebnis messen, das bewahren, was sich wiederholt, und vergessen, was sich nicht bewährt. Dieser Kreislauf trug den Arbeitstitel ShipLoop, ein einseitiges Protokoll in der CLAUDE.md, fünf Skills in.claude/skills/ und eine Scorecard, die Commits, DEVLOG-Überschriften und Sitzungsprotokolle auswertet, um zu messen, wie oft jedes Projekt dem Kreislauf tatsächlich gefolgt ist.

Heute ist das gesamte Projekt Open Source. Mit einer einzigen Zeile lässt es sich in jedes Claude-Code-Projekt installieren, an dem man arbeitet:

curl -sSL https://raw.githubusercontent.com/ruslan4427/claude-shiploop/main/install.sh | bash

Repository: github.com/ruslan4427/claude-shiploop. MIT-Lizenz, keine Registrierung, keine Telemetrie.

Sauberen Code mit Claude zu schreiben ist nicht mehr die eigentliche Schwierigkeit, denn die Modelle sind stark genug, um ein Feature zu tragen, wenn man sie gut anleitet. Schwierig ist die umgebende Disziplin: die Anfrage abzufangen, die eine schnelle Frage bleiben sollte, bevor sie sich in ein Refactoring über vier Dateien verwandelt, ein Dreiklang aus Spezifikation, Plan und Aufgaben zu pflegen, damit das Modell nicht abdriftet, und zu messen, ob das Ergebnis tatsächlich ausgeliefert wurde oder sich nur so anfühlte.

Jedes Projekt, in dem ich diese Disziplin irgendwann etabliert hatte, sah nach drei Monaten gleich aus: eine CLAUDE.md, ein DEVLOG, ein Klassifikator für eingehende Anfragen und ein Kreislauf, der Erkenntnisse in dauerhafte Regeln überführte. Und jedes Projekt, in dem ich sie nicht etabliert hatte, sah nach drei Monaten ebenfalls gleich aus: mehr verbrannte Tokens, mehr Nacharbeit, Fälle, in denen das Modell ein Feature schrieb, das ich bereits gestrichen hatte.

Das Ziel von claude-shiploop ist es, die langsame Schleiferei zu überspringen. Die Disziplin klonen, sich selbst messen und alles löschen, was nicht passt.

Drei Bestandteile, jeder für sich allein nutzbar:

Das Protokoll, ein Anfrage-Klassifikator mit neun Kategorien (Q, B, S, L, R, T, D, M, O, E) plus eine Spezifikations-, Plan- und Aufgabenschwelle für alles, was über der Größe eines kleinen Features liegt. Es liegt in der CLAUDE.md und ist in etwa zwei Minuten gelesen. Wenn man sich nur ein Teil davon ausleiht, dann dieses.

Die Skills, fünf Slash-Befehle als Einstiegspunkte ( /shiploop-start, /shiploop-router, /shiploop-brainstorm, /shiploop-tester, /shiploop-observer ), die in.claude/skills/ liegen. Jeder davon ist eine Markdown-Datei, nichts wird kompiliert. Man kann sie direkt vor Ort bearbeiten, ohne irgendetwas neu bauen zu müssen.

Die Scorecard, ein Node-Parser, der die Commits, DEVLOG-Einträge, Sitzungsprotokolle und die Git-Historie eines Projekts liest und fünf Metriken pro Projekt ausgibt: Disziplin (wie viele Features den Weg über Spezifikation, Plan und Aufgaben nahmen), Nacharbeitsquote (revertierte oder geänderte Zeilen geteilt durch gemergte Zeilen), Zeit bis zur Auslieferung, Kosten pro ausgeliefertem Feature und Tokens pro Auslieferung. Alle fünf Metriken sind ausdrücklich nullable. Fehlen die Daten, bleibt die Metrik null und wird nicht geschätzt.

Die eine Regel, die die gesamte Scorecard zusammenhält: Wenn ein Projekt älter ist als die projektspezifische Sitzungsisolierung oder die DEVLOG-Disziplin noch nicht etabliert hat, liefert die Metrik einen Strich zurück und keine Zahl, die aus der Luft gegriffen ist.

Drei meiner sieben Projekte führen in der Tokens-Spalte einen Strich. Das ist derzeit auf /tools sichtbar. Die Scorecard weigert sich, Zahlen zu erfinden, die die Methodik stärker aussehen lassen, als sie ist, denn sobald das erste null zu „geschätzt 15k Tokens“ abgemildert wird, verliert die gesamte Tabelle ihre Glaubwürdigkeit.

Die Dreistufen-Zuweisung (naked / self-spec / shiploop) ist eine menschliche Entscheidung, die pro Projekt auf /tools dokumentiert ist. Sie wird nicht automatisch erkannt und gibt auch nicht vor, es zu sein, denn es handelt sich um eine Einschätzung, welche Methodik tatsächlich zum Einsatz kam, und nicht um eine Zählung.

Manche Zeilen erhalten Zahlen. Manche erhalten einen Gedankenstrich. Der Strich leistet mehr Arbeit als die Zahlen, denn er ist das Versprechen, dass die Tabelle nicht schöngerechnet wurde.

Über die sieben Projekte, die ich über diese Website ausgeliefert habe, haben sich zwei Muster bewährt:

Die Disziplin-Spalte ist das Fundament für alles andere. Projekte, die den Weg über Spezifikation, Plan und Aufgaben nahmen, hatten Nacharbeitsquoten zwischen 0,2 und 0,6; Projekte ohne diese Disziplin lagen zwischen 2,0 und 4,5. Das Verhältnis dieser Quoten, etwa zehnmal weniger Nacharbeit, wenn die Disziplin vorhanden ist, hielt sich über verschiedene Projektgrößen, Sprachen und Kundentypen hinweg.

Die Spalte für die Zeit bis zur Auslieferung entwickelte sich entgegen meiner Erwartung. Projekte, die in der Spezifikationsphase länger verweilten, lieferten früher aus als Projekte, die am ersten Tag mit dem Codieren begannen. Die Zeit für die Spezifikation war im Sinne von „ich arbeite gerade“ nie sichtbar, was sie im Moment langsamer erscheinen ließ. Die Scorecard hat sie sichtbar gemacht.

Vollständige Tabellen, die Methodik ausgenommen, sowie die Dreistufen-Einordnung für jedes Projekt: /tools.

Unterstützt --dry-run (gibt die Dateiliste aus, ohne etwas zu verändern) und --target <dir> (installiert zur Inspektion in ein separates Verzeichnis). Das Skript liest die vorhandene CLAUDE.md und fügt den ShipLoop-Block ein, ohne die eigenen Regeln zu überschreiben. Das Installationsskript umfasst 178 Zeilen Bash, benötigt außer curl und git keine Abhängigkeiten und ist die erste Datei, die man lesen sollte, bevor man es ausführen lässt.

Repository: github.com/ruslan4427/claude-shiploop. Issues und PRs sind willkommen.