Hermify
Zurück zum Blog
HermesGitHubAI AgentsAutomation

Hermes Agent + GitHub Actions: Automatisieren Sie Ihre Repos

Drei konkrete Rezepte, mit denen Hermes Agent auf Ihre GitHub-Repos aufpasst: CI-Fehlertriage, nächtliche PR-Zusammenfassungen und das Aufräumen veralteter Issues.

Von Hermify Team||8 Min. Lesezeit
Eine dunkle Code-Editor-Ansicht, in der das Hermes-Logo und der GitHub-Octocat durch eine leuchtend grüne Linie verbunden sind, mit der Bildunterschrift „GitHub Automation“

Ihre Repos brauchen einen Helfer, kein weiteres Dashboard

Wenn Sie auch nur zwei oder drei GitHub-Repos pflegen, ist Ihnen wahrscheinlich dasselbe Muster aufgefallen: Der Großteil der Arbeit besteht nicht aus dem Schreiben von Code. Es geht darum, CI-Fehler zu triagieren, einen Blick auf PR-Diffs zu werfen, die Sie gestern geöffnet haben, veraltete Issues zu schließen, die niemand anfassen wird, und sich selbst eine Montagmorgen-Zusammenfassung darüber zu schicken, was am Wochenende passiert ist.

Genau in diesem Teil der Repo-Pflege ist KI wirklich gut. Nicht beim kreativen Programmieren, sondern bei der routinemäßigen Verwaltungsarbeit. Und Hermes Agent wurde mit seinem cron-Scheduler, seinem Webhook-Listener und seinem nativen Zugriff auf die GitHub-CLI genau dafür gebaut.

Dieser Leitfaden zeigt drei konkrete Rezepte, die Sie noch heute in Ihr eigenes Hermes-Setup übernehmen können. Jedes davon löst ein echtes Problem, das Sie wahrscheinlich jede Woche spüren.

  • Ein Agent zur CI-Fehlertriage, der innerhalb von Minuten nach einem roten Status eine Diagnose im PR veröffentlicht
  • Eine nächtliche PR-Zusammenfassung, die um 21 Uhr in Ihrem Telegram oder Discord landet
  • Eine wöchentliche Triage veralteter Issues, die einen Schließungskommentar für Issues entwirft, die seit 60 Tagen niemand angefasst hat

Am Ende sollten Sie in der Lage sein, jedes davon in einer einzigen Sitzung einzurichten. Falls Sie es noch nicht getan haben: Starten Sie mit Hermify und erhalten Sie eine verwaltete Hermes-Instanz, bei der die gesamte GitHub-Verdrahtung bereits eingerichtet ist.

Warum gerade Hermes für die Repo-Automatisierung

Es gibt zahlreiche vorgefertigte GitHub Actions und Marketplace-Bots, die einzelne Aufgaben erledigen: einer für Code-Reviews, einer für veraltete Issues, einer für Release-Notes. Das Problem beim Zusammenstückeln ist, dass sich keiner von ihnen irgendetwas merkt. Jeder Durchlauf beginnt bei null. Jeder benötigt seine eigene Konfiguration. Jeder kommuniziert mit einem anderen externen Dienst.

Hermes unterscheidet sich auf drei nützliche Arten:

  • Ein Agent, viele Skills. Eine einzige Hermes-Instanz kann PRs prüfen, Issues triagieren, cron-Jobs ausführen und spontane Fragen über Telegram beantworten. Sie konfigurieren ihn einmal, Sie bringen ihm einmal etwas bei, er verbessert sich einmal.
  • Persistentes Gedächtnis. Wenn Hermes letzte Woche einen instabilen Test bei PR #312 markiert hat, erinnert es sich daran, wenn derselbe Test heute bei PR #340 instabil läuft. Genau diesen Kontext können die meisten Marketplace Actions nicht halten.
  • cron in einfachem Deutsch. Sie schreiben nicht 0 9 * * 1-5. Sie schreiben „Schicke mir jeden Werktag um 9 Uhr eine PR-Zusammenfassung“, und Hermes erstellt den Skill und den Zeitplan für Sie.

Hermes Agent prüft einen GitHub-Pull-Request in einem Terminal

Für einen tieferen Blick auf die zugrunde liegenden Bausteine lesen Sie unseren Beitrag über Hermes-Gedächtnis und Skills.

Rezept 1: Agent zur CI-Fehlertriage

