Hermes Agent + GitHub Actions: Automate Your Repos

Your Repos Need a Sidekick, Not Another Dashboard

If you maintain even two or three GitHub repos, you have probably noticed the same pattern: most of the work is not writing code. It is triaging CI failures, glancing at PR diffs you opened yesterday, closing stale issues nobody is going to touch, and sending yourself a Monday morning summary of what happened over the weekend.

This is the part of repo maintenance that AI is genuinely good at. Not the creative coding, the routine custodial work. And Hermes Agent, with its cron scheduler, webhook listener, and native GitHub CLI access, was built for exactly this.

This guide shows three concrete recipes you can copy into your own Hermes setup today. Each one solves a real problem you probably feel every week.

• A CI failure triage agent that posts a diagnosis on the PR within minutes of red
• A nightly PR digest that lands in your Telegram or Discord at 9pm
• A weekly stale-issue triage that drafts a closing comment for issues nobody has touched in 60 days

By the end you should be able to set up any of these in a single sitting. If you have not yet, Get started with Hermify gets you a managed Hermes instance with all the GitHub plumbing already wired.

Why Hermes For Repo Automation Specifically

There are plenty of pre-built GitHub Actions and Marketplace bots that do single tasks: one for code review, one for stale issues, one for release notes. The problem with stitching them together is that none of them remember anything. Each run starts from zero. Each one needs its own configuration. Each one talks to a different external service.

Hermes is different in three useful ways:

• One agent, many skills. A single Hermes instance can review PRs, triage issues, run cron jobs, and answer ad-hoc questions over Telegram. You configure it once, you teach it once, it improves once.
• Persistent memory. When Hermes flagged a flaky test on PR #312 last week, it remembers when the same test flakes on PR #340 today. This is the kind of context most Marketplace Actions cannot keep.
• Plain-English cron. You do not write 0 9 * * 1-5. You write "every weekday at 9am send me a PR digest" and Hermes generates the skill and the schedule for you.

For a deeper look at the underlying primitives, see our post on Hermes memory and skills.

Recipe 1: CI Failure Triage Agent

Problem. A test fails on a PR. You see the red X. You click into Actions, scroll the log, figure out which step blew up, decide whether it is a flake or a real regression, and write a comment. That round trip takes 5 to 15 minutes every time. Over a busy week with multiple repos it is hours.

What Hermes does. A webhook fires on check_run completed with conclusion: failure. Hermes fetches the failing job log via the GitHub CLI, identifies the failing step and the most plausible root cause, and posts a comment on the associated PR with a one-paragraph diagnosis and a suggested next step (re-run, fix locally, mark as known-flaky).

Setup outline.

1. In your Hermes config, add a webhook subscription to check_run.completed for the repos you care about.
2. Add a skill called github-ci-triage with a prompt along the lines of: "Fetch the failing job log with gh run view --log-failed. Identify the failing step and the first stack trace or error line. If the error matches a known flaky pattern in memory, label the comment as 'likely flake'. Otherwise summarize the root cause in one paragraph and suggest the smallest fix."
3. Point the webhook handler at this skill and tell it to deliver the result as a PR comment using gh pr comment.

The first time it runs, give the comment a quick read and either thumbs-up it (which Hermes stores as a confirmed good diagnosis) or correct it. After a few rounds the diagnoses get sharper because Hermes is learning your codebase, your CI quirks, and which test files are chronic flakes.

Recipe 2: Nightly PR Digest

Problem. You have between 3 and 15 open PRs at any given time across personal projects, work repos, and the OSS projects you maintain. By Friday afternoon you have no idea which ones moved, which ones are blocked on you, and which ones are blocked on someone else.

What Hermes does. Every weekday at 9pm Madrid time (or whichever timezone you set), Hermes runs the GitHub CLI to list open PRs, groups them by status (waiting on review, waiting on CI, draft, mergeable), and delivers a formatted digest to your Telegram or Discord.

A digest looks like this:

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 outline.

1. Create a cron job with the prompt: "Every weekday at 21:00 list open PRs in albertoaquinodev/* and nousresearch/* using gh pr list. Group by status. Send to my Telegram."
2. Hermes parses the natural-language schedule into the cron expression 0 21 * * 1-5 and registers the skill.
3. Connect a Telegram or Discord delivery target if you have not already.

The whole thing takes about 10 minutes. Once running it costs roughly $0.02 to $0.05 per nightly run on Sonnet, depending on how many PRs are open.

For comparison, the equivalent setup using stitched-together Actions and Slack apps takes a weekend and breaks every time GitHub changes its API.

Recipe 3: Weekly Stale Issue Triage

Problem. Issues accumulate. Some get fixed in a parallel PR and nobody closes them. Some get reported, the user disappears, and the issue sits open forever. Some are duplicates. Manually walking the backlog is the kind of work nobody does.

What Hermes does. Every Monday morning, Hermes lists all issues with no activity in 60 days, reads the issue body and any comments, decides on one of four actions, and (depending on how much autonomy you give it) either drafts a comment for you to approve or posts the comment directly.

The four actions:

• Close as fixed. The referenced bug appears to be resolved in a recent commit or release. Hermes posts a polite closing comment with the linking commit.
• Close as stale. The author was asked for more info 30+ days ago and never replied.
• Bump priority. The issue is still relevant, has thumbs-ups from other users, and deserves a label change.
• Convert to discussion. The issue is a feature request that belongs in Discussions, not Issues.

Setup outline.

1. Create a cron job: "Every Monday at 10am, triage stale issues in my repos. Draft comments but do not post them yet."
2. Hermes generates a skill that runs gh issue list --state open --search 'updated:<2026-03-18' (date computed at run time), reads each issue, and decides on the action.
3. The drafts land in a single Telegram message or, if you prefer, as a PR-style summary you can review.

After a few weeks of supervised runs, you can either flip the switch to auto-post (Hermes acts directly) or keep it in draft mode forever. Either way, your backlog stops growing.

Where Hermes Stops And Where You Take Over

The honest version of this story is that Hermes is excellent at the routine 80% of repo maintenance, and you still want a human for the 20% that requires judgment: deciding whether a CI flake is actually a real bug, calling the breaking change in an API, telling a user their feature request is out of scope.

The whole point of the setup above is to clear the 80% off your plate so you have time for the 20%. For another flavor of this same idea, see our post on self-hosting an AI agent with Docker, which covers the infrastructure side of running Hermes long-term.

Try It This Week

If you already self-host Hermes, the three recipes above are roughly an evening of work to set up. If you do not, the fastest path is Get started with Hermify - a managed Hermes instance ships with the GitHub CLI, webhook listener, and cron scheduler already configured. You add your repo token and write the cron sentence in plain English.

The repo-babysitter setup is the kind of thing you wonder why nobody built sooner. Then you remember: most "AI for developers" tooling is built for the code-writing 20%, not the custodial 80%. Hermes goes after the 80%.

Sources

• Hermes Agent GitHub Integration
• How to Use Hermes Agent with GitHub Repositories
• Tutorial: GitHub PR Review Agent
• Automated GitHub PR Comments with Webhooks
• Hermes Agent Cron Jobs in Plain English: GitHub Backup
• Scheduled Tasks (Cron)
• GitHub Agentic Workflows Technical Preview