Agent AI do codziennego raportu ze sprintu: Twoje repozytorium GitHub streszczone co rano w wiki

Przydatny raport ze sprintu jest krótki, datowany i porównywalny z dnia na dzień. Jest też żmudny w przygotowaniu: trzeba otworzyć repozytorium, policzyć scalone pull requesty, znaleźć te czekające na review, przejrzeć issues, sprawdzić, czy zbliża się wydanie, i napisać dwa akapity, których nikt nie ma czasu dopracować. Zwykle raportu nie ma wcale albo powstaje na szybko przed spotkaniem, a blokady wychodzą na jaw za późno. To idealne zadanie dla autonomicznego agenta AI: powtarza się bez zmian, opiera się na danych już uporządkowanych i można je sprawdzić jednym spojrzeniem.

Inspiracja: poranny raport, którego nikt nie zestawiał

Punktem wyjścia jest zastosowanie opisane w relacjach osób korzystających z autonomicznych agentów: agenci czytają narzędzia zespołu technicznego, liczą, co się wydarzyło, i co rano zostawiają raport ze sprintu. W tych relacjach powraca nie ilość danych, lecz regularność: raport istnieje codziennie, w tej samej strukturze, dzięki czemu widać trendy, zamiast reagować na pojedynczą liczbę.

Atako podejmuje ten pomysł z jednym agentem i jednym wynikiem. Agent czyta GitHub, liczy, pisze i publikuje. Niczego nie zmienia w repozytorium, a raport jest jedyną rzeczą, jaką tworzy.

Co robi agent

Analityk dostaw czyta repozytorium w GitHub, wskazane przez Ciebie w formie właściciel/nazwa. Przy każdym przebiegu stosuje stałą metodę.

Najpierw liczy z siedmiu ostatnich dni, licząc od dzisiejszej daty, pull requesty scalone, wciąż otwarte wraz z wiekiem, czekające na review dłużej niż trzy dni, issues otwarte i zamknięte oraz opublikowane wydania. Potem wskazuje blokady: pull requesty otwarte dłużej niż pięć dni, issues narastające wokół jednego tematu, wydanie opóźnione w świetle commitów. Każdą podaje z linkiem i autorem. Na koniec porównuje z poprzednimi siedmioma dniami i mówi, co się zmieniło.

Następnie pisze w wiki projektu nową stronę „Raport ze sprintu - ” z datą dnia. Jeśli strona dnia już istnieje, aktualizuje ją zamiast tworzyć drugą. Struktura się nie zmienia: trzy lub cztery liczby, które się liczą, postęp względem poprzedniego okresu, blokady i pull requesty, które się wloką, oraz decyzje do rozważenia. Zaczyna od wniosku, czyta się go w dwie minuty, a najważniejsze streszcza na czacie.

Czego agent nie robi

Analityk czyta, nigdy nie zapisuje w GitHub: żadnego komentarza, etykiety, review, scalenia ani zamknięcia. Nie wypycha kodu. Nie kontaktuje się z nikim: raport i czat to jego jedyne kanały wyjścia. Nigdy nie zmyśla liczby ani linku, a brakującą wartość zapisuje jako „niedostępne”.

Każdy dzień ma swoją stronę: agent nigdy nie nadpisuje wcześniejszego dnia, więc zostaje historia, do której zespół może wracać. Fakty są oddzielone od interpretacji, a interpretacja jest oznaczona. Raport proponuje priorytety, ale ich nie narzuca: to zasada projektowania z weryfikacją przez człowieka.

Jak to skonfigurować w Atako

Ze strony tego przypadku użycia wdrożenie składa się z czterech kroków.

1. Połącz GitHub. Daj Atako dostęp do odczytu repozytorium, które ma być śledzone, gdy o to poprosi. Połączenie jest sprawdzane, zanim cokolwiek zostanie utworzone.
2. Podaj swój kontekst. Wskaż repozytorium w formie właściciel/nazwa oraz czytelników raportu, aby dopasować ton.
3. Wdróż. Jedna akcja tworzy agenta i projekt „Raport ze sprintu”. Agent jest przygotowywany i sam dostaje pierwsze polecenia.
4. Pierwszy raport, potem codzienny rytm. Analityk przygotowuje pierwszy raport z ostatnich siedmiu dni, a następnie sam planuje swój przebieg na 8:00, każdego ranka.

Jeśli nie masz jeszcze konta, jego utworzenie rozpoczyna okres próbny, a scenariusz konfiguruje się zaraz potem. Jeśli administrator nie dał Ci uprawnień do tworzenia agentów, wdrożenie poinformuje o tym i się zatrzyma.

Gdzie zobaczyć wyniki

Raport znajduje się w wiki projektu „Raport ze sprintu”, jedna strona dziennie, od najnowszej do najstarszej. Streszczenie agenta trafia też na jego czat, więc najważniejsze przeczytasz na telefonie, zanim otworzysz stronę. Na planszy Atako analityk pojawia się ze swoją aktywnością: widać, kiedy czyta repozytorium, a kiedy pisze, bez pytania, na jakim etapie jest raport.

Możesz z nim rozmawiać na jego czacie. Zapytaj, skąd pochodzi liczba, poproś o opis blokady, o śledzenie innego repozytorium albo o przygotowanie raportu w innym ujęciu. Agent pamięta swoje poprzednie przebiegi.

Zabezpieczenia

Dostęp jest celowo wąski i tylko do odczytu: osiem narzędzi GitHub do listowania repozytoriów, czytania repozytorium, listowania i czytania pull requestów, listowania i wyszukiwania issues oraz listowania commitów i wydań. Agent, który widzi krótką listę narzędzi, używa ich pewniej niż ten, który gubi się w katalogu setek. Domyślnie nic nie jest przyznane, a każdy dostęp można w każdej chwili cofnąć w Atako.

Weryfikacja przez człowieka dotyczy decyzji. Raport wskazuje blokady i pull requesty, które się wloką; to zespół wybiera, czy ponaglić recenzenta, podzielić pull request czy przesunąć wydanie. Agent widzi tylko to, co daje mu GitHub: pull request bez opisu lub repozytorium z issues bez etykiet da mniej precyzyjny raport, a raport to powie zamiast ukrywać.

Czego się spodziewać

Spodziewaj się pierwszego raportu przydatnego, ale jeszcze ogólnego, który staje się precyzyjny, gdy na czacie dostosujesz czytelników i progi, na przykład prosząc o oznaczanie pull requestów czekających na review dwa dni zamiast trzech. Wartość daje powtarzalność: po dwóch tygodniach kolejne strony pozwalają porównywać i widzieć, która blokada się utrzymuje i jaki trend się rysuje. Dla małego zespołu technicznego to różnica między podsumowaniem odtwarzanym z pamięci przed spotkaniem a codziennym raportem, który po prostu istnieje, z tymi samymi definicjami każdego dnia.