Використовувати ШІ-перевірку

Цей посібник показує, як змусити агентів-рев’юерів перевірити pull request і як опублікувати результат на GitHub.

Запустити ШІ-перевірку

Відкрийте PR і перейдіть на вкладку Огляд
Відкрийте меню переповнення ⋯ у рядку дій і виберіть Запитати AI

Цей пункт з’являється лише поки PR відкрито — це дія до злиття. Ту саму кнопку пропонують як Запитати AI у порожньому стані вкладки Рев’ю, доки жодного рев’ю ще немає.

Control Center запускає вбудований конвеєр pr_review і відкриває вкладку Рев’ю цього PR, щоб ви могли спостерігати за ним. Конвеєр:

Відкриває власний простір рев’ю цього PR, у чиєму ізольованому робочому дереві PR вивантажено на його head
Розгортає рецензентів відповідно до рівня рев’ю робочого простору — типово трьох (вбудовані агенти qa, architect і engineer, паралельно). Визначення мови чи предметної області немає
Доручає головному агентові (CEO) звести їхні знахідки в покроковий огляд
Завершує: розкладає знахідки за кошиками консенсусу й обчислює вердикт. Коли асоціація сягає стану awaiting approval, на вкладці Рев’ю з’являється Опублікувати на GitHub

Наскільки глибоко сягає рев’ю, визначає рівень рев’ю робочого простору — light (один рецензент), balanced (три, типовий) або thorough (усі п’ять, додаючи фахівців із безпеки та продуктивності). Його задають у Налаштування → Робочий простір → Загальні, на картці Політика робочого простору. Легший рівень фіксує стільки ж знахідок; просто показує на видному місці менше з них.

Усі рецензенти пишуть в єдиний простір рев’ю цього PR — саме тому їхні знахідки можна порівнювати. Про те, як усе поєднується, дивіться сторінку ШІ-перевірка.

pr_review постачається лише з ручним тригером. Щоб він спрацьовував на кожному опублікованому PR, додайте тригер самостійно — дивіться Запускати агентів-рев’юерів. Також можна запустити рев’ю із самого GitHub, без тригера конвеєра: згадайте бота сервера в PR або додайте мітку ai-review — дивіться Спілкуватися з Control Center з GitHub PR.

Якщо в сповіщенні написано, що для цього pull request рев’ю вже виконується, отже, воно вже в процесі; залишайтеся на вкладці Рев’ю або відкрийте Конвеєри, щоб його знайти.

Прочитати знахідки

Рецензенти записують знахідки як вузли рев’ю в просторі рев’ю. Кожен містить:

Поле	Опис
Тип	`bug`, `suggestion`, `recommendation`, `question` або `ticket`
Пріоритет	P0 (критичний) → P3 (дрібниця)
Категорія	`security`, `stability`, `data_integrity`, `correctness`, `performance` або `maintainability`
Файл і рядок	Де закріплено знахідку
Початковий код	Код, якого стосується знахідка
Запропонований код	Запропоноване виправлення
Впевненість	Наскільки впевнений рецензент
Статус	`open` → `consensus-ready` → `resolved` або `dismissed`

Знахідка сягає стану consensus-ready лише тоді, коли її підтвердить інший рецензент. Агент не може підтвердити власну знахідку, тож думка одного рецензента ніколи не просувається сама собою.

Вкладка Рев’ю показує список знахідок із фільтрами за типом і статусом та перемикачем для відхилених знахідок, поруч з артефактом, який опублікував агент-упорядник. Детермінований вигляд — когорти, багатовісна панель, контрактні та візуальні діфи — обчислюється на сервері, але не має поверхні в застосунку; про те, що дає цей прохід, дивіться Обчислення перевірки.

Перевірити панель розбіжностей

Коли два рецензенти закріплюють знахідки за тим самим файлом і рядком, але оцінюють їх дуже по-різному — пріоритети відрізняються на два чи більше рівнів, або один називає це bug, а інший — suggestion — над списком знахідок з’являється панель розбіжностей. Читайте їх першими: саме там думки рецензентів розходяться, і ваше судження важить найбільше.

Прочитати вердикт

Коли головний агент завершує роботу, він обчислює вердикт:

Вердикт	Значення
Ship	Нічого блокуючого не знайдено
Hold	Проблеми, які варто розв’язати до злиття
Block	Критичні проблеми, які обов’язково треба виправити

Вердикт містить сукупний бал впевненості та кількість знахідок за кожним пріоритетом.

Потім у нього враховуються осі рев’ю, і вони можуть зробити його лише суворішим. Вісь із гейтом, що не проходить, примусово дає Block; вісь із гейтом, яка не змогла завершитися (partial) або взагалі не запустилася (unavailable), примусово дає щонайменше Hold. Відсутність доказів ніколи не відкриває гейт.

Опублікувати рев’ю на GitHub

Публікація — окремий крок, який навмисно контролює користувач. Конвеєр pr_review залишає рев’ю в Control Center; він не публікує його на GitHub.

На вкладці Рев’ю дочекайтеся, доки з’явиться Опублікувати на GitHub
Натисніть Опублікувати на GitHub

Control Center надсилає одне рев’ю на GitHub. Знахідки, вже виправлені чи відхилені, пропускаються. Кнопка включає кожну решту відкритих знахідок і за вердикту Ship подає APPROVE. (Інструмент MCP publish_review_to_github усе ще типово бере лише знахідки, підтверджені іншими рецензентами, і не схвалює, якщо не передати approve_on_ship.) Ті, що мають прив’язку до файлу й рядка, стають рядковими коментарями; усе інше згортається в тіло підсумку, кожне з припискою «— Control Center AI review», щоб джерело було однозначним. Вердикт Block подається як REQUEST_CHANGES; Hold — як COMMENT; Ship — як APPROVE із цієї кнопки. Потім у сповіщенні з’являється Опубліковано. Рев’ю публікується від імені застосунку сервера.

Якщо GitHub відхиляє рядкову прив’язку, бо рядка немає в діфі, усе рев’ю надсилається повторно, а кожну знахідку згорнуто в тіло, тож нічого не зникає мовчки.

Інші вбудовані конвеєри справді публікують на GitHub безпосередньо: cross_review, pr_triage, ticket_to_pr і pre_merge_gate кожен завершується кроком із коментарем. Лише pr_review притримує свій результат для вас.

Запускати рецензентів самостійно

Щоб контролювати, які ролі перевіряють PR і на які файли дивиться кожна з них, скористайтеся інструментом MCP dispatch_reviewers у наявному просторі рев’ю або додайте вузли рецензентів до конвеєра. Обидва шляхи, з точною сигнатурою інструмента, описано в Запускати агентів-рев’юерів.