チュートリアル: GitHub の PR をレビューするエージェントを作る
目次
困っていること: チームが PR を出す速さに、レビューが追いつきません。PR は誰かが見てくれるまで何日も置かれたままです。若手が書いたバグが、誰も確かめる時間を取れずにマージされていきます。午前中は差分の追いかけに消えて、作る時間がありません。
その答え: リポジトリを一日中見張り、新しい PR をバグ・セキュリティ・コードの質の観点でレビューして、要点をあなたに送るエージェントです。人の判断が本当に要る PR にだけ時間を使えばよくなります。
作るもの:
┌───────────────────────────────────────────────────────────────────┐
│ │
│ Cron Timer ──▶ Hermes Agent ──▶ GitHub API ──▶ Review │
│ (every 2h) + gh CLI (PR diffs) delivery │
│ + skill (Telegram, │
│ + memory Discord, │
│ local) │
│ │
└───────────────────────────────────────────────────────────────────┘この案内では、cron ジョブで定期的に PR を見に行きます。サーバーも外から届く窓口も要りません。NAT やファイアウォールの内側でも動きます。
前提
- Hermes Agent がインストール済みであること — Installation guide をご覧ください
- cron ジョブのためにゲートウェイが動いていること:
hermes gateway install # Install as a service
# or
hermes gateway # Run in foreground- GitHub CLI(
gh)が入っていて、認証が済んでいること:
# Install
brew install gh # macOS
sudo apt install gh # Ubuntu/Debian
# Authenticate
gh auth loginステップ 1: 下ごしらえを確かめる
Hermes から GitHub に手が届くか確かめます。チャットを始めてください。
hermes簡単なコマンドで試します。
Run: gh pr list --repo NousResearch/hermes-agent --state open --limit 3開いている PR の一覧が出てくるはずです。これが動けば準備は整っています。
ステップ 2: 手動でレビューさせてみる
同じチャットのまま、実在するプルリクエストのレビューを頼んでみます。
Review this pull request. Read the diff, check for bugs, security issues,
and code quality. Be specific about line numbers and quote problematic code.
Run: gh pr diff 3888 --repo NousResearch/hermes-agentHermes はこう動きます。
gh pr diffを実行してコードの変更を取ってくる- 差分を最後まで読む
- 具体的な指摘のついた、形の整ったレビューを書く
出来ばえに納得できたら、いよいよ自動にします。
ステップ 3: レビュー用のスキルを作る
スキルを用意すると、セッションをまたいでも cron の実行でも、Hermes は同じ物差しでレビューしてくれます。なければ、レビューの質はそのときどきでばらつきます。
mkdir -p ~/.hermes/skills/code-review~/.hermes/skills/code-review/SKILL.md を作ります。
---
name: code-review
description: Review pull requests for bugs, security issues, and code quality
---
# Code Review Guidelines
When reviewing a pull request:
## What to Check
1. **Bugs** — Logic errors, off-by-one, null/undefined handling
2. **Security** — Injection, auth bypass, secrets in code, SSRF
3. **Performance** — N+1 queries, unbounded loops, memory leaks
4. **Style** — Naming conventions, dead code, missing error handling
5. **Tests** — Are changes tested? Do tests cover edge cases?
## Output Format
For each finding:
- **File:Line** — exact location
- **Severity** — Critical / Warning / Suggestion
- **What's wrong** — one sentence
- **Fix** — how to fix it
## Rules
- Be specific. Quote the problematic code.
- Don't flag style nitpicks unless they affect readability.
- If the PR looks good, say so. Don't invent problems.
- End with: APPROVE / REQUEST_CHANGES / COMMENT読み込まれたか確かめましょう。hermes を起動すると、立ち上がりのスキル一覧に code-review が出てくるはずです。
ステップ 4: チームの決まりごとを覚えさせる
レビュアーが本当に役に立つかどうかは、ここで決まります。セッションを始めて、チームの基準を Hermes に教えます。
Remember: In our backend repo, we use Python with FastAPI.
All endpoints must have type annotations and Pydantic models.
We don't allow raw SQL — only SQLAlchemy ORM.
Test files go in tests/ and must use pytest fixtures.Remember: In our frontend repo, we use TypeScript with React.
No `any` types allowed. All components must have props interfaces.
We use React Query for data fetching, never useEffect for API calls.覚えたことはずっと残ります。毎回言わなくても、レビュアーはチームの決まりごとを守らせてくれます。
ステップ 5: 自動で走る cron ジョブを作る
ここまでを一本につなぎます。2 時間おきに走る cron ジョブを作ります。
hermes cron create "0 */2 * * *" \
"Check for new open PRs and review them.
Repos to monitor:
- myorg/backend-api
- myorg/frontend-app
Steps:
1. Run: gh pr list --repo REPO --state open --limit 5 --json number,title,author,createdAt
2. For each PR created or updated in the last 4 hours:
- Run: gh pr diff NUMBER --repo REPO
- Review the diff using the code-review guidelines
3. Format output as:
## PR Reviews — today
### [repo] #[number]: [title]
**Author:** [name] | **Verdict:** APPROVE/REQUEST_CHANGES/COMMENT
[findings]
If no new PRs found, say: No new PRs to review." \
--name "pr-review" \
--deliver telegram \
--skill code-review予約できているか確かめます。
hermes cron listほかにも使える予約の書き方
| 予約 | いつ走るか |
|---|---|
0 */2 * * * |
2 時間おき |
0 9,13,17 * * 1-5 |
平日のみ、1 日 3 回 |
0 9 * * 1 |
毎週月曜の朝にまとめて |
30m |
30 分おき(PR の多いリポジトリ向け) |
ステップ 6: 好きなときに走らせる
予約の時刻を待ちたくないときは、自分で動かせます。
hermes cron run pr-reviewチャットのセッションからでも動かせます。
/cron run pr-reviewもう一歩先へ
レビューを GitHub に直接書き込む
Telegram に送る代わりに、PR そのものにコメントさせることもできます。
cron のプロンプトに、これを足します。
After reviewing, post your review:
- For issues: gh pr review NUMBER --repo REPO --comment --body "YOUR_REVIEW"
- For critical issues: gh pr review NUMBER --repo REPO --request-changes --body "YOUR_REVIEW"
- For clean PRs: gh pr review NUMBER --repo REPO --approve --body "Looks good"週に一度の PR ダッシュボード
月曜の朝に、すべてのリポジトリの様子をまとめさせます。
hermes cron create "0 9 * * 1" \
"Generate a weekly PR dashboard:
- myorg/backend-api
- myorg/frontend-app
- myorg/infra
For each repo show:
1. Open PR count and oldest PR age
2. PRs merged this week
3. Stale PRs (older than 5 days)
4. PRs with no reviewer assigned
Format as a clean summary." \
--name "weekly-dashboard" \
--deliver telegram複数のリポジトリを見張る
プロンプトにリポジトリを足していけば、そのまま広げられます。エージェントは順番に処理していくので、ほかに用意するものはありません。
うまくいかないとき
「gh: command not found」と出る
ゲートウェイは必要最小限の環境で動いています。gh がシステムの PATH にあることを確かめて、ゲートウェイを再起動してください。
レビューの中身がありきたりになる
code-reviewのスキルを足す(ステップ 3)- チームの決まりごとを記憶として教える(ステップ 4)
- あなたの技術の組み合わせについて知っていることが増えるほど、レビューは良くなります
cron ジョブが走らない
hermes gateway status # Is the gateway running?
hermes cron list # Is the job enabled?回数の上限
GitHub は認証済みのユーザーに、1 時間あたり 5,000 回の API 呼び出しを許しています。PR 1 件のレビューで使うのは 3〜5 回ほどです(一覧、差分、必要ならコメント)。1 日に 100 件レビューしても、上限には十分な余裕があります。
次はどうする
- Webhook で PR をレビューする — PR が開かれた瞬間にレビューします(外から届く窓口が要ります)
- 毎朝のブリーフィングボット — PR のレビューを、朝のニュースのまとめと一緒に届けます
- プラグインを作る — レビューの仕組みを、配れるプラグインにまとめます
- プロファイル — レビュー専用のプロファイルを、独自の記憶と設定で動かします
- フォールバックのプロバイダー — どれか 1 つが落ちていても、レビューが止まらないようにします