Представляем правила уровня PR:
Проверяйте PR, а не только код

Мы рады представить правила уровня PR — новую категорию правил, которые анализируют весь Pull Request целиком, а не только отдельные файлы. С двумя новыми специальными тегами, pr-level и git-history, вы теперь можете автоматически применять соглашения вашей команды по оформлению PR.

Что нового

Традиционный code review на базе ИИ анализирует файлы по одному, проверяя баги, проблемы безопасности и паттерны. Но некоторые из самых важных аспектов хорошего PR невозможно найти ни в одном отдельном файле:

Теперь diffray может проверять всё это — автоматически, для каждого PR.

Два новых тега: pr-level и git-history

Мы добавили два специальных тега, которые меняют способ обработки правил ИИ-агентом:

Примеры правил, готовых к использованию

1. Описание PR должно объяснять «Почему»

Самая распространённая проблема с PR: они перечисляют что изменилось, но не почему. Ревьюеры видят diff — им нужен контекст.

- id: pr_description_explain_why
  agent: general
  title: Описание PR должно объяснять мотивацию
  importance: 7
  always_run: true
  match:
    file_glob: ['**/*']
  checklist:
    - Проверить, объясняет ли описание PR бизнес-причину
    - Убедиться, что оно отвечает на "Почему это изменение необходимо?"
    - Искать контекст о решаемой проблеме
  tags:
    - pr-level
    - quality

2. Сообщения коммитов в формате Conventional Commits

Обеспечьте единый формат коммитов для автоматической генерации changelog и семантического версионирования:

- id: commit_message_format
  agent: general
  title: Сообщения коммитов должны следовать формату Conventional Commits
  importance: 5
  always_run: true
  match:
    file_glob: ['**/*']
  checklist:
    - Использовать git log --oneline для проверки недавних коммитов
    - Убедиться, что коммиты следуют формату type(scope): description
    - Проверить понятность сообщений (не "fix stuff", "WIP")
  examples:
    bad: |
      fix stuff
      WIP
      update code
    good: |
      feat(auth): add OAuth2 login with Google
      fix(api): handle null response from payment service
  tags:
    - git-history
    - automation

3. Breaking Changes должны быть задокументированы

Ничто не разрушает доверие быстрее, чем недокументированные breaking changes, попавшие в продакшен:

- id: breaking_changes_documented
  agent: general
  title: Breaking changes должны быть чётко задокументированы
  importance: 9
  always_run: true
  match:
    file_glob: ['**/*']
  checklist:
    - Проверить, изменяют ли изменения публичные API или удаляют функциональность
    - Если breaking, убедиться, что сообщения коммитов включают BREAKING CHANGE
    - Проверить наличие руководства по миграции в описании PR
  tags:
    - pr-level
    - git-history
    - breaking-changes

4. PR с единой ответственностью

PR, смешивающие новые функции, исправления багов и рефакторинг, невозможно качественно ревьюить:

- id: pr_single_responsibility
  agent: general
  title: PR смешивает несвязанные изменения
  importance: 7
  always_run: true
  match:
    file_glob: ['**/*']
  checklist:
    - Проверить изменённые файлы для выявления отдельных областей изменений
    - Убедиться, что изменения не затрагивают несколько несвязанных функций
    - Сообщить, если PR затрагивает auth И payments И styling
  tags:
    - pr-level
    - quality

5. Обязательные ссылки на тикеты

Для отслеживаемости и формирования release notes каждый PR должен быть связан с задачей:

- id: pr_ticket_reference
  agent: general
  title: PR должен ссылаться на issue или тикет
  importance: 5
  always_run: true
  match:
    file_glob: ['**/*']
  checklist:
    - Проверить коммиты на наличие ссылок на тикеты (PROJ-123, #123, ENG-456)
    - Искать URL задач в сообщениях коммитов
    - Сообщать только если НИ ОДИН коммит не содержит ссылки на тикет
  tags:
    - pr-level
    - git-history
    - traceability

Как это работает под капотом

Агент general был обновлён специальными инструкциями для обработки этих тегов:

Правила с always_run: true выполняются для каждого PR независимо от того, какие файлы были изменены. Это делает их идеальными для проверок уровня PR, которые не зависят от конкретных паттернов файлов.

Начало работы

Добавить правила уровня PR в ваш проект очень просто:

Мы опубликовали примеры правил в нашем репозитории project-specific-rules, которые вы можете скопировать и настроить под себя.

Почему это важно

Хорошие PR — это больше, чем просто работающий код. Это документация для будущих разработчиков. Это аудиторский след для соответствия требованиям. Это разница между «что тут произошло?» и «а, понятно».

Правила уровня PR превращают негласные командные знания в автоматизированные проверки. Вместо того чтобы надеяться, что все помнят о необходимости ссылаться на тикеты, документировать breaking changes и писать осмысленные описания — вы получаете единообразную обратную связь по каждому PR.