KI-Coding-Workflow in Version 3: mehr Automatisierung denn je
Ein Entwickler beschreibt die dritte Version seines KI-Coding-Workflows: Worauf frueher plan mode und eine handgeschriebene SPEC.md folgten und spaeter TracerKit, laufen jetzt viele Schritte weitgehend autonom. Neue Tools und bessere Modelle machen das moeglich.
Veröffentlicht am 24. Oktober • Zuerst erschienen auf helderberto.com
Mein KI-Coding-Workflow ändert sich alle paar Monate, deshalb vergebe ich ihm Versionsnummern. Neue Tools erscheinen, Modelle werden besser, und Schritte, die im letzten Frühjahr noch Handanleitung brauchten, laufen heute von allein.
v1 war der Plan-Modus mit einer handgeschriebenen SPEC.md. v2 machte daraus TracerKit. Dieser Beitrag ist v3: Jeder Schritt lebt jetzt in helderberto/agent-skills.
Die Idee hinter v3 passt in einen Satz: Jeder Schritt, der früher ein Prompt war, ist jetzt ein Skill, und jedes „denk bitte daran“ ist jetzt ein Check, der fehlschlagen kann.
TracerKit funktionierte, aber es war ein eigenständiges Tool mit eigenem Release-Zyklus. Jede Anpassung an einem Schritt bedeutete eine Änderung dort, einen Release und ein Update in jedem Projekt. Ich wollte einen einfacheren Weg, Updates auszuliefern und neue Skills hinzuzufügen.
Ich hielt meine anderen Skills ohnehin schon in agent-skills. Den Spec-Flow dorthin zu versetzen, brachte alles an einen Ort. Jetzt ist das Ändern eines Schritts oder Hinzufügen eines Skills ein einziger Commit.
Die Ideen aus TracerKit haben überlebt: Interviews vor den Specs, Tracer-Bullet-Tickets, Verifikation, bevor eine Aufgabe als erledigt gilt. Sie leben im selben Repository wie der Rest meiner Skills.
v3 habe ich nicht von Grund auf neu entworfen. Der Großteil stammt aus zwei Repositories, und ich habe jeweils das übernommen, was ich für das Beste halte.
Aus Matt Pococks Skills habe ich die Form des Flows übernommen:
Aus Addy Osmanis agent-skills habe ich die technische Tiefe innerhalb jedes Schritts übernommen:
Dann habe ich alles auf das reduziert, was das Verhalten des Agenten in meinen Projekten tatsächlich verändert, und ihnen einen gemeinsamen Namensraum gegeben: /hb:.
flowchart LR accTitle: The v3 flow accDescr: Plan with triage, grill, to-spec and to-tickets. Build with build and review. Ship with to-pr and retro. Small fixes skip from triage straight to build. subgraph Plan direction TB triage --> grill --> spec[to-spec] --> tickets[to-tickets] end subgraph Build direction TB build --> review end subgraph Ship direction TB pr[to-pr] --> retro end Plan --> Build --> Ship Nicht jede Aufgabe braucht alle davon. /hb:triage bewertet die Größe der Arbeit und benennt, wo man anfangen soll. Ein kleiner Fix geht direkt an /hb:build.
Ich schreibe die Prompts aus v1 nicht mehr. Ich habe sie einmal als Skills geschrieben, und jetzt verfeinere ich die Skills. Dafür habe ich in Skills Are the New CLI plädiert.
Nehmen wir denselben Dark-Mode-Toggle. In v1 öffnete ich den Plan-Modus und schrieb einen Absatz, in dem ich Claude bat, den Ansatz zu diskutieren und eine Spec zu erzeugen. Jetzt beginnt es mit einem einzigen Befehl:
/hb:grill dark mode Enter fullscreen mode Exit fullscreen mode Das grill interviewt mich in Runden. Jede Runde stellt alle Fragen, die ich gerade beantworten kann, jeweils mit einer empfohlenen Antwort, sodass ein bloßes „ja“ sie übernimmt. Geklärte Begriffe wandern in ein Glossar, und schwer umkehrbare Entscheidungen werden beim Aufkommen zu ADRs.
Dann wird das Gespräch zu Artefakten:
/hb:to-spec dark-mode /hb:to-tickets dark-mode Enter fullscreen mode Exit fullscreen mode Die Spec landet in.specs/specs/dark-mode.md. Die Tickets sind schmale vertikale Scheiben mit blockierenden Abhängigkeiten, sodass der Agent weiß, welches als nächstes entblockt ist. Die v1-Checkliste gibt es noch immer, aber jetzt hat sie eine Reihenfolge.
/hb:build dark-mode Enter fullscreen mode Exit fullscreen mode Es nimmt das nächste entblockte Ticket, arbeitet test-first, führt die Checks des Projekts aus und committet. Mit --all verteilt es die Tickets nach einer einzigen Freigabe an parallele Subagenten.
Zwei Befehle schließen den Prozess ab. /hb:review schickt den Diff an mehrere Reviewer und führt ihre Befunde zu einem einzigen, nach Priorität geordneten Urteil zusammen. /hb:to-pr führt die Checks aus, pusht, öffnet den PR und beobachtet CI.
Anweisungen in einem Prompt werden unter Druck übergangen. Ein Check, der fehlschlägt, nicht. Deshalb bestehen die meisten meiner Schutzmaßnahmen aus Dingen, die mit einem Fehler enden:
Der Agent kann schnell sein, weil er diese nicht stillschweigend überspringen kann. Warum das wichtig ist, habe ich ausführlicher in Code Got Cheap. Review Didn't. beschrieben.
/hb:debug hat eine Regel, die ich inzwischen auch ohne Agenten befolge: keine Theorie vor einem Feedback-Loop.
Bevor der Agent Code liest, um eine Ursache zu raten, muss er einen einzigen Befehl zeigen, der den Bug reproduziert. Er muss exakt das Symptom zeigen, bei jedem Lauf dasselbe Ergebnis liefern und in Sekunden durchlaufen. Ein fehlschlagender Test, ein curl, ein Headless-Browser-Skript.
Erst danach listet er 3 bis 5 Hypothesen nach Priorität auf, jede mit einer Vorhersage, die sie widerlegen könnte. Das hindert den Agenten daran, die erste plausibel klingende Ursache zu fixen, was die Gewohnheit ist, die die meisten meiner Debugging-Sessions verschwendet hat.
flowchart TD accTitle: The debug loop accDescr: Build a feedback loop that fails, reproduce and minimize, list ranked hypotheses, test each one against the loop until it goes green, then fix and keep the loop as a regression test. loop[Failing loop] --> repro[Reproduce + minimize] --> hyp[3-5 ranked hypotheses] hyp --> test{Loop goes green?} test -- no, next hypothesis --> hyp test -- yes --> fix[Fix + regression test] Der Flow verbessert sich selbst Der letzte Schritt ist /hb:retro. Es liest die Session und schlägt Änderungen an der Umgebung vor, nicht am Code: ein fehlender Check, eine Regel in AGENTS.md, die ein Lint-Regel sein sollte, eine Datei, die der Agent zu lange gesucht hat.
Hier zahlt sich die Trennung von TracerKit aus. Ein Retro-Befund wird zu einer Einzeiler-Änderung in agent-skills, und jedes Projekt übernimmt sie beim nächsten Update.
Die Spec steht weiterhin im Mittelpunkt, wie schon in v1. Geändert hat sich alles darum herum. Die Prompts, die ich immer wieder neu getippt habe, sind Skills, und die Erinnerungen, die ich ständig geben musste, sind Checks.
Dieser Flow wird sich mit dem nächsten Tool oder Modell wieder ändern. Wenn das passiert, wird es ein Commit an agent-skills sein, und v4.
Automatisch übersetzt. Das Original auf Englisch ist unten aufklappbar.
Original (Englisch) anzeigen
Posted on Oct 24 • Originally published at helderberto.com
My AI coding workflow changes every few months, so I give it version numbers. New tools ship, models get better, and steps that needed hand-holding last spring now run on their own.
v1 was plan mode and a hand-written SPEC.md. v2 turned that into TracerKit. This post is v3: every step now lives in helderberto/agent-skills.
The idea of v3 fits in one line: each step that used to be a prompt is now a skill, and each "please remember to" is now a check that fails.
TracerKit worked, but it was a separate tool with its own release cycle. Every tweak to a step meant a change there, a release, and an update in each project. I wanted a simpler way to ship updates and add new skills.
I was already keeping my other skills in agent-skills. Moving the spec flow next to them put everything in one place. Now changing a step or adding a skill is one commit.
The ideas from TracerKit survived: interviews before specs, tracer-bullet tickets, verification before a task counts as done. They live in the same repo as the rest of my skills.
I didn't design v3 from scratch. Most of it comes from two repos, and I took what I think is the best of each.
From Matt Pocock's skills I took the shape of the flow:
From Addy Osmani's agent-skills I took the engineering depth inside each step:
Then I cut each one down to what changes the agent's behavior in my projects, and gave them one namespace: /hb:.
flowchart LR accTitle: The v3 flow accDescr: Plan with triage, grill, to-spec and to-tickets. Build with build and review. Ship with to-pr and retro. Small fixes skip from triage straight to build. subgraph Plan direction TB triage --> grill --> spec[to-spec] --> tickets[to-tickets] end subgraph Build direction TB build --> review end subgraph Ship direction TB pr[to-pr] --> retro end Plan --> Build --> Ship Not every task needs all of them. /hb:triage sizes the work and names where to start. A small fix goes straight to /hb:build.
I no longer write the prompts from v1. I wrote them once, as skills, and now I refine the skills. I made the case for this in Skills Are the New CLI.
Take the same dark mode toggle. In v1, I opened plan mode and wrote a paragraph asking Claude to discuss the approach and generate a spec. Now it starts with one command:
/hb:grill dark mode Enter fullscreen mode Exit fullscreen mode The grill interviews me in rounds. Each round asks every question I can answer right now, each with a recommended answer, so a bare "yes" accepts it. Settled terms go to a glossary, and hard-to-reverse decisions become ADRs as they land.
Then the conversation becomes artifacts:
/hb:to-spec dark-mode /hb:to-tickets dark-mode Enter fullscreen mode Exit fullscreen mode The spec lands in.specs/specs/dark-mode.md. The tickets are thin vertical slices with blocking edges, so the agent knows which one is unblocked next. The v1 checklist is still there, but now it has an order.
/hb:build dark-mode Enter fullscreen mode Exit fullscreen mode It takes the next unblocked ticket, works test-first, runs the project's checks and commits. With --all, it fans tickets out to parallel subagents after one approval.
Two commands close it out. /hb:review sends the diff to several reviewers and merges their findings into one ranked verdict. /hb:to-pr runs the checks, pushes, opens the PR and watches CI.
Instructions in a prompt get skipped under pressure. A check that fails does not. So most of my guardrails are things that exit with an error:
The agent can be fast because it can't quietly skip these. I wrote more about why this matters in Code Got Cheap. Review Didn't.
/hb:debug has one rule I now follow without an agent too: no theory before a feedback loop.
Before reading code to guess a cause, the agent has to show one command that reproduces the bug. It must fail on the exact symptom, give the same result every run, and finish in seconds. A failing test, a curl, a headless browser script.
Only then does it list 3 to 5 ranked hypotheses, each with a prediction that could prove it wrong. That stops the agent from fixing the first plausible cause, which is the habit that wasted most of my debugging sessions.
flowchart TD accTitle: The debug loop accDescr: Build a feedback loop that fails, reproduce and minimize, list ranked hypotheses, test each one against the loop until it goes green, then fix and keep the loop as a regression test. loop[Failing loop] --> repro[Reproduce + minimize] --> hyp[3-5 ranked hypotheses] hyp --> test{Loop goes green?} test -- no, next hypothesis --> hyp test -- yes --> fix[Fix + regression test] The flow improves itself The last step is /hb:retro. It reads the session and suggests changes to the environment, not the code: a missing check, a rule in AGENTS.md that should be a lint rule, a file the agent took too long to find.
This is where moving off TracerKit pays off. A retro finding becomes a one-line edit in agent-skills, and every project picks it up on the next update.
The spec is still at the center, as it was in v1. What changed is everything around it. The prompts I kept retyping are skills, and the reminders I kept giving are checks.
This flow will change again with the next tool or model. When it does, it will be a commit to agent-skills, and v4.