Review GitHub pull requests for bugs and security
The problem: Your team opens PRs faster than you can review them. Task: The problem: Your team opens PRs faster than you can review them. PRs sit for days waiting for eyeballs. Junior devs merge bugs because nobody had time to check. You spend your mornings catching up on diffs instead of building. The solution: An AI agent that watches your repos around the clock, reviews every new PR for bugs, security issues, and code quality, and sends you a summary — so you only spend time on PRs that actually need human judgment. What you'll build: This guide uses cron jobs to poll for PRs on a schedule — no server or public endpoint needed. Works behind NAT and firewalls. If you have a public endpoint available, check out Automated GitHub PR Comments with Webhooks — GitHub pushes events to Hermes instantly when PRs are opened or updated. Prerequisites Hermes Agent installed — see the Installation guide Gateway running for cron jobs: hermes gateway install # Install as a service# orhermes gateway # Run in foreground GitHub CLI (gh) installed and authenticated: # Installbrew install gh # macOSsudo apt install gh # Ubuntu/Debian# Authenticategh auth login Messaging configured (optional) — Telegram or Discord Use deliver: "local" to save reviews to ~/.hermes/cron/output/. Great for testing before wiring up notifications. Step 1: Verify the Setup Make sure Hermes can access GitHub. Start a chat: Test with a simple command: You should see a list of open PRs. If this works, you're ready. Step 2: Try a Manual Review Still in the chat, ask Hermes to review a real PR: Hermes will: Execute gh pr diff to fetch the code changes Read through the entire diff Produce a structured review with specific findings If you're happy with the quality, time to automate it. Step 3: Create a Review Skill A skill gives Hermes consistent review guidelines that persist across sessions and cron runs. Without one, review quality varies. Create ~/.hermes/skills/code-review/SKILL.md: Verify it loaded — start hermes and you should see code-review in the skills list at startup. Step 4: Teach It Your Conventions This is what makes the reviewer actually useful. Start a session and teach Hermes your team's standards: These memories persist forever — the reviewer will enforce your conventions without being told each time. Step 5: Create the Automated Cron Job Now wire it all together. Create a cron job that runs every 2 hours: Verify it's scheduled: Other useful schedules Step 6: Run It On Demand Don't want to wait for the schedule? Trigger it manually: Or from within a chat session: Going Further Post Reviews Directly to GitHub Instead of delivering to Telegram, have the agent comment on the PR itself: Add this to your cron prompt: Make sure gh has a token with repo scope. Reviews are posted as whoever gh is authenticated as. Weekly PR Dashboard Create a Monday morning overview of all your repos: Multi-Repo Monitoring Scale up by adding more repos to the prompt. The agent processes them sequentially — no extra setup needed. Troubleshooting "gh: command not found" The gateway runs in a minimal environment. Ensure gh is in the system PATH and restart the gateway. Reviews are too generic Add the code-review skill (Step 3) Teach Hermes your conventions via memory (Step 4) The more context it has about your stack, the better the reviews Cron job doesn't run Rate limits GitHub allows 5,000 API requests/hour for authenticated users. Each PR review uses ~3-5 requests (list + diff + optional comments). Even reviewing 100 PRs/day stays well within limits. What's Next? Webhook-Based PR Reviews — get instant reviews when PRs are opened (requires a public endpoint) Daily Briefing Bot — combine PR reviews with your morning news digest Build a Plugin — wrap the review logic into a shareable plugin Profiles — run a dedicated reviewer profile with its own memory and config Fallback Providers — ensure reviews run even when one provider is down; tools: Hermes Agent. Human role: The original post does not say how a person stayed involved.; limitations: Prerequisites include Hermes Agent, GitHub CLI authenticated with repo scope, and a running gateway for cron jobs. The system operates behind NAT/firewalls using polling, avoiding public endpoints. GitHub API rate limits (5,000 requests/hour) are sufficient for ~100 PRs/day. Reviews may be generic without specific team conventions taught via memory. Human approval is required before posting comments directly to GitHub to prevent unauthorized actions..
Tools
Published on Agent Work Atlas:
Overview
The problem: Your team opens PRs faster than you can review them.
Workflow
The problem: Your team opens PRs faster than you can review them. PRs sit for days waiting for eyeballs. Junior devs merge bugs because nobody had time to check. You spend your mornings catching up on diffs instead of building. The solution: An AI agent that watches your repos around the clock, reviews every new PR for bugs, security issues, and code quality, and sends you a summary — so you only spend time on PRs that actually need human judgment. What you'll build: This guide uses cron jobs to poll for PRs on a schedule — no server or public endpoint needed. Works behind NAT and firewalls. If you have a public endpoint available, check out Automated GitHub PR Comments with Webhooks — GitHub pushes events to Hermes instantly when PRs are opened or updated. Prerequisites Hermes Agent installed — see the Installation guide Gateway running for cron jobs: hermes gateway install # Install as a service# orhermes gateway # Run in foreground GitHub CLI (gh) installed and authenticated: # Installbrew install gh # macOSsudo apt install gh # Ubuntu/Debian# Authenticategh auth login Messaging configured (optional) — Telegram or Discord Use deliver: "local" to save reviews to ~/.hermes/cron/output/. Great for testing before wiring up notifications. Step 1: Verify the Setup Make sure Hermes can access GitHub. Start a chat: Test with a simple command: You should see a list of open PRs. If this works, you're ready. Step 2: Try a Manual Review Still in the chat, ask Hermes to review a real PR: Hermes will: Execute gh pr diff to fetch the code changes Read through the entire diff Produce a structured review with specific findings If you're happy with the quality, time to automate it. Step 3: Create a Review Skill A skill gives Hermes consistent review guidelines that persist across sessions and cron runs. Without one, review quality varies. Create ~/.hermes/skills/code-review/SKILL.md: Verify it loaded — start hermes and you should see code-review in the skills list at startup. Step 4: Teach It Your Conventions This is what makes the reviewer actually useful. Start a session and teach Hermes your team's standards: These memories persist forever — the reviewer will enforce your conventions without being told each time. Step 5: Create the Automated Cron Job Now wire it all together. Create a cron job that runs every 2 hours: Verify it's scheduled: Other useful schedules Step 6: Run It On Demand Don't want to wait for the schedule? Trigger it manually: Or from within a chat session: Going Further Post Reviews Directly to GitHub Instead of delivering to Telegram, have the agent comment on the PR itself: Add this to your cron prompt: Make sure gh has a token with repo scope. Reviews are posted as whoever gh is authenticated as. Weekly PR Dashboard Create a Monday morning overview of all your repos: Multi-Repo Monitoring Scale up by adding more repos to the prompt. The agent processes them sequentially — no extra setup needed. Troubleshooting "gh: command not found" The gateway runs in a minimal environment. Ensure gh is in the system PATH and restart the gateway. Reviews are too generic Add the code-review skill (Step 3) Teach Hermes your conventions via memory (Step 4) The more context it has about your stack, the better the reviews Cron job doesn't run Rate limits GitHub allows 5,000 API requests/hour for authenticated users. Each PR review uses ~3-5 requests (list + diff + optional comments). Even reviewing 100 PRs/day stays well within limits. What's Next? Webhook-Based PR Reviews — get instant reviews when PRs are opened (requires a public endpoint) Daily Briefing Bot — combine PR reviews with your morning news digest Build a Plugin — wrap the review logic into a shareable plugin Profiles — run a dedicated reviewer profile with its own memory and config Fallback Providers — ensure reviews run even when one provider is down
Reported result
The source describes the intended workflow but does not report measured outcomes, success rates, or time savings from actual execution. It claims the system reduces review bottlenecks by filtering PRs that need human judgment, but no data validates this impact. A measurable acceptance check would be: Track the reduction in average PR review latency (time from open to merge) over two weeks compared to the baseline, ensuring false positive rates in security flags remain below 5%.
Human role
The original post does not say how a person stayed involved.
Limitations
Prerequisites include Hermes Agent, GitHub CLI authenticated with repo scope, and a running gateway for cron jobs. The system operates behind NAT/firewalls using polling, avoiding public endpoints. GitHub API rate limits (5,000 requests/hour) are sufficient for ~100 PRs/day. Reviews may be generic without specific team conventions taught via memory. Human approval is required before posting comments directly to GitHub to prevent unauthorized actions.
Try it
Act as a DevOps engineer setting up an automated PR review system using Hermes Agent. My team uses [replaceable: GitHub Org/Repos] and needs to reduce review backlog. 1. Verify setup: Run 'gh pr list --repo [replaceable: repo-name] --state open' to confirm access. 2. Create a skill: Define ~/.hermes/skills/code-review/SKILL.md with guidelines for bugs, security, and style. 3. Teach conventions: Instruct Hermes to remember our stack details (e.g., [replaceable: language/framework]). 4. Configure cron: Set up a job to poll every 2 hours, fetching diffs via 'gh pr diff' and generating structured reviews. 5. Dry run: Execute the review manually on one PR and save output to local file. Show me the result. 6. Human check: Do not post to GitHub or send notifications until I approve the sample output. If inputs are missing, ask for the specific repo name and desired notification channel.
Source reports are not independently verified. Publication date is the catalog publication date, not the original article date.