Jedes Mal, wenn ein Coding-Agent eine Aufgabe abschließt, öffnet sich dieselbe Lücke. Man bekommt einen Diff und ein fröhliches „fertig“, aber nicht, was sich geändert hat, was übersprungen wurde, was getestet wurde oder worüber sich der Agent noch unsicher ist. Also liest man den Diff erneut, führt die Tests selbst noch einmal aus und stellt erneut Fragen, die der Agent hätte beantworten können, als er die Arbeit zurückgab. Bei zwei Agents verdoppeln sich diese Kosten. Die Arbeit ist nicht das Problem. Die Übergabe ist es: was zwischen der Person, die beauftragt, und dem Agent, der ausführt, fließt – und was zurückkommt.
Ein Handoff-Template für Coding-Agents ist eine feste Struktur dafür, was eine Aufgabe bei einem Besitzerwechsel mit sich führt: von einer Person an einen Agent bei der Zuweisung und von einem Agent zurück an eine Person beim Review. Statt die Form jeder Übergabe zu improvisieren, füllt man jedes Mal dieselben Felder aus. Der Agent weiß vor dem Start, was „fertig“ bedeutet, und man bekommt dieselbe Zusammenfassung, dieselben Belege und dieselben offenen Fragen, wenn er aufhört.
Dieser Artikel stellt die zwei Templates vor, die sich in der Praxis bewähren, mit Sharkly als Workflow: die Ebene über deinen Coding-Agents, die Kontext, Fortschritt, Blocker, Ergebnisse und menschliche Review von der Anfrage bis zum Release sichtbar hält. Du hast bereits Coding-Agents. Sharkly macht ein Team daraus, und das Handoff-Template sorgt dafür, dass jede Übergabe ein Beleg statt einer Vermutung ist.
Was ein Handoff-Template für Coding-Agents ist
Ein Handoff-Template ist eine Checkliste in Strukturform. Es beantwortet drei Fragen, die ein nackter Diff nie beantwortet: Was wurde verlangt, was ist passiert und wer ist jetzt am Zug. Wenn diese drei zusammen reisen, liest der nächste Beteiligte einen Beleg, statt drei zu rekonstruieren.
Es gibt zwei Übergaben, die ein Template verdienen, weil sie in entgegengesetzte Richtungen laufen und entgegengesetzte Dinge mit sich führen:
- Assignment-Handoff (Person oder leitender Agent an einen Agent): das Ziel, die Grenzen und die Definition von „fertig“, die vor Arbeitsbeginn übergeben werden.
- Review-Handoff (Agent zurück an eine Person): die Änderung, der Nachweis, dass sie funktioniert, und die Teile, die ein Mensch noch beurteilen muss – übergeben, wenn die Arbeit endet.
Beide mit einem Template zu versehen, ist der Punkt. Die meisten Teams schreiben ein grobes Ticket und versehen auf dem Rückweg nichts mit einem Template, sodass jede Review als Verhör beginnt. Den Rückweg zu reparieren, ist der Ort, an dem die Zeit steckt.
Das Betriebsmodell, das das Template abbildet
Ein Template ist nur so gut wie das Betriebsmodell darunter. Vier Verben entscheiden, wer welche Nahtstelle besitzt: wer zuweist, wer ausführt, wer reviewt, wer abnimmt. Agents recherchieren, führen aus, testen und berichten. Menschen geben die Richtung vor, erteilen Befugnisse und nehmen das Ergebnis ab. Automatisierung endet dort, wo Team-Urteilsvermögen gefragt ist.
Dieser Vertrag ist der Grund, warum die beiden Templates unterschiedliche Felder tragen. Ein Agent sollte nie raten müssen, wie die Abnahme aussieht, also zwingt das Assignment-Template den Auftraggeber, sie aufzuschreiben. Eine Person sollte nie raten müssen, ob Grün sicher bedeutet, also zwingt das Review-Template den Agent, seine Arbeit offenzulegen. Hier ist der Assignment-Handoff als Copy-Paste-Block:
## Assignment handoff
Task ID: SH-###
Goal: one sentence, in plain language
In scope: the specific files, endpoints, or behaviors to touch
Out of scope: what to leave alone (auth, billing, public contracts)
Definition of done:
- [ ] observable acceptance criterion 1
- [ ] observable acceptance criterion 2
Constraints: frameworks, patterns, or limits to respect
Assignee: the exact Agent that owns this
Die Zeilen „Out of scope“ und „Definition of done“ leisten die Schwerstarbeit. Ohne sie optimiert ein Agent auf einen bestehenden Diff, nicht auf das Ergebnis, das du gemeint hast. Mit ihnen ist die Abnahmeprüfung geschrieben, bevor eine einzige Zeile Code existiert.
Der Review-Handoff: Was zurückkommt
Das Rückgabe-Template ist dasjenige, das die meisten Workflows überspringen – und das dir deinen Nachmittag rettet. Wenn ein Agent fertig ist, sollte er dich nicht mit „bereit“ und einem Link anpingen. Er sollte eine ausgefüllte Struktur zurückgeben:
## Review handoff
Task ID: SH-###
Summary: what changed, in 2-3 sentences
Acceptance: each definition-of-done item, checked with how it was verified
Tests: typecheck / unit / build results, pasted or linked
Diff: the PR or worktree branch
Known limits: what this does NOT cover, and any risky assumption
Open questions: decisions left for a human
Die Felder „Known limits“ und „Open questions“ sind das, was eine echte Übergabe von einer Wand voller grüner Häkchen unterscheidet. Eine ehrliche Einschränkung („Der Redis-Zähler setzt eine einzelne Region voraus“) verwandelt einen blinden Merge in einen informierten. Es ist dasselbe Prinzip wie beim Review von KI-generiertem Code mit Belegen auf Aufgabenebene: Der Reviewer liest eine Aussage samt Beweis, nicht einen Diff samt Hoffnung.
Eine Grenze, die man klar aussprechen sollte: Der Review-Handoff ist keine Merge-Anfrage. Er ist eine Review-Anfrage. Der Agent stellt vor; die Person entscheidet. Diese beiden Akte getrennt zu halten, ist das, was verhindert, dass ungereviewte Arbeit ausgeliefert wird.
Status und Review-Gates: Wo das Template lebt
Ein Template, das in einem Scrollback-Puffer lebt, ist ein Template, das niemand liest. Der Handoff muss an etwas Gemeinsames angehängt sein, und Status sind der natürliche Ort dafür. Jede Task durchläuft genau eine Spur, und jede Statusänderung ist eine Übergabe mit angehängtem Template:
| Status | Owner | Template attached |
|---|---|---|
| Todo | Person or leader Agent | Assignment handoff |
| In progress | Agent | (working in an isolated worktree) |
| Ready for review | Agent | Review handoff |
| Done | Person | acceptance note + merge decision |
Die Regel, die das lesbar macht: Agents verschieben eine Task nach Ready for review; Menschen verschieben sie nach Done. Ein Agent markiert seine eigene Arbeit nie als Done, und eine Person muss nie rekonstruieren, was passiert ist, weil der Review-Handoff bereits an der Task hängt. In Sharkly kehren Ausführung, Blocker, Ergebnisse und Folgegespräche in die Task-Timeline zurück, sodass man bei zehn laufenden Agents das Board liest und nicht zehn Terminals. Das ist der Unterschied zwischen dem Nachverfolgen dessen, was Agents abgeschlossen haben und der Hoffnung, dass ein Commit-Log es später erklärt. Wo autonome Arbeit stoppen muss, ist selbst eine Designentscheidung, behandelt in wo man Approval-Gates platziert.
Ein durchgerechnetes Beispiel: Vom Ticket zum gemergten PR
Nehmen wir eine realistisch geformte Task, SH-441: „CSV-Export zur Reports-Seite hinzufügen.“ Beobachte, wie sich die Templates füllen, nicht der Code.
Eine Person öffnet SH-441, und ein leitender Agent vervollständigt den Assignment-Handoff: Ziel („Nutzer sollen den aktuellen Report als CSV herunterladen können“), im Scope (der Reports-Controller und ein neues Export-Modul), außerhalb des Scope (Auth, die bestehenden Report-Abfragen) und eine Definition von „fertig“ mit drei prüfbaren Punkten (ein Download-Button, korrektes Escaping für Kommas und Anführungszeichen, ein Test mit einem 10k-Zeilen-Fixture). Der Assignee ist ein Backend-Agent. Nichts ist mehrdeutig, weil das Template es nicht zugelassen hat.
Der Backend-Agent beansprucht die Task, arbeitet in einem isolierten Worktree, sodass er nie mit anderer Arbeit kollidiert, und arbeitet die Definition-of-done-Punkte als seine eigene Checkliste ab. Wenn Typecheck, Unit-Tests und Build grün sind, verschiebt er SH-441 nach Ready for review mit ausgefülltem Rückgabe-Template: eine kurze Zusammenfassung, jeden Abnahmepunkt abgehakt mit der Angabe, wie er verifiziert wurde, der Diff und eine bekannte Einschränkung („Exporte über 100k Zeilen puffern im Speicher; Streaming ist nicht implementiert“).
Jetzt dreht sich die Übergabe um. Eine Person liest einen Beleg, nicht ein Scrollback. Sie bestätigt den Escaping-Test, wägt das Speicherlimit gegen reale Report-Größen ab, nimmt es vorerst ab und verschiebt SH-441 nach Done, was den Merge auslöst. Vom Ticket zum gemergten PR, mit einem ausgefüllten Template an beiden Nahtstellen und einem Beleg darüber, wer was besessen hat. Das ist der von Anforderungen zu Code nachvollziehbar gemachte Weg von Anfang bis Ende.
Wann ein Template überflüssig ist
Templates haben einen Preis, also hier das ehrliche Entscheidungspaar. Überspringe das vollständige Template bei kleiner, klar definierter Arbeit, die ein Agent in einem Durchgang erledigt, wo das Ziel und die Abnahme aus dem Task-Titel offensichtlich sind. Greife danach, sobald Arbeit eine Nahtstelle überquert, die zählt: mehrere Agents an einem Ziel, eine Änderung an einem öffentlichen Vertrag oder irgendetwas, das Auth, Billing oder Daten berührt, die man nicht einfach zurücknehmen kann. Ein Template ist eine Versicherung gegen verlorenen Kontext, und eine Versicherung schließt man dort ab, wo ein Verlust wehtun würde.
Du kannst das alles von Hand mit einem geteilten Board und Disziplin betreiben. Das funktioniert, bis die Zahl der Agents, Tasks und Repositories steigt und die Disziplin das Erste ist, was verloren geht. Wenn du bereits mehrere Agents laufen lässt, gibt dir Sharkly einen Ort, um ihre Tasks und Ergebnisse zu verwalten: geteilte Tasks, die den Assignment- und den Review-Handoff tragen, Assignees pro Task, isolierte Worktrees und eine Status-Spur, in der Agents Ready for review erreichen und Menschen Done entscheiden. Behalte die Coding-Agents, die du bereits nutzt. Lade Sharkly herunter, wenn die Nahtstellen zwischen ihnen anfangen, mehr zu kosten als die Arbeit.
FAQ
Was ist ein Handoff-Template für Coding-Agents? Es ist eine feste Struktur dafür, was eine Aufgabe bei einem Besitzerwechsel mit sich führt. Es gibt zwei: einen Assignment-Handoff (Ziel, Scope und Definition von „fertig“, von einer Person an einen Agent) und einen Review-Handoff (Zusammenfassung, Belege und bekannte Einschränkungen, von einem Agent zurück an eine Person). Jedes Mal dieselben Felder auszufüllen, ist das, was verhindert, dass der Kontext zwischen den Beteiligten verdampft.
Warum den Rückweg mit einem Template versehen und nicht nur das Ticket? Die meisten Teams schreiben ein Ticket und versehen auf dem Rückweg nichts mit einem Template, sodass jede Review als Verhör beginnt. Der Review-Handoff mit seiner Zusammenfassung, den abgehakten Abnahmepunkten und den bekannten Einschränkungen ist der Ort, an dem ein Template am meisten Zeit spart. Siehe Human-in-the-Loop-Coding-Agents.
Sollte ein Agent seine eigene Arbeit als fertig markieren? Nein. Lass einen Agent eine Task nach Ready for review verschieben mit ausgefülltem Rückgabe-Template; überlasse den Schritt nach Done und die Merge-Entscheidung einer Person. „Vorgestellt“ von „abgenommen“ zu trennen, ist das, was verhindert, dass ungereviewter Code ausgeliefert wird.
Wo sollte das Template leben? An einer geteilten Task, angehängt an eine Statusänderung, nicht in einem Terminal, das nur ein Agent gesehen hat. Wenn der Handoff ein Status mit angehängtem Template ist, sieht der nächste Beteiligte genau, was auf ihn wartet. Das verhindert auch, dass Review zum Engpass wird, wenn viele Agents gleichzeitig fertig werden.
Brauche ich dafür ein Tool, oder kann ich es manuell machen? Du kannst es mit einem geteilten Board und Disziplin betreiben. Eine dedizierte Ebene zahlt sich aus, sobald du mehrere Agents über mehrere Repositories koordinierst und manuelles Tracking zur eigentlichen Arbeit wird. Vergleiche es mit einem Allzweck-KI-Task-Manager für Agent-Arbeit.
