Capstone: A Feature from Spec to PR

Капстоун начинается не с кода, а с рамки. Выберите фичу среднего размера: день работы, три—семь файлов, ясная ценность для пользователя. Сформулируйте критерии приёмки списком проверяемых утверждений: «фильтр по статусу работает на бэке и в UI», «пустой результат показывает заглушку», «тесты покрывают граничные случаи фильтра».

Переведите Claude Code в режим планирования — циклом Shift+Tab до plan mode или флагом --permission-mode plan. В этом режиме агент читает и анализирует, но не правит: попросите его исследовать код, предложить план по шагам и оценить риски. Спорьте с планом: «почему миграция, а не вычисляемое поле?», «что сломается у существующих пользователей?» — менять решение на этом этапе дешевле всего, дальше цена растёт с каждым шагом.

Согласованный план зафиксируйте в файл PLAN.md: шаги с чек-боксами, критерии приёмки, открытые вопросы. Это не бюрократия, а чекпойнт: контекст сессии смертен, файл — нет. Любая новая сессия — после /clear, обрыва связи или на следующее утро — продолжит с плана, а не с археологических раскопок. Железное правило капстоуна: ни одной правки кода, пока план не записан и не согласован.

Работа идёт в изоляции: git worktree add и отдельная ветка feat/... — основной каталог остаётся свободным для параллельных дел и срочных фиксов.

Двигайтесь по плану шагами: один шаг — одно проверяемое состояние — один коммит. После каждого зелёного шага коммитьте поимённо и отмечайте чек-бокс в PLAN.md. Этот ритм даёт три вещи: откат на шаг назад вместо отката всей работы, читаемую историю для ревьюера и устойчивость к обрывам — сессия может умереть, прогресс не умрёт.

Делегируйте независимое. Пока основная сессия ведёт бэкенд-логику, субагент пишет тесты по согласованному контракту API, второй — обновляет документацию. Правила из урока о параллельности действуют в полную силу: разные файлы или разные worktree, зависимые шаги — строго последовательно, отчёты — с доказательствами.

Решения, принятые по ходу («индекс по created_at, а не по id»), фиксируйте немедленно: через # в память или строкой в PLAN.md. Устные договорённости с агентом не переживают /compact. И следите за размером шага: если шаг разросся и дифф пухнет — остановитесь и разбейте его в плане. Гигантский дифф в конце — самый дорогой способ узнать, что вы свернули не туда на втором часу работы.

Финальная проверка строится на доказательствах, а не на «агент сказал, что готово». Минимальный чек-лист.

• Полный прогон тестов и линтера — вывод команд в терминале, а не пересказ. Упавший тест возвращает вас на шаг исполнения.
• git diff против основной ветки: каждый файл в диффе объясним задачей. Случайные переформатирования, забытые отладочные строки и чужие файлы — вычистить до ревью.
• Критерии приёмки из PLAN.md проходятся по одному, руками или скриптом, с отметкой результата.

Подключите второй взгляд: команда /review или свежий субагент-ревьюер с промптом «найди проблемы в этом диффе: краевые случаи, безопасность, производительность». Свежий контекст видит то, к чему замылился основной: он не знает истории ваших решений и потому проверяет их заново, без презумпции правильности. Замечания дешевле исправить сейчас, чем в ревью коллеги.

Отдельным пунктом — негативные сценарии: пустой ввод, недоступный внешний сервис, повторный запрос, конкурентное изменение. Агенты отлично пишут счастливый путь и систематически недописывают обработку ошибок — это самое частое замечание на ревью агентского кода. Проверяйте несчастливые пути осознанно, они не проверятся сами.

Публикация — стандартный финал:

git push -u origin feat/search-filters
gh pr create --base dev \
  --title "feat(search): фильтры по статусу и дате" \
  --body-file PR_DESCRIPTION.md

Описание PR пишите для ревьюера: что сделано и зачем, как проверено (вывод тестов, скриншоты), на что смотреть особенно внимательно. Рабочий приём — попросить агента собрать черновик описания из PLAN.md и истории коммитов, а затем отредактировать руками: фактура агентская, акценты ваши.

После мержа — разбор полётов, самый недооценённый шаг цикла. Три вопроса. Где агент ошибся и почему — постановка, контекст, недостающее правило? Какое правило добавить в CLAUDE.md, чтобы ошибка не повторилась? Какой процесс упаковать в команду, hook или skill? Примеры из практики: агент трижды забывал прогнать миграции — это кандидат в hook; вы трижды писали один и тот же промпт проверки — это команда; ревьюер трижды объяснял правила дизайн-системы — это skill.

Каждый капстоун должен делать следующий дешевле: фича уходит команде, выводы — в конфигурацию проекта. Это и есть агентная разработка как система, а не серия удачных сессий. На этом курс закончен — дальше система растёт сама, задача за задачей.