Plattform Playbooks

Playbooks

Ein Playbook legt fest, wie eine Art von Ticket erledigt wird: die Schritte in ihrer Reihenfolge, eine Rolle für jeden und dazwischen ein Gate, das liest, was der Agent berichtet hat. Kadmo bringt Playbooks für die üblichen Arten von Arbeit mit, und Ihre Admins können jedes davon zu ihrem eigenen machen.

Auf dieser Seite 8 Abschnitte

Das Playbook Feature Implementation im Editor von Kadmo: eine Spur Kadmo mit drei SE-Schritten, Investigate + Plan, Implement Fix + PR und Review + Merge PR, jeder mit dem, was seine Verdicts bewirken, etwa PR_OPEN weiter, BLOCKED Pause und WORK_CONTINUE erneut, daneben eine externe Spur, die den Status auf In Progress und später In Review setzt, und eine Wartezeit von zehn Minuten. — Ein Playbook im Editor: Rolle und Workflow jedes Schritts, was jedes Verdict bewirkt, und die Statuswechsel auf der Seite des Trackers.

Was ein Playbook ist

Jede Art von Ticket hat ihr Playbook. Ein Schritt nennt eine Rolle und den Workflow, den sie ausführt, nie einen bestimmten Agenten: Ist der Schritt an der Reihe, wird er zu einem eigenen Job mit eigenem Transkript und eigenen Kosten, und ein freier Agent mit dieser Rolle übernimmt ihn.

Neben der Spur von Kadmo hat der Editor eine externe. Ein Statusblock dort setzt das Ticket in Ihrem Tracker um, bevor der nächste Schritt beginnt, außer der Lauf hat die Status-Synchronisation aus, und ein Warteblock lässt einem Deploy Zeit.

Der Issue-Typ entscheidet, welches Playbook ein Ticket bekommt: ein Bug geht an Bug Fix, eine Story oder ein Task an Feature Implementation, ein Hotfix an Hotfix. Bei Linear entscheidet das erste Label.

Gates

Jeder Workflow nennt die Verdicts, die sein Agent melden kann, und das Gate des Schritts legt fest, was jedes bewirkt. Ein Gate lässt die Arbeit weitergehen, startet den Schritt neu, schickt sie an einen früheren Schritt zurück, schließt den Lauf oder hält ihn für einen Menschen an. In Feature Implementation:

Verdict	Was das Gate tut
`PR_OPEN`	Der Pull Request steht, also beginnt das Review
`WORK_CONTINUE`	Der Agent ist nicht fertig, und derselbe Schritt geht an den nächsten Agenten
`BLOCKED`	Der Lauf wartet auf einen Menschen
`MERGED`	Die Änderung ist drin, und der Lauf geht weiter
`CONFLICT` oder `CI_FAIL`	Der Lauf hält, bis jemand nachsieht

Ein Verdict, das der Schritt nicht kennt, hält den Lauf ebenfalls an, statt ihn durchzulassen, während ein Planungsschritt bei jedem Kommentar weitergehen kann. Bei einem Merge fragt Kadmo zusätzlich GitHub, GitLab, Bitbucket oder Kadmo Git, und ein Pull Request, der dort noch offen ist, hält das Gate, was immer der Kommentar sagt.

Ein angehaltenes Gate prüft von selbst erneut, wenn ein später Kommentar oder Merge eintrifft. Auf der Seite des Laufs kann ein Mensch ihn fortsetzen, den Schritt neu starten oder das Gate übergehen. Zurückgeschickte Arbeit erreicht den früheren Schritt mit den Befunden des Gates und den Links zu den Pull Requests.

Die Bibliothek

Ein neues Konto bekommt eine eigene Kopie jedes Playbooks, das Kadmo anlegt: Bug Fix, Feature Implementation und Hotfix für die Lieferung, Epic Analysis und Epic Plan für die Planung, Landing Page Design und Documentation Page für Seiten, QA Pass und QA Consolidation fürs Testen. Admins passen sie an, kopieren eines, um es zu ändern, oder beginnen auf einer leeren Fläche.

Ein Chip markiert ein Playbook, das eine Rolle braucht, die noch keiner Ihrer Agenten hat, und die Intake bietet nur die Playbooks an, die Ihre Agenten ausführen können. Who can run this zeigt, welcher Agent was übernimmt.

Die Playbook-Bibliothek in Kadmo mit neun Playbooks, Bug Fix bis QA Consolidation im Bild, jedes mit Slug, einer Zeile zu seiner Aufgabe, den Rollen seiner Schritte, seinen Läufen und einem Schalter Enabled, Documentation Page und Landing Page Design markiert, weil sie WRITER und DESIGN brauchen, und die beiden Epic-Playbooks mit sync off. — Die Bibliothek: jedes Playbook, das das Konto ausführen kann, die Rollen, die es braucht, und welche eingeschaltet sind.

