Mein Coding-Workflow mit Claude

Vor einer Woche habe ich erzählt, wie aus ein paar ständig wiederholten Konventionen ein Plugin mit acht Skillsblog.orbitstack.casa wurde. Seitdem ist einiges passiert, vor allem auf der Coding-Seite. Hier also der Rundgang: welche Skills ich fürs Coden habe, was sie tun, und woran man sieht, dass die Konventionen dahinter nicht nur auf dem Papier stehen.

Zwei Plugins statt einem

Damals (hach ja, damals vorm Kriesch) lag alles in einem Plugin namens orbitstack. Inzwischen haben die Coding-Skills ihr eigenes: orbittech. orbitstack kümmert sich um den Rest meines Alltags — Kalender, Tasks, diesen Blog. orbittech kümmert sich um Code.

Heißt auch: zwei Plugins, die ich nach jeder Änderung selbst zusammenbauen und in Claude Desktop hochladen darf. Wie ich mein privates Skill-Repo sauber da reinbekomme, ohne jedes Mal Paketbote zu spielen, habe ich noch nicht raus. grummel grummel

Die Skills

coding — Das Fundament, auf das alle anderen verweisen, inzwischen bei Revision 66. Hier steht der Stack: Rust für Backends, CLIs, MCP-Server und Libraries, Svelte fürs Frontend, cargo und bun als einzige Paketmanager, TOML für die Konfiguration eigener Tools. Dazu Logging, Spec-Workflow, Git, Tests und Deployment, jeweils in eigenen ref-Dateien. Durchgesetzt wird das über just check, das bei Grün einfach still ist — und wer bewusst abweicht, schreibt das in die DEVIATIONS.md des Projekts.

Der Junge mag Struktur, was?

repo-sanity — Geht ein Repo gegen die Konventionen durch. Er erkennt den Projekttyp an den Dateien, lässt zuerst medic (dazu gleich mehr) laufen und prüft von Hand, was medic noch nicht kennt. Repariert wird dabei nichts: Jeder Befund wird entweder ein Task in tracky oder eine bewusst behaltene Abweichung. Eigene Regeln hat der Skill keine — nur eine Checkliste, wie man die Regeln aus coding prüft.