Problem. Ein Test schlägt bei einem PR fehl. Sie sehen das rote X. Sie klicken in Actions, scrollen durch das Log, finden heraus, welcher Schritt in die Luft geflogen ist, entscheiden, ob es sich um einen instabilen Test oder eine echte Regression handelt, und schreiben einen Kommentar. Dieser Hin-und-Her-Vorgang dauert jedes Mal 5 bis 15 Minuten. In einer arbeitsreichen Woche mit mehreren Repos summiert sich das zu Stunden.

Was Hermes tut. Ein Webhook wird bei check_run mit dem Status „completed“ und conclusion: failure ausgelöst. Hermes ruft das Log des fehlgeschlagenen Jobs über die GitHub-CLI ab, identifiziert den fehlgeschlagenen Schritt und die wahrscheinlichste Grundursache und veröffentlicht im zugehörigen PR einen Kommentar mit einer einabsätzigen Diagnose und einem Vorschlag für den nächsten Schritt (erneut ausführen, lokal beheben, als bekannt instabil markieren).

Setup-Übersicht.

  1. Fügen Sie in Ihrer Hermes-Konfiguration ein Webhook-Abonnement für check_run.completed für die Repos hinzu, die Ihnen wichtig sind.
  2. Fügen Sie einen Skill namens github-ci-triage mit einem Prompt in etwa folgender Art hinzu: „Rufe das Log des fehlgeschlagenen Jobs mit gh run view --log-failed ab. Identifiziere den fehlgeschlagenen Schritt und die erste Stack-Trace- oder Fehlerzeile. Wenn der Fehler einem bekannten instabilen Muster im Gedächtnis entspricht, kennzeichne den Kommentar als ‚wahrscheinlich instabil‘. Andernfalls fasse die Grundursache in einem Absatz zusammen und schlage die kleinstmögliche Korrektur vor.“
  3. Verweisen Sie den Webhook-Handler auf diesen Skill und weisen Sie ihn an, das Ergebnis mit gh pr comment als PR-Kommentar zu liefern.

Lesen Sie den Kommentar beim ersten Durchlauf kurz durch und geben Sie ihm entweder einen Daumen nach oben (was Hermes als bestätigte gute Diagnose speichert) oder korrigieren Sie ihn. Nach einigen Runden werden die Diagnosen schärfer, weil Hermes Ihre Codebasis, Ihre CI-Eigenheiten und die chronisch instabilen Testdateien lernt.

Rezept 2: Nächtliche PR-Zusammenfassung

Problem. Sie haben zu jedem Zeitpunkt zwischen 3 und 15 offene PRs über persönliche Projekte, Arbeits-Repos und die OSS-Projekte verteilt, die Sie pflegen. Am Freitagnachmittag haben Sie keine Ahnung mehr, welche sich bewegt haben, welche auf Sie warten und welche auf jemand anderen warten.

Was Hermes tut. Jeden Werktag um 21 Uhr Madrider Zeit (oder welche Zeitzone Sie auch festlegen) führt Hermes die GitHub-CLI aus, um offene PRs aufzulisten, gruppiert sie nach Status (wartet auf Review, wartet auf CI, Entwurf, mergebar) und liefert eine formatierte Zusammenfassung an Ihr Telegram oder Discord.

Eine Zusammenfassung sieht so aus:

PR digest - 18 May 2026

WAITING ON YOU (3):
- albertoaquinodev/hermes-up #421 "fix: revalidate blog index" - review requested 4d ago
- albertoaquinodev/hermes-up #418 "feat: BYOK provider snapshot" - your review is the last blocker
- nousresearch/hermes-agent #2104 "docs: add cron examples" - small docs PR

WAITING ON OTHERS (2):
- albertoaquinodev/hermes-up #420 - blocked on reviewer for 2d
- nousresearch/hermes-agent #2099 - CI red, owner is fixing

MERGEABLE NOW (1):
- albertoaquinodev/hermes-up #422 - all green, ready to merge

