Учебное пособие: Создание агента для ревью PR на GitHub

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

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

Что вы производите:

┌───────────────────────────────────────────────────────────────────┐
│                                                                   │
│   Таймер Cron  ──▶  Агент Hermes  ──▶  GitHub API  ──▶  Доставка │
│   (каждые 2ч)       + gh CLI           (диффы PR)       ревью    │
│                    + навык                             (Telegram, │
│                    + память                            Discord,   │
│                                                        локально) │
│                                                                   │
└───────────────────────────────────────────────────────────────────┘

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

💡 Tip

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


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

# Аутентификация gh auth login `` - **Настроенные мессенджеры** (опционально) — [Telegram](/docs/user-guide/messaging/telegram) или [Discord](/docs/user-guide/messaging/discord)<div class="admonition admonition-tip"><p class="admonition-title">💡 Tip</p> Нет мессенджеров? Не проблема Используйтеdeliver: "local", чтобы сохранить версию в~/.hermes/cron/output/`. Отлично подходит для тестирования перед подключением.


Шаг 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-agent

Гермес: 1. Выполните gh pr diff, чтобы получить изменения кода. 2. Прочитает весь дифф 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 Еженедельный обзор по понедельникам утра
30м Каждые 30 минут (репозитории с высокой активностью)

Шаг 6: Запуск механизма

Не хотите ждать расписания? Запустите вручную:

hermes cron run pr-review

Или из сеанса чата:

/cron run pr-review

дальше шагов

Публикация обзора прямо на GitHub

Вместо доставки в Telegram пусть агент комментирует сам пиар:

Добавьте это в подсказку 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`.</div>
### Еженедельная панель PR

сделать обзор всех репозиториев в понедельник утром:
```bash
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: команда не найдена"

Шлюз работает превосходным образом. Убедитесь, что gh находится в системном PATH, и перезапустите шлюз.

Ревью слишком общее

  1. Добавьте навыки code-review (Шаг 3)
  2. Обучите Гермеса соглашениям через память (Шаг 4)
  3. Чем больше контекста на вашем столе, тем лучше обзор.

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

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

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

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


Что дальше?