Playbooks für AI Coding Agents

Ein Prompt ist kein Prozess

Sie können einen Coding Agent bitten, der Reihe nach zu planen, zu bauen, zu prüfen und zu testen. Er liest diese Bitte bei jedem Lauf neu, und über eine lange Aufgabe driftet er: eine Prüfung fällt aus, der Agent begutachtet seine eigene Änderung, oder etwas landet, das niemand angesehen hat.

Ein Playbook lebt außerhalb des Modells. Seine Schritte, Rollen und Gates sind Konfiguration, ein Agent kann also keinen Schritt überspringen und auf keinem Schritt mergen, der es nicht erlaubt. Der Prozess hält beim hundertsten Ticket wie beim ersten.

Was in einem Playbook steckt

Jede Art von Arbeit hat ihr Playbook: ein Bug, ein Feature, ein Hotfix, eine Dokumentationsseite. Ein Schritt nennt eine Rolle und die Aufgabe, die sie erledigt. Ist der Schritt an der Reihe, übernimmt ihn ein freier Agent mit dieser Rolle auf seiner eigenen Maschine, bearbeitet das Ticket und meldet ein Verdict, und das Verdict entscheidet, was als Nächstes geschieht.

Playbook · Feature Implementation

TicketSie PlanPM BuildSE ReviewSenior Ihre Freigabe FreigabeSie TestQA Gemergt

Agenten mit einer Rolle, wie ein Team

Jeder Schritt nennt eine Rolle, und die Rolle legt fest, was ein Agent dort darf. Der Schritt, der baut, öffnet den Pull Request und kann ihn nicht mergen; der Merge gehört zum Review-Schritt, einem eigenen Job; der Schritt, der testet, meldet, was er gefunden hat, und mergt nichts. Bauen und Prüfen getrennt zu halten ist das, was Probleme früh fängt, wie in einem guten Scrum-Team.

Skills und Kontext: was jeder Agent weiß

Ein Agent bringt auf einen Schritt drei Dinge mit, und zusammen entscheiden sie über die Qualität der Arbeit, weit mehr als die Wahl des Modells.

Agenten reden nicht miteinander. Jeder Schritt schreibt auf das Ticket, was er getan hat und warum, und der nächste Schritt beginnt bei diesem Protokoll. Skill Discovery liest Ihre Repositories und Ihr Produkt und schreibt die Module des Packs für Sie, jedes mit einem Konfidenzwert, damit ein Agent die Codebasis kennt, bevor er sie anfasst.

Ein Gate nach jedem Schritt

Jeder Schritt endet in einem Verdict, und das Gate entscheidet, was es bedeutet. Ein Problem hält dort an, wo es auftaucht, statt bis ans Ende des Laufs zu wandern, und ein Gate kann die Arbeit samt seinen Befunden und den Links der Pull Requests an einen früheren Schritt zurückschicken.

Schweigen zählt nie als bestanden: ein Schritt ohne Verdict oder mit einem, das das Gate nicht kennt, hält den Lauf für einen Menschen an. Beim Merge fragt das Gate außerdem Ihren Git-Host, und ein noch offener Pull Request hält es auf, was auch immer der Kommentar sagt.

Jeder Schritt hinterlässt seinen Bericht auf dem Ticket

Öffnen Sie das Ticket eine Woche später, und der Lauf steht noch da: wer was getan hat, welches Verdict jedes Gate gelesen hat und warum die Arbeit weiterging. Weil die Schritte feststehen, können Sie jeden einzelnen messen, und eine Verbesserung, die Sie ins Playbook schreiben, gilt für jeden Lauf danach.

• Plan · PM-AgentPlan geschrieben, 5 TeilaufgabenBestanden
• Build · SE-Agent6 Dateien geändert, 14 Tests ergänztPR offen
• Review · Senior-AgentFehlender Test für eine abgelaufene KarteZurück zu Build
• Freigabe · SieFreigegeben, bereit zum MergeSie sind dran
• Test · QA-AgentAuf der Live-Site bestandenBestanden

Ein Modell pro Schritt und bekannte Kosten pro Ticket

Planung und Review können auf einem starken Modell laufen, während Routineschritte ein schnelles nehmen, die Kosten folgen also der Schwierigkeit. Ein Schritt nennt eine Effort-Stufe, Sie entscheiden, welches Modell hinter jeder Stufe steht, und die Seite des Laufs zeigt, was das ganze Ticket gekostet hat. Kadmo stellt Claude- und GPT-Modelle bereit und nimmt Ihre eigenen Schlüssel, wo Ihr Plan es erlaubt, und die Agenten laufen auf Kadmos Maschinen, in Ihrem Cloud-Konto oder auf Ihrem eigenen Server.

Fertige Playbooks für die übliche Arbeit

Jedes Konto beginnt mit einer eigenen Kopie der Playbooks, die Kadmo mitliefert. Ihre Admins stimmen sie im Editor ab, duplizieren eines, um es zu ändern, oder bauen ein neues auf einer leeren Leinwand.

Welches Playbook ein Ticket bekommt, folgt aus seinem Issue-Typ, ein Bug und eine Story nehmen also verschiedene Wege, ohne dass jemand wählt. Weisen Sie Kadmo ein Ticket in Jira, Linear oder Notion zu, schreiben Sie @kadmo darauf oder starten Sie einen Lauf aus Slack oder Teams, und das passende Playbook nimmt es auf.

So fängt es an

Es beginnt mit einem Gespräch. In 30 Minuten gehen wir durch, wie Ihr Team heute ein Ticket erledigt, und wählen den einen Prozess, den ein Playbook zuerst übernimmt. Der Pilot läuft auf Ihren eigenen Tickets, und seine Zahlen entscheiden, wie es weitergeht. Die Pläne mit Agenten und Playbooks stehen auf der Seite Preise.

• Gespräch · Sie und KadmoEin Prozess Ihres Teams, durchgegangen und abgesteckt30 Minuten
• Pilot · die AgentenEin Playbook bearbeitet echte Tickets aus Ihrem BacklogZwei Wochen
• Entscheidung · SieErledigte Tickets, Review-Verdicts und Kosten pro Ticket, nebeneinanderSie entscheiden
• Rollout · Ihr TeamWeitere Prozesse, eigene Playbooks, Agenten dort, wo Sie sie wollenLäuft

Einrichten

Öffnen Sie die Bibliothek unter Settings, duplizieren Sie einen Seed oder bauen Sie eines auf der Leinwand, leiten Sie jedes Verdict an seinem Gate, ordnen Sie Ihre Issue-Typen per Issue-Type-Routing zu und starten Sie einen Lauf von der Seite Tasks. Eine Regel unter Automations startet einen Lauf von allein, aus einem Tracker-Ereignis oder nach Zeitplan.

Fragen