Разделить работу с агентом на шаги с результатом в проекте: вопросы, спецификация, задачи, реализация, ревью и pull request.
Чему научишься
•Объяснять шаги пайплайна разработки с агентом и результат каждого шага.
•Выбирать между коротким путём для мелкой правки и полным путём для фичи.
•Выбирать между `grill-with-docs` и `wayfinder` по объёму решений.
•Определять, какие правила проекта записать поверх готового набора скиллов.
Содержание · 12ОткрытьСкрыть
В этом материале разберём, как работа с агентом делится на шаги, кто запускает каждый шаг и где остаётся его результат. Разбор опирается на набор скиллов Matt Pocock версии 1.3.1 по состоянию на 8 октября 2026 года. Если ты уже ведёшь разработку через спецификации, начни с правила рабочих копий и правил поверх набора.
Почему одной просьбы мало
Платформа, которую ты строишь, должна позволять ответственному создать проект. Представь, что ты сразу просишь агента «сделай в платформе создание проектов». Чтобы выполнить просьбу, нужно решить, как ответственный создаёт проект, где хранится запись и как проверить результат. Если не обсудить и не сохранить решения заранее, они могут появиться только в коде. Следующей сессии придётся восстанавливать их причины. Пайплайн делает обсуждение и запись решений явными шагами, результат которых ты можешь проверить.
Пайплайн разработки делит работу на шаги с понятным результатом. Сначала договариваемся о поведении, затем записываем решение, делим его на задачи, реализуем и проверяем. Каждый шаг оставляет результат в проекте, и следующий шаг на него опирается.
Возьмём ту же просьбу о создании проектов и проведём её по шагам.
Вопросы. Агент спрашивает тебя о том, чего нет в требованиях. Что ответственный видит после создания проекта? Может ли название повторяться? Что происходит при ошибке сохранения? Вопросы идут раундами: агент присылает нумерованный список и к каждому вопросу предлагает свой ответ, а решаешь ты. Результат шага состоит из принятых решений.
Спецификация. Агент собирает решения в один документ. Спецификация описывает, что должно получиться, какое решение выбрано и как проверить результат. Основные решения нужно обсудить раньше. Способ проверки агент может уточнить, пока составляет документ.
Задачи. Агент делит спецификацию на задачи. У каждой есть небольшой законченный результат, который можно показать и проверить. Например, «созданный проект открывается после перезапуска приложения».
Реализация. Агент берёт одну задачу, пишет код и запускает проверки.
Ревью. Изменения сверяются со спецификацией и правилами проекта. Замечания возвращают работу на реализацию.
Pull request. Проверенные изменения оформляются как предложение для основной ветки. Его описание называет, что сделано и чем это подтверждено.
Какой скилл стоит за каждым шагом
Эти шаги можно каждый раз объяснять агенту заново. Удобнее взять готовые скиллы. Набор Matt Pocock ты уже поставил в проект в первом задании. Скиллы в нём разделены по задачам, их можно прочитать, сочетать и использовать по одному. В основе знакомые инженерные подходы, такие как уточнение требований, разработка через спецификации, тестирование и ревью.
grill-with-docs задаёт тебе вопросы, пока вы не договоритесь о поведении и решениях;
to-spec собирает согласованное в спецификацию и публикует её задачей в трекере;
to-tickets делит спецификацию на задачи с проверяемым результатом;
implement выполняет одну задачу через тесты, запускает ревью и делает коммит;
code-review сверяет изменения со спецификацией и правилами проекта;
pr задаёт форму описания pull request;
retro после трудной сессии предлагает, что поправить в harness, чтобы следующая прошла легче.
У самого автора эта цепочка выглядит так: grill-with-docs → to-spec → to-tickets → implement → code-review → retro. В наборе больше двадцати скиллов. Другой набор скиллов тоже подойдёт, если за каждым шагом стоит понятный способ работы, а результат шага остаётся в проекте.
Мой совет
Я ставлю набор целиком и пользуюсь тем, что нужно сейчас. Скиллы ссылаются друг на друга: например, grill-with-docs вызывает ещё два скилла, а implement опирается на скиллы тестирования и ревью.
Кто запускает шаг
Шаги не идут сами один за другим. Почти все скиллы цепочки помечены для запуска вручную, поэтому агент не вызывает их по своей инициативе, их вызываешь ты. В Claude Code это команда вида /grill-with-docs, в Codex $grill-with-docs. Исключения составляют code-review и pr: их агент вызывает и сам, например code-review изнутри implement. Каждый шаг проектирования запускаешь ты. Попросил задать вопросы, ответил на них. Попросил оформить спецификацию, прочитал её. Попросил разделить на задачи, посмотрел разбиение. Между шагами ты видишь результат и можешь его поправить, пока исправление стоит одного сообщения.
С задачами порядок другой. Основное поведение и границы задачи к этому моменту согласованы. Агент ведёт задачу от первого изменения до готового pull request. Если появляется существенный новый вопрос, агент возвращает его тебе. Действия из списка согласований тоже остаются за тобой. Сам implement доходит только до коммита, остальной путь до pull request задают правила процесса. Каждую задачу автор набора советует начинать в новой сессии, потому что задачи нарезаны так, чтобы каждая помещалась в один свежий контекст. Ты смотришь результат, сливаешь изменения в основную ветку и только потом запускаешь следующую задачу. Так ты проверяешь работу небольшими частями и замечаешь ошибку до того, как на ней построена следующая задача.
Процесс можно перестроить, когда появится опыт. Например, запускать несколько задач подряд. Начинай именно с этого порядка. В нём видно каждый результат.
Где остаётся результат
Результат шага должен пережить сессию. Часть результата лежит в репозитории, часть в трекере задач, а часть остаётся только в разговоре.
Задачи лежат в трекере задач, то есть в сервисе, где ведут список задач. В этом проекте это GitHub Issues. Issue называют запись в трекере с описанием, обсуждением и состоянием «открыта» или «закрыта». Набор хранит спецификацию в одной Issue, а задачи делает её подзадачами. Таблица показывает, что оставляет каждый шаг.
ADR (architecture decision record, запись об архитектурном решении) хранит выбранное решение и его причины. Например, docs/adr/0001-postgres.md объясняет выбор PostgreSQL.
Таблица в материале
Шаг
Скилл
Кто запускает
Что остаётся
Где
Настройка
setup-matt-pocock-skills
Ты, один раз на проект
Где лежат задачи, какие у них пометки, где глоссарий и записи о решениях
docs/agents/, раздел ## Agent skills в AGENTS.md
Вопросы
grill-with-docs
Ты
Термины проекта и записи о решениях, которые трудно отменить
GLOSSARY.md, docs/adr/
Спецификация
to-spec
Ты, в той же сессии, что и вопросы
Все решения разговора и места, где тесты будут проверять поведение
Issue с пометкой ready-for-agent
Задачи
to-tickets
Ты, разбиение одобряешь до публикации
Узкие задачи через все слои и связи между ними
Подзадачи Issue спецификации с пометкой ready-for-agent
Реализация
implement
Ты, одна задача на сессию
Код с тестами
Коммит в текущей ветке
Ревью
code-review
implement сам, агент или ты
Отчёт: соблюдены ли правила проекта и сделано ли то, что просила задача
Только в сессии
Pull request
pr
Агент по правилам процесса
Описание: что сделано, чем подтверждено, насколько рискованно слияние
Pull request в GitHub
Ретроспектива
retro
Ты, после трудной сессии
Предложения: указатель, проверка или правило
Правки появляются после твоего согласия
Обрати внимание на строку вопросов. Термины grill-with-docs записывает сразу, как только о них договорились. Запись о решении он только предлагает, и только если решение трудно отменить, оно неочевидно без контекста и выбрано из настоящих вариантов. Остальные решения остаются только в разговоре. У автора набора сессия, после которой появились только новые термины и ни одной записи о решении, считается нормальной. Поэтому to-spec запускают в той же сессии, пока разговор ещё в контексте. В новой сессии его уже нет, и спецификации не из чего собраться.
Проверьте понимание
Вы с агентом обсудили создание проектов в grill-with-docs. Агент записал два термина в GLOSSARY.md, записей о решениях нет. Когда запускать to-spec?
1.
Сразу, в той же сессии, где шли вопросы.
2.
Завтра, в новой сессии со свежим контекстом.
3.
Позже, когда агент запишет решения в docs/adr/.
У ревью похожая особенность. Отчёт code-review остаётся только в сессии, поэтому исходы замечаний переносят в pull request по правилам процесса.
Через несколько задач файлы harness и документы проекта могут выглядеть так. Код в дереве не показан.
ai-dev-platform/
├── AGENTS.md # инструкции и раздел Agent skills
├── GLOSSARY.md # термины проекта, ведёт grill-with-docs
├── .agents/skills/ # скиллы набора
├── .claude/skills # ссылка на .agents/skills для Claude Code
└── docs/
├── brief.md # бриф заказчика
├── agents/
│ ├── issue-tracker.md # где лежат задачи и как с ними работать
│ ├── domain.md # где глоссарий и записи о решениях
│ └── triage-labels.md # пометки задач, если установлен triage
├── adr/
│ └── 0001-postgres.md # решение, которое трудно отменить
└── workflow.md # правила процесса, их пишешь ты с агентом
В GitHub при этом лежат Issue спецификации, её подзадачи, ветки и pull request каждой задачи. Список задач может выглядеть так:
#2 Спецификация: создание и открытие проектов ready-for-agent
#3 Создание проекта: форма, сохранение, страница проекта ready-for-agent
#4 Список проектов и пустое состояние ready-for-agent, ждёт #3
#5 Ошибка сохранения ready-for-agent, ждёт #3
Пометка ready-for-agent означает, что задача описана полностью и агент может взять её без новых вопросов. to-spec ставит её и на саму спецификацию, а to-tickets на каждую задачу, даже на ту, что ждёт другую. Поэтому правила процесса говорят агенту, какую задачу брать: подзадачу с ready-for-agent, у которой закрыты все блокирующие задачи. Набор использует ещё несколько пометок. Например, ready-for-human ставят на работу, которую делает человек.
По такому списку видно всё состояние работы: что решено, что сделано, что можно начать. Новая сессия читает его и продолжает с нужной задачи.
Мой совет
Спецификацию я храню в Issue, а не файлом в репозитории, потому что рядом лежат её задачи, и Issue закрывается вместе с работой, а файл после готовой фичи устаревает. Решения, которые должны жить долго, записываю в документы проекта. Доску GitHub Projects я не веду, потому что состояние задачи видно по самой Issue, её пометке и pull request, а доску кто-то должен поддерживать.
Каждая задача в своей рабочей копии
Агент меняет файлы в той папке, где его запустили. Если две сессии работают в одной папке, они меняют одни и те же файлы и мешают друг другу. Даже одна сессия в основной папке оставляет там незаконченные изменения, и следующая задача начинается с чужого состояния. Поэтому каждой задаче дают свою рабочую копию.
Git worktree создаёт ещё одну рабочую копию того же репозитория в отдельной папке. История, ветки и настройки Git у копий общие, а файлы в каждой папке свои. У каждой копии своя ветка. Одну ветку нельзя открыть в двух копиях сразу, Git откажется это сделать. Работа с копиями выглядит так:
git worktree add ../platform-task-4 -b task-4 main # копия для задачи #4 и ветка task-4 от main
git worktree list # все рабочие копии
git worktree remove ../platform-task-4 # убрать копию после слияния
В новую копию попадают только файлы из Git. Файл .env с секретами, установленные зависимости и локальную базу в ней нужно завести заново. Если задачи идут одновременно, у каждой должны быть свои порты и своя тестовая база, иначе они помешают друг другу.
Агент может создать рабочую копию сам средствами Git или своего приложения. В новой копии он проверяет исходную версию, создаёт ветку задачи и готовит окружение. Так дальнейшая работа идёт с известного состояния.
Правило. Каждая задача, а вообще любая сессия, которая меняет файлы, начинается в новой рабочей копии от свежего main. В основной папке на main агент только читает, обсуждает и планирует. Так в main попадает только то, что прошло pull request, а основная папка остаётся чистой. После слияния копию убирают.
Правило записывают в правила процесса, а закрепить его можно механизмом. Git перед каждым коммитом запускает хук pre-commit, то есть скрипт из папки хуков. Хук может запретить коммит в main:
#!/bin/sh
# .githooks/pre-commit
if [ "$(git branch --show-current)" = "main" ]; then
echo "Коммит в main запрещён. Создай рабочую копию для задачи: git worktree add" >&2
exit 1
fi
Стандартная папка хуков .git/hooks не попадает в Git. Поэтому хук кладут в папку проекта, например .githooks, делают исполняемым (chmod +x .githooks/pre-commit) и включают командой git config core.hooksPath .githooks. Настройка общая для всех рабочих копий, но в каждом новом клоне репозитория её нужно включить заново. Флаг --no-verify пропускает хук, поэтому на GitHub основную ветку дополнительно защищают правилом, которое запрещает прямой push.
Параллельные задачи. Когда у каждой задачи своя копия, независимые задачи можно вести одновременно. На схеме показаны две будущие задачи MCP-сервера: они начинают работу от одной проверенной версии и попадают в основную ветку по очереди. Приём и проверка совместного результата появятся в главе 2.
Когда нужен wayfinder
grill-with-docs рассчитан на одну сессию. Все решения принимаются в одном разговоре. Бывает работа больше. Решений много, одни зависят от других, а для некоторых сначала нужно что-то выяснить или попробовать. Для такой работы в наборе есть скилл wayfinder. Его тоже запускаешь ты.
Wayfinder строит в трекере карту. Карта состоит из одной Issue с пометкой wayfinder:map и её подзадач. Каждая подзадача карты задаёт вопрос, ответом на который становится решение, а не часть кода. Подзадачи бывают четырёх видов:
обсуждение (grilling): вопрос решаете вы с агентом в разговоре;
прототип (prototype): агент делает черновой образец, например экран, а решаешь ты, посмотрев на него;
поиск (research): агент сам ищет факты в документации или внешних сервисах;
подготовка (task): нужно что-то сделать, чтобы решение стало возможным, например получить доступ к сервису.
Одна сессия закрывает один вопрос: записывает ответ в его Issue, закрывает её и добавляет в карту строку со ссылкой. Поиск устроен иначе. Такие вопросы решают отдельные агенты параллельно, их запускают сразу после построения карты. Вопросы, которые пока нельзя сформулировать точно, лежат в разделе карты «Not yet specified». Когда ответы проясняют их, они становятся новыми подзадачами.
Пометки карты (wayfinder:map, wayfinder:grilling и другие) скилл в GitHub не создаёт, поэтому перед первой картой попроси агента их создать.
Когда вопросов не осталось, wayfinder останавливается и код не пишет. Дальше идёт обычный путь: to-spec собирает решения карты в спецификацию, а to-tickets делит её на задачи.
Выбор зависит от числа сессий. Если решения помещаются в один разговор, бери grill-with-docs, потому что он быстрее и дешевле. Wayfinder нужен, когда работа не помещается в одну сессию, а путь к результату пока не виден. Автор набора называет его самым тяжёлым скиллом. Карта на весь продукт разрастается, и поздние вопросы устаревают раньше, чем до них дойдёт очередь. Поэтому у карты должна быть ограниченная цель, например одна конкретная спецификация, а не «сделать всю первую версию». В главе 2 первая версия платформы (MVP, minimum viable product) строится по этапам, и каждый этап обычно помещается в разговор grill-with-docs. Wayfinder там понадобится, если вопросов этапа слишком много для одной сессии.
Короткий путь для мелкой правки
Не каждой работе нужны все шаги. Сравни две просьбы.
Таблица в материале
Работа
Путь
Исправить подпись на кнопке
Задача → реализация → ревью → pull request
Создание и открытие проектов
Вопросы → спецификация → задачи → реализация → ревью → pull request
Первый путь подходит, когда решать нечего и результат помещается в одну задачу. Достаточно описать её в Issue. Второй путь нужен фиче, то есть новой возможности для пользователя, в которой есть что выбирать. Реализация, ревью и pull request остаются в обоих путях. Сокращается только проектирование. Если сомневаешься, начни с вопросов, потому что короткое обсуждение стоит дешевле, чем переделка готового кода.
Чего в наборе нет
Набор описывает шаги, но часть вопросов оставляет проекту. В какой ветке агент работает? Кто сливает pull request? Какая команда подтверждает, что задача готова? Что агент согласует с тобой? Скилл implement, например, заканчивается на коммите в текущую ветку. Ветку он не создаёт, pull request не открывает и задачу в трекере не закрывает. Есть и техническая деталь. code-review смотрит только закоммиченные изменения, а implement вызывает его до своего коммита. Без промежуточного коммита ревьюер не увидит изменений.
Ответы на эти вопросы записывают в самом проекте, в коротком файле с правилами процесса. Его начало может выглядеть так:
# Процесс разработки
Фича идёт так: вопросы → спецификация → задачи → реализация → ревью → pull request.
Мелкая правка идёт так: задача → реализация → ревью → pull request.
Вопросы, спецификацию и разбиение на задачи запускаю я.
Бери подзадачу спецификации с пометкой ready-for-agent, у которой закрыты
все блокирующие задачи. Веди её до готового pull request. Существенные новые вопросы и действия
из списка согласований возвращай мне. Путь задачи:
новая рабочая копия и ветка task-<номер> от свежего main, реализация, коммит со ссылкой #<номер>, code-review от main,
исправление замечаний и повторное ревью, проверенный коммит и исходы замечаний
в описании pull request, pull request с Closes #<номер>.
Pull request сливаю я.
В файл попадает только то, о чём набор молчит. Пересказывать в нём скиллы не нужно. Сначала стоит прочитать, как задачу решает сам автор набора. У него часто уже есть более простой ответ.
Как понять, что пайплайн помогает
Открой новую сессию посреди работы и спроси агента, на чём остановились. Пайплайн работает, если агент по Issue, спецификации и правилам процесса называет следующую задачу и не спрашивает о решениях, которые вы уже приняли. Второй признак виден в ревью. Замечания касаются кода, а не поведения, о котором вы не договорились.
Углубление
Набор скиллов Matt Pocock. В папках docs/engineering и docs/productivity автор описывает каждый скилл: когда его брать, что он оставляет и чего не делает. Начни с implement.md, там разобраны частые вопросы о коммите, pull request и ревью.
Попроси агента открыть один скилл из набора и объяснить, что он делает на каждом шаге и какой результат оставляет.
Где пригодится
В задании «Заложи основу проекта» ты записываешь правила процесса и проводишь по ним задачи основы до слитого pull request. В главе 2 по тем же правилам идут задачи MVP.