repo-todo — Bringt Ordnung in die offenen Tasks eines Repos; der Verzeichnisname ist der Tag, nach dem gefiltert wird. Er gruppiert nach Schicht (#cli, #api, #mcp, #ui, #lib) und Plattform, liest, was was blockiert, und schlägt eine Reihenfolge vor. Außerdem nennt er Bündel von Tasks, die man besser als eine gemeinsame Spec löst statt einzeln. Geschrieben wird nichts — umgesetzt wird nur, was ich absegne.

Ist „Spec" auch ein Instrument?

Nein Patrick, eine Spec ist kein Instrument. Eine Spec ist einfach nur ein Dokument, das sagt: „Feature A soll das können, und zwar genau so."

task-solver — Nimmt einen Task von der Triage bis zum getaggten Release. Die Triage macht er selbst, Spec, Implementierung, Review und Fixes laufen als eigene Agenten (spec-writer, coder, reviewer, fixer), jeder in seinem eigenen Worktree. Die wichtigste Regel: Code wird nie von dem Agenten beurteilt, der ihn geschrieben hat. Am Ende bumpt, mergt und taggt er und schließt die Tasks — nur git push bleibt bei mir.

survey — Der Neue im Bunde, Revision 1. Er liest bestehenden Code auf der Suche nach weniger [l], stabilerem [s], schnellerem [v] oder dedupliziertem [d] Code mit gleichem Ergebnis. Als „Exploration" beantwortet er stattdessen eine konkrete Frage — etwa „was wäre, wenn wir Paket A statt Paket B nähmen?" — gern mit Prototyp. Alles läuft auf einem eigenen Branch, das Ergebnis landet in einem Pad, und gemergt wird erst nach meinem Review.

Wie das im Alltag zusammenläuft

Den größten Unterschied machen tatsächlich die beiden unscheinbarsten: repo-sanity und repo-todo.

Wenn mir eine Idee für ein Projekt kommt, schreibe ich nicht sofort Code. Erst läuft repo-sanity, dann repo-todo, und dann ordne ich die neue Aufgabe in das ein, was da ist — falls sie nicht sowieso schon als Task herumliegt. Das klingt nach Umweg, ist aber das Gegenteil: Ich weiß, wo das Repo steht, statt es zu erfühlen. Ich grübel nicht mehr, was als Nächstes dran ist. Und die beiden greifen ineinander — repo-sanity erzeugt Befunde, repo-todo sortiert sie.

Nebenbei löst das ein Problem, das ich sonst hätte: Altbestand. Jede Konventionsänderung macht ältere Repos ein Stück „falscher". Statt alle paar Wochen einen großen Durchgang durch sämtliche Projekte zu machen, ziehe ich ein Repo einfach dann nach, wenn ich es sowieso wieder anfasse.

Ist die Aufgabe eingeordnet, übernimmt task-solver.

Und ja: Ich habe schon mal versucht, „einen großen Durchgang" für alles zu machen … Das Update aller meiner Tools auf keel 0.34 — meine gemeinsame Rust-Bibliothek — hat dann via task-solver spontan insgesamt 76 Agenten gespawnt. Und alle wollten irgendwas von mir. Meine persönlichen five minutes of fame glitzer funkel — und es hat mein Usage für die gesamte Woche gefressen …

Konventionen, die man prüfen kann

Warum überhaupt Konventionen als Skills? Der Auslöser war — wie im letzten Post erzählt — das ewige Wiederholen. Aber der eigentliche Gewinn liegt woanders:

• Konsistenz. Jede Session hält sich an dieselben Regeln, ohne dass ich sie erklären muss.
• Abweichungen werden sichtbar. Was nicht der Konvention entspricht, ist entweder ein Task oder eine bewusste Entscheidung mit Begründung.
• Gleiche Stacks. Meine Projekte verhalten sich vom Kern her gleich und lassen sich gleich coden.

Am deutlichsten sieht man das am justfile. So sieht es in fach aus, meinem Mail-Daemon:

Die just-Rezepte in fach — dieselben in jedem Rust-Projekt.

Dieselben Rezepte, dieselben Namen, in jedem Rust-Projekt: check als Gate, bump, commit, audit, hooks, install. Wer ein Repo kennt, kennt alle.

medic

Ein Teil der Konventionen ist inzwischen in ein eigenes Tool gewandert: medic. Es prüft ein Repo mechanisch gegen die Regeln, läuft als erster Schritt in just check und als pre-commit-Hook.

So sieht das in wordmark aus, meinem Logo-Generator:

medic check in wordmark: zwei ×, ein ?

Drei Zustände: ✓ passt, × passt nicht, und ? heißt „kann ich nicht allein entscheiden". Die beiden × sind echt: Dem justfile fehlt das audit-Rezept, und das Gate lässt cargo deny aus. wordmark braucht also noch Zuwendung — und zwar nicht nach Bauchgefühl, sondern mechanisch nachweisbar. Genau das ist der Punkt.

Kann sich noch wer daran erinnern, dass ich letztens meinte „erwarte nicht, dass dein eigener Code danach noch okay ist"? Ja-ha-ha!

Das Bild kommt übrigens aus besagtem wordmark-Projekt.

Das ? bei just/check-green ist ehrlich gemeint: medic baut nie selbst, also kann es auch nicht wissen, ob just check grün ist. Das prüft repo-sanity. Und wer wissen will, warum ein Check existiert, fragt einfach nach:

medic explain sagt, woher ein Check kommt.

Jeder Check hat einen Namen

Die Markierungen [m], [g] und [j] — mechanisch, grep, Urteil — habe ich letztes Malblog.orbitstack.casa schon erklärt. Neu ist, dass jeder Check eine feste ID bekommen hat, <bereich>/<name>. So steht er in der Checkliste von repo-sanity:

- [m] `just/check-runs-deny` In Rust, `check` runs `cargo deny --offline
  check bans licenses sources` (`../coding/ref/JUSTFILE.md`, "The gate is
  silent").

Dieselbe ID taucht in medic auf, und dieselbe ID steht in der DEVIATIONS.md, wenn ich eine Abweichung bewusst behalte. Die Markierung gehört dabei nicht zur ID — ein Check kann also von „grep" zu „mechanisch" aufsteigen, ohne dass eine einzige Ausnahme kaputtgeht.

medics Katalog ist eine Kopie dieser Liste. Laufen beide auseinander, gewinnt die Liste, und der Unterschied ist ein Task für medic — kein Befund gegen das Repo.

Und wer pflegt das alles?

Ehrlich: Das ist der Preis. coding steht bei Revision 66, und jede Regel will formuliert werden. Die Arbeitsteilung dabei: Ich gebe vor, was gelten soll, Claude schreibt den exakten Wortlaut. Und repo-sanity hat so etwas wie einen Check für die Checks — fällt beim Durchgehen etwas auf, das medic noch nicht abfängt, oder taucht dasselbe Problem wiederholt auf, wird daraus ein neuer Check.

insert Inception dröööööhn

Ein Beispiel aus dieser Woche

Wie so eine Regel entsteht, konnte ich diese Woche live beobachten. Die coder-Agenten hingen immer wieder ewig an Aufrufen wie diesem:

find / -name "keel-*" -path "*registry/src*" 2>/dev/null | head

Eigentlich wollten sie nur nachschauen, wie eine Funktion in keel aussieht. Dafür haben sie die komplette Platte durchsucht. Die Skills sagten zwar, was keel kann — aber nirgends, wo der Quellcode liegt. Im Cache liegen drei Versionen nebeneinander, der Agent weiß nicht, welche das Projekt benutzt, rät, und greift am Ende zum Vorschlaghammer.

Die Lösung ist ein Einzeiler: cargo metadata sagt genau, welche Version das Projekt laut Cargo.lock nutzt und wo sie liegt — in 0,13 Sekunden statt „irgendwann". Eine eigene API-Doku für keel gibt es dagegen bewusst nicht. Die würde driften; die Feature-Tabelle im Skill war schon eine Version hinterher. Die Doc-Kommentare im Code sind die Doku, man muss sie nur finden.

Die Regel steht jetzt an genau einer Stelle im coding-Skill, alle fünf Agenten verweisen darauf. Von der Beobachtung bis zum Commit: drei Nachrichten.

Die Agenten halten sich übrigens erstaunlich diszipliniert an Regeln. Aber wo keine steht, holen sie eben den Vorschlaghammer raus.

Und jetzt?

Wenn ich aus der letzten Woche eine Sache mitnehme, dann die: Eine Regel, die nur im Skill steht, ist eine Bitte. Eine Regel, die geprüft wird, ist eine Regel.

Nicht jede lässt sich prüfen — ob ein Agent find / tippt, sieht medic nie. Dann bleibt nur, sie an die richtige Stelle zu schreiben. Aber wo es geht: prüfbar machen.

wordmark weiß jetzt jedenfalls schwarz auf weiß, was es noch zu tun hat.