Workflow und Zustand
Auf einem gewöhnlichen Board sagt eine Spalte, wie weit etwas ist. Sie ist eine Markierung für Menschen: Wer sie liest, weiß Bescheid, und wer das Item verschiebt, hat etwas beschlossen.
Hier ist ein Zustand mehr als das. Er trägt die Anweisung, die derjenige bekommt, der das Item als Nächstes bearbeitet.
Was ein Zustand mitbringt
Jeder Zustand legt zwei Dinge fest.
Wer handelt. Entweder ein Mensch, oder eine Session, oder das System selbst. Bei einem menschlichen Zustand wartet das Item, bis jemand es ansieht. Bei einem maschinellen wird es zur Arbeit, die eine Session ziehen kann.
Was zu tun ist. Maschinelle Zustände tragen eine Anweisung. Im Zustand Spec eine andere als im Zustand Implement — dasselbe Item, ein anderer Auftrag, ein anderer Kontext.
Das ist der Grund, warum eine Session hier nicht bei null anfängt. Sie fragt nicht „woran arbeiten wir", sie bekommt gesagt, was jetzt dran ist und was sie dafür wissen muss.
Die Abläufe, die es heute gibt
HSDD — der vollständige Weg mit zwei Freigaben:
Backlog → Spec → Spec Review → Implement → Code Review → Done
(du) (KI) (du) (KI) (du)
ASDD — derselbe Weg ohne Zwischenfreigaben, für Aufgaben, bei denen du dem Ergebnis vertraust:
Backlog → Spec → Implement → Done
(du) (KI) (KI)
Simple — ohne Spezifikation, für Arbeit, die keine braucht.
Planning — die Vorstufe: aus einem groben Gedanken eine formulierte Anforderung machen, bevor sie überhaupt in einen der anderen Abläufe geht. Der Ablauf, mit dem fachliche Rollen arbeiten.
Die Wahl triffst du je Item. Der Unterschied zwischen HSDD und ASDD ist eine Entscheidung darüber, wie viel du sehen willst, nicht darüber, wie gut das Ergebnis wird.
Warum die Grenzen zwischen den Zuständen wichtiger sind als die Zustände
Das ist der eigentliche Gedanke hinter der Konstruktion, und er ist der Grund, warum das Ganze mit gewöhnlichen Modellen ungewöhnlich zuverlässig läuft.
Ein langes Gespräch mit einem Modell wird schlechter, je länger es dauert. Es sammelt sich an: alte Irrtümer, verworfene Ansätze, Halbsätze aus einem anderen Zusammenhang. Irgendwann arbeitet das Modell gegen seinen eigenen Verlauf.
Ein Zustandswechsel schneidet das ab. Jeder Zustand fängt sauber an, mit genau dem Kontext, der zu ihm gehört. Keine Session muss etwas über ihre Aufgabe hinaus im Kopf behalten.
Damit ist das Gerüst festgelegt und nur die Arbeit innerhalb eines einzelnen Schritts offen. Und ein einzelner Schritt ist klein genug, dass heutige Modelle ihn zuverlässig schaffen.
Was ohne Zuweisung passiert
Nichts. Eine Session bekommt ausschließlich Items, die ihr zugewiesen sind — nicht bevorzugt, sondern ausschließlich. Fragt sie nach einem fremden Item, bekommt sie eine Absage statt einer Antwort.
Das ist kein Komfortmerkmal, sondern eine Grenze: Kein Agent arbeitet an etwas, das ihm niemand gegeben hat.
Der Weg zurück
Ein Item muss nicht vorwärts. Passt ein Ergebnis nicht, schiebst du es zurück und schreibst dazu, was zu überarbeiten ist. Diese Anmerkung wird Teil des Kontextes des Items — die nächste Session liest sie mit, statt denselben Fehler noch einmal zu machen.
Mehrere Abläufe auf einem Board
Die vier Abläufe sind ein Vorschlag, keine Grenze. Welcher davon in einem Projekt gilt, legt die Administration deines Arbeitsbereichs fest — ein Projekt kann mehrere gleichzeitig führen.
Der praktische Nutzen zeigt sich im Team: Verschiedene Rollen können auf demselben Board mit verschiedenen Abläufen arbeiten. Wer fachlich zuarbeitet, braucht nicht denselben Weg wie jemand, der implementiert — und niemand muss seine Arbeitsweise aufgeben, damit die andere Seite funktioniert.
Was ein Workflow heute nicht tut
Er läuft nicht von allein durch. Ein maschineller Zustand macht das Item zu verfügbarer Arbeit; ausgeführt wird es, wenn du eine Session startest. Es gibt keine Items, die über Nacht fertig werden.
Und du legst heute keine eigenen Abläufe an. Zustände benennen, festlegen wer handelt, die Anweisungen schreiben — das machen wir. Brauchst du einen Ablauf, den es noch nicht gibt, ist das eine Anfrage an uns, kein Handgriff in deinem Arbeitsbereich.
Daran arbeiten wir, und wir sagen es hier, weil der Unterschied groß ist.
- Wo die Anweisungen und Entscheidungen liegen → Das Umbrella
- Wie deine Session an die Arbeit kommt → Die MCP-Anbindung
- Der ganze Ablauf am Stück → Erste Schritte