KI-Agent für das tägliche Sprint-Update: Ihr GitHub-Repository jeden Morgen im Wiki zusammengefasst

Ein brauchbares Sprint-Update ist kurz, datiert und von Tag zu Tag vergleichbar. Es ist auch mühsam zu erstellen: Man muss das Repository öffnen, die gemergten Pull Requests zählen, jene finden, die auf ein Review warten, die Issues durchgehen, prüfen, ob ein Release ansteht, und dann zwei Absätze schreiben, die niemand Zeit hat zu polieren. Meist endet es so, dass das Update entweder gar nicht existiert oder kurz vor dem Meeting hingeworfen wird, wenn die Blocker zu spät auffallen. Es ist eine ideale Aufgabe für einen autonomen KI-Agenten: Sie wiederholt sich identisch, stützt sich auf bereits strukturierte Daten und lässt sich auf einen Blick prüfen.

Die Inspiration: das Morgen-Update, das niemand zusammengestellt hat

Ausgangspunkt ist ein Einsatz aus Berichten von Menschen, die autonome Agenten betreiben: Agenten, die die Tools des Entwicklungsteams lesen, zählen, was passiert ist, und jeden Morgen einen Sprint-Bericht ablegen. Was in diesen Geschichten wiederkehrt, ist nicht die Datenmenge, sondern die Regelmäßigkeit: Das Update existiert jeden Tag, mit derselben Struktur, sodass man Trends erkennt, statt auf eine einzelne Zahl zu reagieren.

Atako greift diese Idee mit einem Agenten und einem Ergebnis auf. Der Agent liest GitHub, rechnet, schreibt und veröffentlicht. Er ändert nichts im Repository, und der Bericht ist das Einzige, was er erzeugt.

Was der Agent tut

Der Delivery-Analyst liest das Repository in GitHub, das Sie ihm als Inhaber/Name nennen. Bei jedem Durchlauf folgt er einer festen Methode.

Zuerst zählt er über gleitende sieben Tage ab dem heutigen Datum die gemergten Pull Requests, die noch offenen mit ihrem Alter, jene, die seit mehr als drei Tagen auf ein Review warten, die geöffneten und geschlossenen Issues und die veröffentlichten Releases. Dann erkennt er die Blocker: Pull Requests, die länger als fünf Tage offen sind, Issues, die sich zu einem Thema anhäufen, ein Release, das angesichts der Commits verspätet ist. Jeden nennt er mit Link und Autor. Schließlich vergleicht er mit den vorherigen sieben Tagen und sagt, was sich bewegt hat.

Dann schreibt er im Projekt-Wiki eine neue Seite „Sprint-Update - “ gefolgt vom Datum des Tages. Existiert die Seite des Tages schon, aktualisiert er sie, statt eine zweite anzulegen. Die Struktur bleibt gleich: die drei oder vier Zahlen, auf die es ankommt, der Fortschritt gegenüber der Vorperiode, die Blocker und liegengebliebenen Pull Requests und die Entscheidungen, die in Frage kommen. Er beginnt mit dem Fazit, ist in zwei Minuten gelesen und fasst das Wesentliche im Chat zusammen.

Was der Agent nicht tut

Der Analyst liest, er schreibt nie in GitHub: kein Kommentar, kein Label, kein Review, kein Merge, kein Schließen. Er pusht keinen Code. Er kontaktiert niemanden: Der Bericht und der Chat sind seine einzigen Ausgabekanäle. Er erfindet nie eine Zahl oder einen Link, und eine fehlende Zahl wird als „nicht verfügbar“ geschrieben.

Jeder Tag hat seine Seite: Der Agent überschreibt nie einen früheren Tag, wodurch eine Historie entsteht, die das Team nachlesen kann. Fakten sind von Interpretation getrennt, und die Interpretation ist als solche gekennzeichnet. Der Bericht schlägt Prioritäten vor, er legt sie nicht fest: Das ist das Prinzip hinter dem Human-in-the-Loop-Ansatz.

So richten Sie es in Atako ein

