Pull request

Pull request: проверка до слияния

Когда агент закончил работу в ветке, её нужно вернуть в main. Сделать это можно сразу, но тогда о содержимом правки вы узнаете уже из папки. Pull request это запрос на изменения: агент показывает, что он хочет поменять, а вы решаете, принять или нет.

Так работает ремонт. Клиент хочет покрасить стены, мастер сначала говорит "вот план, согласен?" и красит только после "согласен". С агентом ещё проще: результат готов сразу, вы смотрите на него до слияния, и если не нравится, main не меняется.

Короткий пример на скилле плана дня: из него нужно убрать файл memory.md.

Работай в ветке. Убери из скилла memory.md. И отправь pull request.

Источник: урок 6 программы Personal Corp.

Источник ответа: урок 6, 1:00–1:10: первую часть ведущий читает с экрана, вторую пересказывает.

Агент делает рабочее дерево и ветку, правит копию и присылает ссылку на pull request. На странице pull request на GitHub два места:

• описание от агента: что и зачем он сделал;
• вкладка изменённых файлов: построчно видно, что удалено и что добавлено.

Пока запрос не влит, ничего не исчезло. Его можно принять большой зелёной кнопкой слияния, отклонить или прокомментировать отдельные строки. Если правка не нужна, скажите агенту удалить ветку и pull request, и папка останется как была. Для своих задач используйте общий вариант промпта.

Сделай [ЗАДАЧА] в отдельной ветке и отдельном рабочем дереве. Когда закончишь, пришли ссылку на pull request: в описании напиши, что изменил и зачем. В main ничего не вливай, жди моего "да".

Источник: урок 6 программы Personal Corp.

Источник ответа: пример ответа по показу на шестом уроке.

Рабочий режим выглядит так: агенты присылают запросы, вы смотрите изменения и нажимаете кнопку. Если ветка не закрывается или pull request завис, разбираться в командах не нужно: опишите агенту, что видите, и он разберётся сам.

Как выглядит хороший pull request

Описание pull request читает человек, который решает, вливать или нет. Хорошее описание отвечает на его вопросы в том порядке, в каком они приходят в голову: что поменяется, что от меня нужно, как это выглядит, где это в коде и как проверить. Ниже верх описания настоящего pull request: агент собрал в нём пять веток этой книги в одну.

Описание идёт сверху вниз, от того, что нужно вам, к тому, что нужно проверяющему.

• Первый абзац обычными словами. Что изменится для читателя книги и что нужно от вас: посмотреть и влить. Без названий веток, файлов и терминов. Этот абзац читают всегда, остальное по необходимости.
• Карта фич. Таблица: фича, что видно, где в коде, как проверить. Каждую строку можно проверить отдельно. Под таблицей грабли, на которых легко споткнуться, и картинки по фичам.
• Картинка результата прямо в описании. Вы видите, что получилось, не скачивая ветку и не запуская проект.
• Техническая часть ниже. Схема веток, как разрешены конфликты, тесты, чем рискует слияние. Её читает проверяющий агент или вы, когда что-то пошло не так.

Такое описание агент пишет по промпту.

Напиши описание pull request в таком порядке.
1. Первый абзац обычными словами, в информационном стиле Ильяхова: что поменяется для того, кто это увидит, и что нужно от меня (посмотреть, влить). Без веток, файлов и терминов, 2–4 коротких предложения.
2. Карта фич, как в pstack: таблица «фича → что видно → где в коде → как проверить», под ней картинки по фичам.
3. Картинка результата прямо в описании: закоммить снимок экрана в ветку и вставь его в описание.
4. Ниже техническая часть: схема изменений, доказательства до и после, чем рискует слияние.

Источник: скилл mp-pr и слово основателя 29.10.2026: «первый абзац по-человечески в стиле Ильяхова», «в pull request показывается изображение», «feature map как у pstack».

Источник ответа: pull request serejaris/cohorts#253, снимок assets/pr-example.png этой главы.

Один pull request вы прочитаете сами. Что делать, когда их приходит больше, чем вы успеваете проверить, разобрано в следующей главе «Проверяющий в новой сессии».

Слова, которыми агенту ставят задачу про Git