Перейти к основному содержимому

Учебник: Создаём агента проверки PR на GitHub

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

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

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

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

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

Хотите ревью в реальном времени?

Если у вас есть публичный эндпоинт, посмотрите Автоматические комментарии к PR на GitHub через вебхуки — GitHub мгновенно отправляет события в VibeOS при открытии или обновлении PR.


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

  • Установленный VibeOS — см. Руководство по установке
  • Запущенный шлюз для cron-задач:
    vibeos gateway install   # Установить как службу
    # или
    vibeos gateway # Запустить в фоне
  • Установленный и аутентифицированный GitHub CLI (gh):
    # Установка
    brew install gh # macOS
    sudo apt install gh # Ubuntu/Debian

    # Аутентификация
    gh auth login
  • Настроенный мессенджер (опционально) — Telegram или Discord
Нет мессенджера? Не проблема

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


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

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

vibeos

Протестируйте простой командой:

Выполни: gh pr list --repo Linx72/VibeOS --state open --limit 3

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


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

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

Проверь этот пул-реквест. Прочитай дифф, найди баги, проблемы безопасности
и качество кода. Укажи конкретные строки и процитируй проблемный код.

Выполни: gh pr diff 3888 --repo Linx72/VibeOS

VibeOS:

  1. Выполнит gh pr diff, чтобы получить изменения кода
  2. Прочитает весь дифф
  3. Составит структурированное ревью с конкретными замечаниями

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


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

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

mkdir -p ~/.vibeos/skills/code-review

Создайте ~/.vibeos/skills/code-review/SKILL.md:

---
name: code-review
description: Проверять пул-реквесты на баги, проблемы безопасности и качество кода
---

# Правила код-ревью

При проверке пул-реквеста:

## Что проверять
1. **Баги** — логические ошибки, off-by-one, обработка null/undefined
2. **Безопасность** — инъекции, обход аутентификации, секреты в коде, SSRF
3. **Производительность** — N+1 запросы, бесконечные циклы, утечки памяти
4. **Стиль** — соглашения об именах, мёртвый код, отсутствие обработки ошибок
5. **Тесты** — Проверены ли изменения? Покрывают ли тесты граничные случаи?

## Формат вывода
Для каждого замечания:
- **Файл:Строка** — точное местоположение
- **Серьёзность** — Критично / Предупреждение / Предложение
- **Что не так** — одно предложение
- **Исправление** — как это исправить

## Правила
- Будьте конкретны. Цитируйте проблемный код.
- Не отмечайте мелкие придирки к стилю, если они не влияют на читаемость.
- Если PR хорош, так и скажите. Не выдумывайте проблемы.
- Завершайте: ОДОБРИТЬ / ЗАПРОСИТЬ_ИЗМЕНЕНИЯ / ЗАМЕЧАНИЕ

Проверьте, что навык загружен — запустите vibeos, и вы должны увидеть code-review в списке навыков при старте.


Шаг 4: Обучите своим правилам​

Это то, что делает ревьюера действительно полезным. Запустите сессию и обучите VibeOS стандартам вашей команды:

Запомни: В нашем бэкенд-репозитории мы используем Python с FastAPI.
Все эндпоинты должны иметь аннотации типов и Pydantic-модели.
Мы не используем сырой SQL — только SQLAlchemy ORM.
Тестовые файлы находятся в tests/ и должны использовать pytest fixtures.
Запомни: В нашем фронтенд-репозитории мы используем TypeScript с React.
Тип `any` запрещён. Все компоненты должны иметь интерфейсы пропсов.
Мы используем React Query для загрузки данных, никогда useEffect для API-вызовов.

Эти воспоминания сохраняются навсегда — ревьюер будет соблюдать ваши правила без необходимости повторять каждый раз.


Шаг 5: Создайте автоматическую cron-задачу​

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

vibeos cron create "0 */2 * * *" \
"Проверь новые открытые PR и выполни их ревью.

Репозитории для мониторинга:
- myorg/backend-api
- myorg/frontend-app

Шаги:
1. Выполни: gh pr list --repo REPO --state open --limit 5 --json number,title,author,createdAt
2. Для каждого PR, созданного или обновлённого за последние 4 часа:
- Выполни: gh pr diff NUMBER --repo REPO
- Проверь дифф, используя правила код-ревью
3. Отформатируй вывод как:

## Ревью PR — сегодня

### [repo] #[number]: [title]
**Автор:** [name] | **Вердикт:** ОДОБРИТЬ/ЗАПРОСИТЬ_ИЗМЕНЕНИЯ/ЗАМЕЧАНИЕ
[замечания]

Если новых PR не найдено, скажи: Новых PR для ревью нет." \
--name "pr-review" \
--deliver telegram \
--skill code-review

Проверьте, что задача запланирована:

vibeos cron list

Другие полезные расписания​

РасписаниеКогда
0 */2 * * *Каждые 2 часа
0 9,13,17 * * 1-5Три раза в день, только будни
0 9 * * 1Еженедельный обзор в понедельник утром
30mКаждые 30 минут (для репозиториев с высокой активностью)

Шаг 6: Запустите по требованию​

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

vibeos cron run pr-review

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

/cron run pr-review

Дальнейшие шаги​

Публикация ревью напрямую в GitHub​

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

Добавьте это в промпт cron-задачи:

После ревью опубликуй свой отзыв:
- Для проблем: gh pr review NUMBER --repo REPO --comment --body "YOUR_REVIEW"
- Для критических проблем: gh pr review NUMBER --repo REPO --request-changes --body "YOUR_REVIEW"
- Для чистых PR: gh pr review NUMBER --repo REPO --approve --body "Выглядит хорошо"
предупреждение

Убедитесь, что у gh есть токен с областью repo. Ревью публикуются от имени пользователя, под которым аутентифицирован gh.

Еженедельная панель PR​

Создайте обзор всех ваших репозиториев в понедельник утром:

vibeos cron create "0 9 * * 1" \
"Сформируй еженедельную панель PR:
- myorg/backend-api
- myorg/frontend-app
- myorg/infra

Для каждого репозитория покажи:
1. Количество открытых PR и возраст самого старого
2. PR, слитые на этой неделе
3. Застарелые PR (старше 5 дней)
4. PR без назначенного ревьюера

Отформатируй как чистую сводку." \
--name "weekly-dashboard" \
--deliver telegram

Мониторинг нескольких репозиториев​

Масштабируйтесь, добавляя больше репозиториев в промпт. Агент обрабатывает их последовательно — никакой дополнительной настройки не требуется.


Устранение неполадок​

«gh: command not found»​

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

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

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

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

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

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

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


Что дальше?​