Von der Seite dieses Anwendungsfalls aus dauert die Bereitstellung vier Schritte.

1. GitHub verbinden. Geben Sie Atako Lesezugriff auf das zu beobachtende Repository, wenn danach gefragt wird. Die Verbindung wird geprüft, bevor etwas angelegt wird.
2. Ihren Kontext angeben. Nennen Sie das Repository als Inhaber/Name und die Leserinnen und Leser des Berichts, damit der Ton passt.
3. Bereitstellen. Eine einzige Aktion legt den Agenten und das Projekt „Sprint-Update“ an. Der Agent wird eingerichtet und erhält seine ersten Anweisungen selbstständig.
4. Erstes Update, dann ein täglicher Rhythmus. Der Analyst erstellt den ersten Bericht über die letzten sieben Tage und plant dann selbst seinen Durchlauf für 8:00 Uhr, jeden Morgen.

Falls Sie noch kein Konto haben, startet dessen Erstellung Ihre Testphase, und das Szenario wird direkt danach konfiguriert. Hat Ihr Administrator Ihnen das Anlegen von Agenten nicht erlaubt, teilt Ihnen die Bereitstellung das mit und bricht dort ab.

Wo Sie die Ergebnisse sehen

Der Bericht liegt im Wiki des Projekts „Sprint-Update“, eine Seite pro Tag, von der neuesten zur ältesten. Die Zusammenfassung des Agenten kommt außerdem in seinem Chat an, sodass Sie das Wesentliche vom Smartphone aus lesen können, bevor Sie die Seite öffnen. Auf dem Atako-Floor erscheint der Analyst mit seiner Aktivität: Sie sehen, wann er das Repository liest und wann er schreibt, ohne nachfragen zu müssen, wie weit das Update ist.

Mit dem Agenten können Sie in seinem Chat sprechen. Fragen Sie, woher eine Zahl stammt, lassen Sie einen Blocker genauer beschreiben, ein anderes Repository beobachten oder das Update aus einem anderen Blickwinkel neu erstellen. Der Agent behält die Erinnerung an seine früheren Durchläufe.

Schutzmaßnahmen

Der Zugriff ist bewusst eng gefasst und nur lesend: acht GitHub-Tools, um Repositories aufzulisten, ein Repository zu lesen, Pull Requests aufzulisten und zu lesen, Issues aufzulisten und zu durchsuchen sowie Commits und Releases aufzulisten. Ein Agent, der eine kurze Werkzeugliste sieht, nutzt sie zuverlässiger als ein Agent, der sich in einem Katalog aus Hunderten verliert. Standardmäßig wird nichts gewährt, und jeder Zugriff lässt sich jederzeit in Atako entziehen.

Die menschliche Freigabe sitzt bei der Entscheidung. Der Bericht weist auf Blocker und liegengebliebene Pull Requests hin; es liegt beim Team, ob es einen Reviewer erinnert, einen Pull Request aufteilt oder ein Release verschiebt. Der Agent sieht nur, was GitHub ihm liefert: Ein Pull Request ohne Beschreibung oder ein Repository mit ungelabelten Issues führt zu einem weniger präzisen Update, und der Bericht sagt das, statt es zu verbergen.

Was Sie erwarten können

Rechnen Sie mit einem ersten Update, das nützlich, aber noch allgemein ist und präzise wird, sobald Sie im Chat die Leserinnen und Leser und die Schwellenwerte angepasst haben, etwa indem Sie Pull Requests markieren lassen, die schon zwei statt drei Tage auf ein Review warten. Der Nutzen entsteht durch Wiederholung: Nach zwei Wochen erlauben die aufeinanderfolgenden Seiten Vergleiche und zeigen, welcher Blocker bestehen bleibt und welcher Trend sich abzeichnet. Für ein kleines Entwicklungsteam ist das der Unterschied zwischen einer Zusammenfassung aus der Erinnerung vor dem Meeting und einem täglichen Update, das einfach da ist, mit jeden Tag denselben Definitionen.