Набор навыков Мэтта Поукока: процесс «разбор, спека, тикеты, реализация, ревью»

Vibe coding — это весело, пока код не сталкивается с настоящим продуктом. Вы описываете фичу, агент кивает и выдаёт гору кода, появляется пулл-реквест, который выглядит очень деловито. А потом всплывают проблемы. Поведение не совсем такое, как представляла команда, объяснение полно жаргона, крайний случай ломает оформление заказа, а существующий код тихо стало труднее менять.

Страшно не то, что агент пишет плохой код, — люди делают то же самое. Страшно то, что агент ускоряет недопонимание. Размытый запрос превращается в крупную, убедительную и дорогую ошибку.

Репозиторий навыков Мэтта Поукока — практичный ответ на это. Его README называет себя «Skills For Real Engineers» (навыки для настоящих инженеров): маленькие инструкции, которые можно вызвать, когда нужна конкретная помощь. Идея не в том, чтобы отдать весь процесс разработки гигантскому фреймворку. Она в том, чтобы дать агенту несколько надёжных приёмов для моментов, где важно инженерное суждение.

Агент оправдывает себя тем, что сначала притормаживает на опасных участках работы и только потом ускоряет набор кода.

Что входит в набор

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

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

Нужна разовая настройка на каждый репозиторий. Установите набор одним из этих двух вариантов, но никогда обоими:

claude plugins install mattpocock-skills

или:

npx skills@latest add mattpocock/skills

Затем один раз выполните это внутри репозитория:

/setup-matt-pocock-skills

Во время настройки агент узнаёт локальную структуру, включая трекер задач, метки для триажа и пути к документации. Это не ежедневная рутина. Это контекст, который иначе пришлось бы каждый раз заново открывать, угадывать или забывать.

Почему промпта недостаточно, но и огромный процесс не решение

Промпт выражает желание. Он не может надёжно нести все решения, спрятанные внутри одного короткого продуктового предложения.

«Добавить сохранённые корзины в витрину» звучит ясно, пока кто-нибудь не спросит, что хранит сохранённая корзина, кто может её видеть, что происходит при изменении остатков, фиксируются ли цены и где фиче место. Один промпт хоронит эти вопросы под единственной командой: построй это.

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

Этот набор находится между этими крайностями. Сфокусированные навыки нацелены на сфокусированные режимы отказа. Идею можно разобрать, долговечную спеку можно написать, когда это оправдано, а тикеты можно подогнать под используемый трекер. Для однострочной опечатки почти всё это можно пропустить. По сравнению с фреймворком, который берёт на себя весь воркфлоу, маленькие навыки проще комбинировать, читать и заменять.

На какие сбои он нацелен

README полезен тем, что называет конкретные сбои и не относится к AI-кодингу как к единому волшебному действию.

• Рассогласование. Агент строит правдоподобную трактовку, которая не та, что задумывалась. grill-me напрямую допрашивает идею, а grill-with-docs вносит в разговор документацию репозитория и контекст предметной области.
• Многословный жаргон. Ответ может звучать уверенно и всё равно оставить продукт более запутанным, чем раньше. Поток, ориентированный на документацию, может фиксировать контекст в CONTEXT.md и в ADR, а domain-modeling делает ключевые понятия явными, чтобы они не растворялись в именах вроде data, item или manager.
• Код, который не работает. Для реализации через тесты воркфлоу указывает на /tdd, а на diagnosing-bugs — когда сбойное поведение требует расследования вместо очередной спекулятивной заплатки.
• Ком грязи. Когда фиче нигде нет места, ещё одна абстракция не всегда лечение. to-spec, improve-codebase-architecture и codebase-design делают форму системы видимой и помогают улучшать её осознанно.

Несколько навыков маршрутизации и координации дополняют картину. ask-matt помогает выбрать путь, wayfinder поддерживает планы на несколько сессий, handoff сохраняет состояние, wait-what проверяет понимание, а triage разбирает, что должно случиться дальше.

Конвейер

Основной поток связывает пять шагов:

/grill-with-docs -> /to-spec -> /to-tickets -> /implement -> /code-review

Под капотом /implement управляет /tdd. У каждого шага одна задача, и его результат даёт следующему шагу что-то конкретное для работы.

1. Разобрать идею

Начните с /grill-with-docs, когда фича затрагивает и продуктовые, и технические вопросы. Опишите, чего хотите, и попросите агента оспорить предположения, опираясь на документацию репозитория.

В примере с сохранённой корзиной полезные вопросы идут раньше любого кода. Привязана ли сохранённая корзина к аккаунту? Может ли один клиент держать несколько? Перепроверяет ли восстановление остатки и цену? Это снимок или указатель на живой каталог? Можно ли ею поделиться? Что видит пользователь, когда товар сняли с продажи?

