Ein autonomer GitHub-Bot, der weiß, wann er die Finger stillhalten muss
Das GitHub-Agent-Rezept aus dem Cookbook verdrahtet Issue-Triage, PR-Review und automatische Bugfixes mit GitHub Actions — auf OpenCode und Muse Spark. Das eigentlich Übertragbare daran sind die Leitplanken.
Was der Bot macht
Das Rezept baut einen autonomen Bot auf Basis von GitHub Actions mit vier Jobs: Issue-Triage, Pull-Request-Review, Erkennung von KI-Slop und automatisch erstellte Bugfix-PRs. Als Harness dient OpenCode, als Modell Muse Spark — angebunden über die Drop-in-Kompatibilität der Model API mit bestehenden Agent-CLIs. Alles läuft in den Actions deines eigenen Repositories, nicht auf fremder Infrastruktur.
Zurückhaltung als Design-Anforderung
Was dieses Rezept von einem naiven „LLM an Webhooks klemmen“-Projekt unterscheidet: Ein großer Teil davon dreht sich darum, wann der Bot nicht handeln soll. Der Review-Agent führt eine explizite „NOT slop“-Liste — Kriterien für Änderungen, die er nicht anmeckern darf, damit er bei legitimen Patterns keinen Fehlalarm auslöst. Die Triage schließt niemals Issues; das bleibt eine menschliche Entscheidung. Und der Bugfix-Agent öffnet keinen PR, wenn er den Bug nicht vorher reproduzieren konnte. Metas Haltung dazu ist unmissverständlich: Übertriggern gilt als Failure Mode, nicht als Schönheitsfehler.
Dazu kommt eine Zitierpflicht: Die Q&A-Funktion darf nur aus Repository-Dateien antworten, muss ihre Aussagen mit Datei- und Abschnittsangabe belegen und muss passen, wenn die Antwort nicht im Repo steht. Für einen Bot, der in öffentlichen Threads mit der Stimme deines Projekts spricht, ist „belegt oder still“ die einzig vertretbare Policy.
AGENTS.md: eine Datei für die ganze Flotte
Jeder Agent im Rezept lädt automatisch eine gemeinsame AGENTS.md mit Repository-Kontext — damit niemand Konventionen raten muss — und den Security-Regeln, die alle erben. Meta nennt sie die mit Abstand wichtigste Datei, die du an dein eigenes Projekt anpassen solltest: Die mitgelieferte Version ist ein durchgerechnetes Beispiel für einen Python/pytest/uv-Stack, gedacht zum Umschreiben für deinen Stack — nur der SECURITY-Abschnitt bleibt wortwörtlich stehen.
In Phasen ausrollen, Schreibrechte verdienen
Die Deployment-Anleitung ist eine vierstufige Vertrauensleiter. Phase eins: PR-Review und Triage, rein lesend — Qualität an echtem Traffic validieren, ohne jeden Blast Radius. Phase zwei: explizite /oc-Kommandos, sodass Maintainer den Agenten bewusst anstoßen. Phase drei: automatisches Bugfixing, freigeschaltet über Labels. Phase vier: Härtung — Branch Protection, CODEOWNERS, CI-Gates. Schreibzugriff wird über eine Erfolgsbilanz verdient und niemals am ersten Tag verteilt. Das ist dieselbe Philosophie wie bei Muse Codes eigener Auditierbarkeits-Story: Autonomie wächst nur so schnell, wie die Verifikation mitwächst.
Wie Meta das validiert hat
Ein Detail zum Nachmachen: Meta hat das Rezept validiert, indem die echten Agenten headless gegen geskriptete Issue- und PR-Szenarien liefen — der Prompt der Action wurde nachgebaut, ein Fake-gh lag im PATH, sodass kein echtes Repository angefasst wurde — und dann wurde gelesen, was dabei herauskam. Teste deinen Bot so, wie du jede nicht vertrauenswürdige Automatisierung testen würdest: im Einmachglas, bevor sie Produktion sieht. Das lauffähige Rezept findest du im Cookbook unter Use Cases.