Руководство: Создание агента ревью PR на GitHub

Проблема: Ваша команда открывает PR быстрее, чем вы успеваете их ревьюить. PR неделями ждут проверки. Джуниоры сливают баги, потому что ни у кого нет времени проверить. Вы тратите утро на просмотр диффов вместо того, чтобы создавать.

Решение: AI-агент, который круглосуточно следит за вашими репозиториями, ревьюит каждый новый PR на предмет багов, уязвимостей и качества кода, а затем присылает вам сводку — так вы тратите время только на те PR, которые действительно требуют человеческого суждения.

Что вы создадите:

┌───────────────────────────────────────────────────────────────────┐
│                                                                   │
│   Cron Timer  ──▶  Hermes Agent  ──▶  GitHub API  ──▶  Review     │
│   (every 2h)       + gh CLI           (PR diffs)       delivery   │
│                    + skill                             (Telegram,  │
│                    + memory                            Discord,   │
│                                                        local)     │
│                                                                   │
└───────────────────────────────────────────────────────────────────┘

В этом руководстве используются cron-задачи для опроса PR по расписанию — не нужен сервер или публичный эндпоинт. Работает за NAT и файрволами.

tip Нужно ревью в реальном времени? Если у вас есть публичный эндпоинт, ознакомьтесь с Автоматические комментарии к PR на GitHub через Webhooks — GitHub мгновенно отправляет события Hermes при открытии или обновлении PR.


Предварительные требования

# Аутентификация gh auth login ```

tip Нет мессенджера? Не проблема Используйте deliver: "local", чтобы сохранять ревью в ~/.hermes/cron/output/. Отлично подходит для тестирования перед настройкой уведомлений.


Шаг 1: Проверка настройки

Убедитесь, что Hermes может получить доступ к GitHub. Запустите чат:

hermes

Проверьте простой командой:

Run: gh pr list --repo NousResearch/hermes-agent --state open --limit 3

Вы должны увидеть список открытых PR. Если это сработало — вы готовы.


Шаг 2: Попробуйте ручное ревью

Всё ещё в чате, попросите Hermes проверить реальный PR:

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-agent

Hermes сделает:

  1. Выполнит gh pr diff для получения изменений кода

  2. Прочитает весь diff

  3. Подготовит структурированное ревью с конкретными замечаниями

Если качество вас устраивает — пора автоматизировать.


Шаг 3: Создание навыка ревью

Навык даёт Hermes единые рекомендации по ревью, которые сохраняются между сессиями и запусками cron. Без него качество ревью будет разным.

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-задачи

Теперь объедините всё вместе. Создайте cron-задачу, которая запускается каждые 2 часа:

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 Три раза в день, только будни
0 9 * * 1 Еженедельная сводка по понедельникам
30m Каждые 30 минут (репозитории с высокой нагрузкой)

Шаг 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"
Убедитесь, что `gh` имеет токен с областью `repo`. Ревью публикуются от имени того пользователя, под которым аутентифицирован `gh`.

Еженедельная 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: команда не найдена»

Gateway работает в минимальном окружении. Убедитесь, что gh находится в системном PATH, и перезапустите gateway.

Слишком общие ревью

  1. Добавьте навык code-review (Шаг 3)

  2. Обучите Hermes вашим соглашениям через память (Шаг 4)

  3. Чем больше контекста о вашем стеке, тем лучше будут ревью

Cron-задача не запускается

hermes gateway status    # Gateway запущен?
hermes cron list         # Задача включена?

Лимиты запросов

GitHub разрешает 5 000 API-запросов в час для аутентифицированных пользователей. Каждое ревью PR использует ~3-5 запросов (список + diff + опциональные комментарии). Даже ревью 100 PR в день остаётся в пределах лимитов.


Что дальше?