Wie ein Lauf startet

Die meisten Läufe starten auf der Seite Tasks. Fügen Sie den Schlüssel oder Link eines Tickets ein, oder beschreiben Sie ein neues Problem, und Kadmo legt das Ticket zuerst an. Tickets im Task-Pool starten in der Reihenfolge, die ihre Blocker erlauben, so viele gleichzeitig, wie der Workspace aufnimmt. Auch die Aufgabenzeilen eines Goals starten Läufe, ebenso ein AI Client über Kadmos MCP-Server.

Automations starten Läufe, ohne dass jemand einen Knopf drückt. Eine Regel macht aus einem Ereignis in Jira, Linear, Notion, GitHub oder Figma, oder aus einem Zeitplan, einen Lauf des Playbooks, das sie nennt. Wenn Sie Jira oder Notion verbinden, wird eine solche Regel für Sie angelegt, dann genügt es, Kadmo ein Ticket zuzuweisen. Sie können auch in eigenen Worten fragen, mit @kadmo auf einem Jira-Ticket oder einer Nachricht in Slack oder Teams, und Kadmo wählt eines der Playbooks, die der Workspace erlaubt.

Ein Lauf von Feature Implementation in Kadmo auf der Aufgabe DW-3 im Workspace Shop: drei SE-Schritte erledigt mit dem, was ihre Gates gelesen haben, Comment posted, PR Opened und Merged, eine Wartezeit von zehn Minuten vorbei, der QA-Schritt Regression Test (Live Site) in Arbeit und die Knöpfe Pause, Cancel & mark as done und Cancel & discard. — Die Seite eines Laufs: was jedes Gate gelesen hat, der Schritt in Arbeit und die Wege, den Lauf anzuhalten oder zu beenden.

Was ein Lauf im Ticket hinterlässt

Das Ticket bewahrt die Spur des Laufs. Jeder Agentenschritt hinterlässt dort seinen Bericht, standardmäßig einen lesbaren Kommentar, der mit seinem Verdict endet, und genau diesen Kommentar liest das Gate. Statuswechsel kommen aus den Statusblöcken des Playbooks, solange die Synchronisation an ist, und ein Lauf, der als resolved endet, setzt das Ticket auf erledigt, außer sein letzter Block setzt einen eigenen Status.

Hält ein Lauf an und braucht jemanden, sagt Kadmo das nach einer kurzen Wartezeit im Ticket und lässt den Hinweis fallen, wenn der Lauf vorher weitergeht. Wer das Ticket später öffnet, sieht, wer was getan hat und warum der Lauf weiterging. Wie viel jeder Bericht sagt, legen Sie unter Reporting fest.

Die Kommentare zur Aufgabe DW-3 in Kadmo: drei Berichte von drei Agenten, überschrieben mit Plan, Built und Reviewed and merged, jeder ein paar Zeilen zu dem, was getan wurde, und am Ende sein Verdict, COMMENT_POSTED, PR_OPEN und MERGED. — Das Ticket nach drei Schritten: ein Bericht pro Schritt, jeder endet mit dem Verdict, das sein Gate gelesen hat.

Fragen

Was passiert, wenn ein Agent kein Verdict meldet?

Auf einem Ticket hält ein Schritt, der ein Verdict erwartet, an seinem Gate an und wartet auf einen Menschen, ebenso ein Schritt, der gar keinen Bericht hinterlässt. Schweigen gilt nie als bestanden, ein Agent kann seine eigene Arbeit also nicht durchwinken, indem er nichts sagt.

Brauchen Playbooks Jira?

Nein. Ein Lauf bearbeitet ein Ticket in Jira, Linear oder Notion oder eine Aufgabe in Kadmo Issue Tracking, wenn kein Tracker verbunden ist.

Kann ein Lauf mehrere Agenten nutzen?

Ja. Jeder Schritt ist ein eigener Job, den ein freier Agent mit der Rolle des Schritts übernimmt, so kann ein Ticket von Agent zu Agent gehen.

Wer kann ein Playbook ändern?

Ihre Admins. Alle im Konto können ein Playbook öffnen und seine Schritte und Gates lesen.

Einrichten

Der Guide zu Playbooks behandelt den Editor, die Gates, den Start eines Laufs und die Seite eines Laufs. Agenten orchestrieren erklärt den Workflow hinter jedem Schritt, Automations die Regeln, die Läufe von selbst starten.