Repo Monitor
What it is
A recurring workflow that watches repository changes and reports meaningful deltas.
In plain terms
Think of a copy editor who reads through the same manuscript every morning but marks up only the paragraphs that are actually different from yesterday’s draft — the rest gets a quick skim and no red pen. Repo Monitor works the same way for a piece of software: on a schedule, it checks the project’s activity (new issues, pull requests, releases, or commits) against what it saw last time, and only speaks up when there’s something genuinely new to say.
Why it matters
A real feature landing, a breaking change — a repo monitor is a recurring job that watches for repository changes and reports specifically the meaningful ones, not every commit indiscriminately, which is what keeps it from turning into noise nobody reads. It works well stacked with no-model jobs and monitoring more broadly, letting a cheap check rule out ‘nothing happened’ before a model call gets spent summarizing what actually did. Manual triggering is commonly wired in too, so a monitor can be re-run on demand right after a known change instead of waiting for its next scheduled pass.
How it works
Mechanically, a repo monitor pairs a cron job (tools/cronjob_tools.py) with a small polling script. Hermes ships a ready-made one, watch_github.py, that hits GitHub’s issues, pulls, releases, or commits endpoint for a repo, compares the results against a saved watermark file of previously-seen IDs capped at 500 entries, and prints a formatted digest only for the ones it hasn’t seen before — empty output means stay silent. The cron job runs that script on a schedule such as every 15 minutes, in a fresh session with no memory of past runs, so the instructions have to be self-contained. The very first run always records a baseline instead of replaying the whole repo history, and setting a GITHUB_TOKEN lifts the otherwise 60-request-per-hour anonymous rate limit.
A concrete example
A maintainer wants to know the moment someone opens a pull request against their public repo, without refreshing GitHub all day.
- They ask Hermes to set up a five-minute watcher for the repo’s pull requests.
- Hermes creates a cron job that runs the GitHub watcher script every five minutes and delivers to their chat.
- Most ticks produce nothing — the watermark file shows no new pull IDs, so the job stays silent.
- When a new PR lands, the next tick’s script prints its title, author, and link; the cron run turns that into a short summary and sends it straight to the maintainer’s chat.
How it connects
This note belongs to the Workflow Patterns family. Its closest neighboring concepts are: Research Briefing, Content Repurposing, Agent Runtime.
Source evidence
vendor/hermes-agent/toolsets.py#<file>— Structural Source Map fallback for toolsets.py. A core source file in the Tool Registry and Toolsets structure within Tools, Toolsets, and MCP.
Workflows
- Repository Monitor
Related articles
- No article currently mentions this concept by name/alias often enough to qualify (see mention-mining policy).
