Autonomiczny bot GitHuba, który wie, kiedy nic nie robić
Przepis na agenta GitHuba z cookbooka spina triage, review PR-ów i automatyczne poprawki bugów w GitHub Actions na OpenCode i Muse Spark. Najcenniejsze w nim są jednak bezpieczniki.
Co ten bot właściwie robi
Przepis buduje autonomicznego bota w GitHub Actions z czterema zadaniami: triage issue, review pull requestów, wykrywanie „AI slopu“ i PR-y z poprawkami bugów — całość działa na OpenCode z Muse Spark jako modelem, dzięki temu, że Model API bez żadnych przeróbek wpina się w istniejące agentowe CLI. Wszystko kręci się w Actions twojego własnego repozytorium, nie na czyjejś infrastrukturze.
Powściągliwość jako wymaganie projektowe
Tym, co odróżnia ten przepis od naiwnego „podepnijmy LLM do webhooków“, jest to, jak duża jego część dotyczy niedziałania. Agent od review ma jawną listę „NOT slop“ — kryteria zmian, których nie wolno mu oflagować, żeby nie krzyczał „wilk!“ przy w pełni uzasadnionych wzorcach. Triage nigdy nie zamyka issue; to zostaje decyzją człowieka. Agent od bugfixów nie otwiera PR-a, jeśli najpierw nie zdoła zreprodukować błędu. Meta stawia sprawę wprost: nadgorliwe odpalanie się to tryb awarii, a nie drobiazg.
Jest też dyscyplina cytowania: funkcja Q&A może odpowiadać wyłącznie na podstawie plików repozytorium, do każdego twierdzenia musi dołączyć odnośnik do pliku i sekcji, a gdy odpowiedzi w repo nie ma — odmówić zamiast konfabulować. Dla bota, który wypowiada się głosem twojego projektu w publicznych wątkach, „ugruntowane albo cisza“ to jedyna polityka, którą da się obronić.
AGENTS.md: jeden plik, by wszystkimi rządzić
Każdy agent z przepisu automatycznie wczytuje wspólny AGENTS.md z kontekstem repozytorium — dzięki czemu agenci nie zgadują konwencji — oraz z regułami bezpieczeństwa, które wszyscy dziedziczą. Meta nazywa go najważniejszym plikiem do dostosowania pod własny projekt: dostarczona wersja to rozpisany przykład dla stacku Python/pytest/uv, do przepisania pod twój, ale z sekcją SECURITY zachowaną słowo w słowo.
Wdrażaj etapami, na uprawnienia do zapisu trzeba zasłużyć
Wskazówki wdrożeniowe to czterostopniowa drabina zaufania. Etap pierwszy: review PR-ów i triage, tylko do odczytu — sprawdzasz jakość na prawdziwym ruchu przy zerowym promieniu rażenia. Etap drugi: jawne komendy /oc, żeby maintainerzy uruchamiali pracę agenta świadomie. Etap trzeci: automatyczne naprawianie bugów bramkowane etykietami. Etap czwarty: utwardzanie — branch protection, CODEOWNERS, bramki CI. Dostęp do zapisu zdobywa się historią dobrych decyzji, nigdy nie dostaje pierwszego dnia. To ta sama filozofia, co we własnej historii audytowalności Muse Code: autonomia rośnie tylko tak szybko, jak weryfikacja.
Jak Meta to zwalidowała
Detal wart skopiowania: przepis zwalidowano, puszczając prawdziwych agentów w trybie headless na oskryptowane scenariusze issue i PR-ów — odtwarzając prompt z Action z podstawionym fałszywym gh na PATH, żeby nic nie tknęło żywego repozytorium — a potem czytając, co wyprodukowali. Testuj swojego bota tak, jak testowałbyś każdą niezaufaną automatyzację: w słoiku, zanim spotka produkcję. Gotowy do uruchomienia przepis znajdziesz w cookbooku wśród use case’ów.