Setup-Übersicht.

  1. Erstellen Sie einen cron-Job mit dem Prompt: „Liste jeden Werktag um 21:00 die offenen PRs in albertoaquinodev/* und nousresearch/* mit gh pr list auf. Gruppiere nach Status. Schicke das an mein Telegram.“
  2. Hermes parst den natürlichsprachlichen Zeitplan in den cron-Ausdruck 0 21 * * 1-5 und registriert den Skill.
  3. Verbinden Sie ein Telegram- oder Discord-Lieferziel, falls Sie das noch nicht getan haben.

Das Ganze dauert etwa 10 Minuten. Sobald es läuft, kostet es ungefähr $0,02 bis $0,05 pro nächtlichem Durchlauf auf Sonnet, je nachdem, wie viele PRs offen sind.

Zum Vergleich: Das entsprechende Setup mit zusammengestückelten Actions und Slack-Apps kostet ein ganzes Wochenende und geht jedes Mal kaputt, wenn GitHub seine API ändert.

Rezept 3: Wöchentliche Triage veralteter Issues

Problem. Issues häufen sich an. Manche werden in einem parallelen PR behoben, und niemand schließt sie. Manche werden gemeldet, der Nutzer verschwindet, und das Issue bleibt für immer offen. Manche sind Duplikate. Den Rückstand manuell durchzugehen ist die Art von Arbeit, die niemand macht.

Was Hermes tut. Jeden Montagmorgen listet Hermes alle Issues ohne Aktivität in 60 Tagen auf, liest den Issue-Text und etwaige Kommentare, entscheidet sich für eine von vier Aktionen und entwirft (je nachdem, wie viel Autonomie Sie ihm geben) entweder einen Kommentar, den Sie freigeben können, oder veröffentlicht den Kommentar direkt.

Die vier Aktionen:

  • Als behoben schließen. Der referenzierte Fehler scheint in einem aktuellen Commit oder Release behoben zu sein. Hermes veröffentlicht einen höflichen Schließungskommentar mit dem verknüpfenden Commit.
  • Als veraltet schließen. Der Autor wurde vor mehr als 30 Tagen um weitere Informationen gebeten und hat nie geantwortet.
  • Priorität anheben. Das Issue ist weiterhin relevant, hat Daumen nach oben von anderen Nutzern und verdient eine Label-Änderung.
  • In Discussion umwandeln. Das Issue ist ein Feature-Wunsch, der in Discussions gehört, nicht in Issues.

Ein Terminal, das geplante Hermes-Agent-Jobs zeigt, die gegen ein GitHub-Repository laufen

Setup-Übersicht.

  1. Erstellen Sie einen cron-Job: „Triagiere jeden Montag um 10 Uhr veraltete Issues in meinen Repos. Entwirf Kommentare, aber veröffentliche sie noch nicht.“
  2. Hermes erstellt einen Skill, der gh issue list --state open --search 'updated:<2026-03-18' ausführt (Datum zur Laufzeit berechnet), jedes Issue liest und sich für die Aktion entscheidet.
  3. Die Entwürfe landen in einer einzigen Telegram-Nachricht oder, falls Sie das bevorzugen, als PR-artige Zusammenfassung, die Sie prüfen können.

Nach einigen Wochen überwachter Durchläufe können Sie entweder auf automatisches Veröffentlichen umschalten (Hermes handelt direkt) oder es für immer im Entwurfsmodus belassen. So oder so hört Ihr Rückstand auf zu wachsen.

Wo Hermes aufhört und wo Sie übernehmen

Die ehrliche Version dieser Geschichte ist, dass Hermes bei den routinemäßigen 80 % der Repo-Pflege hervorragend ist, und Sie weiterhin einen Menschen für die 20 % wollen, die Urteilsvermögen erfordern: zu entscheiden, ob ein instabiler CI-Test tatsächlich ein echter Fehler ist, den Breaking Change in einer API zu erkennen, einem Nutzer zu sagen, dass sein Feature-Wunsch außerhalb des Rahmens liegt.

Der ganze Sinn des obigen Setups besteht darin, die 80 % von Ihrem Teller zu räumen, damit Sie Zeit für die 20 % haben. Für eine andere Variante derselben Idee lesen Sie unseren Beitrag über das Selbst-Hosten eines KI-Agenten mit Docker, der die Infrastrukturseite des langfristigen Betriebs von Hermes behandelt.

Probieren Sie es diese Woche aus

Wenn Sie Hermes bereits selbst hosten, sind die drei obigen Rezepte ungefähr ein Abend Arbeit zum Einrichten. Falls nicht, ist der schnellste Weg Starten Sie mit Hermify: Eine verwaltete Hermes-Instanz wird mit der bereits konfigurierten GitHub-CLI, dem Webhook-Listener und dem cron-Scheduler ausgeliefert. Sie fügen Ihr Repo-Token hinzu und schreiben den cron-Satz in einfachem Deutsch.

Das Repo-Babysitter-Setup ist die Art von Sache, bei der man sich fragt, warum es niemand früher gebaut hat. Dann erinnert man sich: Die meisten „KI für Entwickler“-Tools sind für die 20 % des Code-Schreibens gebaut, nicht für die 80 % der Verwaltung. Hermes nimmt sich die 80 % vor.

Quellen

Betreiben Sie Ihren eigenen Hermes Agent

Bringen Sie Ihren API-Schlüssel mit, verbinden Sie Telegram und erhalten Sie in 60 Sekunden einen selbstlernenden KI-Agenten.

Loslegen