Цель не в бесконечном интервью. Она в том, чтобы вытащить наружу решения, которые, если оставить их открытыми, по умолчанию примет реализация.

Когда идея уже хорошо понятна, хватит более лёгкого grill-me. Если агент начинает использовать термины, которых нет у команды, попросите CONTEXT.md, ADR или проход domain-modeling. Короткий общий словарь стоит больше длинного ответа.

2. Превратить решения в спеку

Имея ответы, запустите /to-spec. Спека указывает, что фича делает, чего не делает и как существующая система распознает успех.

Возьмём витрину на TypeScript. Её спека могла бы описывать сохранённую корзину как именованный список, принадлежащий вошедшему в систему клиенту. Хранятся только ID товаров и количества, без замороженных цен и остатков. При восстановлении доступность проверяется заново, а строки, которые нельзя выполнить, проходят через уже существующую обработку ошибок. Гостей просят войти.

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

3. Превратить спеку в тикеты

Запустите /to-tickets, когда спека достаточно устойчива, чтобы её делить. Тикеты должны описывать срезы, которые можно построить и отревьюить, а не список расплывчатых отделов. Один разумный способ нарезать эту фичу:

1. Модель предметной области и слой хранения для корзин, принадлежащих вошедшим клиентам.
2. Команды плюс валидация для сохранения, списка, переименования, удаления и восстановления.
3. Шаг восстановления, который заново проверяет остатки и сегодняшние цены.
4. Экраны витрины, включая состояния загрузки, пустоты и ошибки.
5. Интеграционные тесты для правил доступа, отсутствующих товаров и чистого восстановления.

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

4. Реализовать с тестами впереди

Теперь запустите /implement. Он управляет /tdd, так что агент отталкивается от наблюдаемого поведения, пишет падающий тест, делает минимальное изменение, которое его проходит, и держит набор тестов в работе, пока продвигается по тикетам.

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

Если тест падает, не просите случайных правок, пока красное не станет зелёным. Используйте diagnosing-bugs, чтобы расследовать. Считайте падающий тест свидетельством о системе, а не препятствием на пути к зелёной галочке.

Иногда работа показывает, что спека была ошибочной. Тогда правильный ход — вернуться к ней, ведь ничто не заставляет этот воркфлоу идти по прямой. Цель — держать решение, тикет, тест и код рассказывающими одну и ту же историю, а не защищать то, что написали первым.

5. Отревьюить результат

Завершите с /code-review. Это больше, чем проверка стиля. Ревьюеры ищут согласие между поведением и спекой, тесты, которые действительно покрывают важные случаи, уважение к уже существующей архитектуре и публичную поверхность, оставленную как можно меньшей.

Добротное ревью может вскрыть логику восстановления, которой место в сервисе оформления заказа, уже имеющемся в кодовой базе, эндпоинт списка без проверки авторизации или интерфейс, позволяющий купить товар, которого больше нет. Оно также может обнаружить, что фича корректна, но границе модуля стало труднее следовать. Вот когда improve-codebase-architecture или codebase-design могут помочь как продолжение, а не как ритуал, навязанный каждому изменению.

Финальное ревью защищает кодовую базу от фичи, прошедшей только собственные узкие тесты.

Что отличает его

Воркфлоу разделяет виды мышления, которые агенты склонны смешивать. Прояснение продуктового решения — это не проектирование модуля, проектирование модуля — это не написание теста, а проходящий тест не доказывает, что фиче место в текущей архитектуре.

Суждение остаётся в руках человека. Можно остановиться после разбора, переписать спеку, выбросить предложенное деление на тикеты или позволить ask-matt подсказать нужный навык. wayfinder покрывает планы на несколько сессий, handoff хранит контекст, wait-what проверяет запутанный запрос, а triage выбирает следующий кусок работы.

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

Когда его пропустить

Для однострочной опечатки, небольшой правки текста или одноразового локального эксперимента всё это избыточно. У настройки есть цена, пусть и платится она раз на репозиторий, а намеренные паузы не бесплатны, когда изменение действительно тривиально.

Руководствуйтесь здравым смыслом. Изменения, затрагивающие бизнес-правила, границы модулей, хранимые данные, права доступа или публичный API, оправдывают паузу, ведь она стоит меньше, чем уборка после уверенного недопонимания. Всё остальное может пойти напрямик.

Начать с малого — вполне нормально. Выберите один путь установки, запустите /setup-matt-pocock-skills в настоящем репозитории и попробуйте /grill-me на следующей фиче, которая кажется ясной, но на деле нет. Когда изменение заслуживает полного пути, продолжите прогон через /grill-with-docs и дальше к спекам, тикетам, /implement и /code-review.

Выгода не в большем числе строк в час. Просто меньше неверных предположений попадает в код изначально. Это куда менее эффектное обещание, чем vibe coding, и именно оно держится, когда магазин уже работает, а код наследует другой инженер.