# Matt Pocock Skills: как превратить AI-агента из генератора кода в инженера > Разбор mattpocock/skills: скиллы для Claude Code и Codex, с которыми агент сначала допрашивает вас, пишет спецификацию и режет её на задачи, а потом пишет код через TDD и проверяет ревью по двум осям. Источник: https://blog.uspeshnyy.ru/blog/matt-pocock-skills/ Автор: Александр Успешный · blog.uspeshnyy.ru Опубликовано: 2026-09-12 Теги: Claude, AI-агенты, инструменты, система --- Знакомый сценарий. Пишете агенту «сделай мне фичу» — через минуту получаете 800 строк. Код собирается, выглядит солидно и делает не совсем то, что вы имели в виду. Дальше полдня уходит на объяснения, что именно было «не то». Дело не в модели. Между вами и агентом тот же разрыв, что между заказчиком и разработчиком: вы уверены, что всё объяснили, а он додумал остальное сам. Мэтт Покок — преподаватель TypeScript, автор Total TypeScript и AI Hero — собрал репозиторий [skills](https://github.com/mattpocock/skills) как раз вокруг этого разрыва. Это не очередная папка с промптами, а набор небольших инструкций, которые ведут агента по инженерному процессу: понять задачу, записать её, разбить на части и только потом писать код. ![Два способа работы с агентом: «сделай фичу» и 800 строк в ответ — или сначала вопросы, спека и задачи, и только потом агент берётся за код](/images/posts/matt-pocock-skills-1.webp) ## Что это за репозиторий Описание на GitHub короткое: «Skills for Real Engineers. Straight from my .agents directory» — скиллы, которые автор сам использует каждый день. В README формулировка резче: для настоящей инженерии, а не для vibe coding. - **Масштаб.** На 12 сентября 2026 года — больше 260 тысяч звёзд и около 22 тысяч форков. Репозиторий появился в феврале 2026-го, лицензия MIT. - **Совместимость.** Claude Code, Codex и другие агенты. Автор отдельно подчёркивает, что скиллы работают с любой моделью. - **Состав.** В плагин входят 25 скиллов, ещё несколько лежат в папках для редкого и бета-версий. | Группа | Что внутри | Примеры | |---|---|---| | Engineering, 18 скиллов | Ежедневная работа с кодом | `grill-with-docs`, `to-spec`, `to-tickets`, `implement`, `tdd`, `diagnosing-bugs`, `code-review` | | Productivity, 7 скиллов | Рабочие инструменты не про код | `grill-me`, `handoff`, `teach`, `wait-what`, `to-questionnaire` | | misc и in-progress | Редкое и бета, в плагин не входят | `git-guardrails-claude-code`, `setup-pre-commit` | Самое интересное в README — позиция автора. Подходы вроде GSD, BMAD и Spec-Kit, пишет Покок, пытаются помочь тем, что забирают процесс себе. Но вместе с процессом они забирают у вас контроль, а ошибку внутри чужого процесса трудно исправить. Его скиллы задуманы наоборот: маленькие, легко переделываются под себя и собираются друг с другом как детали конструктора. ### Две породы скиллов Одна архитектурная деталь многое объясняет. Скиллы делятся на два типа: - **Вызываемые человеком** — `/grill-me`, `/to-spec`, `/implement`. Срабатывают, только когда вы их набрали. Их работа — дирижировать. - **Вызываемые моделью** — `tdd`, `code-review`, `diagnosing-bugs`. Агент берёт их сам, когда задача подходит. В них живёт переиспользуемая дисциплина. Правило одно: скилл первого типа может вызывать скиллы второго, но никогда — другой скилл первого. Поэтому `/implement` внутри сам гоняет тесты и ревью, а переход «спека → задачи → код» запускаете вы, шаг за шагом. По процессу агент без вас не уедет. ## Четыре поломки, которые он чинит README построен не вокруг списка скиллов, а вокруг поломок — ситуаций, в которых агент подводит. На каждую есть своё лекарство. ![Четыре поломки агента: сделал не то — допрос, много слов — словарь, не работает — тесты, ком грязи — модули](/images/posts/matt-pocock-skills-2.webp) ### 1. Агент сделал не то, что вы хотели Лечится допросом. Скилл `grilling` и две обёртки над ним — `/grill-me` и `/grill-with-docs` — заставляют агента интервьюировать вас, пока не останется ни одного решения, принятого молча. Автор называет их самыми популярными в репозитории и советует запускать перед каждым изменением. Устроено это аккуратнее, чем «задай мне вопросы»: - **Решения складываются в дерево.** Каждое тянет за собой решения, которые от него зависят. - **Вопросы идут раундами.** В раунд попадает всё, на что можно ответить прямо сейчас, не угадывая ответы на ещё открытые вопросы. - **К каждому вопросу — рекомендуемый ответ.** Вам остаётся согласиться или поправить. - **Факты агент ищет сам.** Если для вопроса нужно заглянуть в файлы, он отправляет субагента, а не спрашивает вас. Решения остаются за вами. - **Допрос кончается, когда дерево пройдено целиком.** И даже тогда агент ничего не делает, пока вы не подтвердите, что договорились. Разница с обычным «уточни детали» — в последнем пункте. Агент не останавливается на трёх вопросах для приличия: он идёт по дереву, пока неизвестных не останется. Это тот же приём, что и [поиск «неизвестных» при работе с Claude](/blog/fable-5-poisk-neizvestnyh/), только оформленный в процедуру. ### 2. Агент говорит двадцать слов там, где хватит одного Агента бросают в проект и заставляют разбираться в местном жаргоне на ходу. Отсюда длинные описательные обороты вместо одного термина. Лекарство взято из предметно-ориентированного проектирования Эрика Эванса — общий язык проекта. В репозитории это файл `CONTEXT.md`, глоссарий терминов. Пример из README. Было: «проблема возникает, когда урок внутри раздела курса становится "настоящим", то есть получает место в файловой системе». Стало: «проблема с каскадом материализации». Сам репозиторий ведёт такой словарь для себя. Фрагмент его `CONTEXT.md`: ```markdown **Issue tracker**: The tool that hosts a repo's issues: GitHub Issues, Linear, a local `.scratch/` markdown convention, or similar. _Avoid_: backlog manager, backlog backend, issue host ``` Главное здесь — строка `_Avoid_`: она запрещает синонимы, которые размывают смысл. Внизу файла есть раздел о спорных словах: там записано, что «backlog» означало одновременно инструмент и объём работы и как это разрешили. Словарь пополняется сам. Пока идёт допрос `/grill-with-docs`, скилл `domain-modeling` уточняет термины и записывает трудно обратимые решения в ADR — короткие документы «что решили и почему». Автор считает этот приём, возможно, самым сильным во всём репозитории: переменные и файлы называются единообразно, агенту проще ориентироваться в коде, и он тратит меньше токенов на размышления. Если у вас уже есть [CLAUDE.md](/blog/shablon-claude-md/), `CONTEXT.md` его не заменяет, а дополняет. Первый объясняет агенту, как работать в проекте, второй — как в нём называть вещи. ### 3. Код не работает Если агент понял задачу, но всё равно пишет ерунду, — у него нет обратной связи. Нужны типы, доступ к браузеру и автотесты. **`tdd`** — цикл «красный → зелёный»: сначала падающий тест, потом ровно столько кода, чтобы тест прошёл. Что в нём ценного: - **Тесты только на согласованных швах.** Шов — публичная граница модуля, через которую видно поведение. До первого теста агент перечисляет швы и подтверждает их с вами. - **Вертикальные срезы.** Один тест → одна реализация → следующий тест. Не «сначала все тесты, потом весь код»: такие тесты проверяют воображаемое поведение. - **Список анти-паттернов.** Мой любимый — тавтологический тест вида `expect(add(a, b)).toBe(a + b)`. Он проходит всегда, потому что считает ожидаемое значение тем же способом, что и сам код. - **Рефакторинг — не часть цикла.** Он уходит на этап ревью. **`diagnosing-bugs`** — для трудных багов. Первое правило: никаких гипотез, пока нет тугой петли обратной связи — одной команды, которая уже краснеет именно на этом баге. В скилле десять способов её построить: от падающего теста и curl-скрипта до `git bisect run` и сравнения старой и новой версии. Формулировка автора: постройте правильную петлю — и баг исправлен на 90%. ### 4. Кодовая база превращается в ком грязи Агенты ускоряют написание кода — и так же ускоряют энтропию. Проекты, собранные агентами, быстро становятся сложными и трудно меняются. Лекарство автор называет радикальным: заботиться о дизайне кода. Опора — «глубокие модули» Джона Остерхаута, много поведения за маленьким интерфейсом. Словарь этой дисциплины — модуль, интерфейс, глубина, шов, адаптер — держит скилл `codebase-design`. А `/improve-codebase-architecture` проходит по проекту, ищет модули, которые стоит углубить, и выдаёт кандидатов HTML-отчётом. Запускать его автор советует раз в несколько дней и честно предупреждает: это обзор, а не спасение. Старый запутанный проект он найдёт где улучшить, но распутывать за вас не будет. Про соседнюю проблему — как вообще отучить агента писать лишнее — есть разбор [Ponytail](/blog/ponytail-kak-nauchit-ai-agenta-ne-generirovat-lishniy-kod/). ## Главный маршрут: от идеи до коммита Скиллы задуманы как детали, но складываются в маршрут. Его описывает отдельный скилл-навигатор `/ask-matt`: ему можно описать ситуацию и спросить, с чего начать. **1. `/grill-with-docs`** — допрос. Если вопрос не решить на словах — нужно увидеть логику, состояние или интерфейс, — маршрут делает крюк: `/handoff` переносит разговор в отдельную сессию, `/prototype` отвечает на вопрос одноразовым кодом, второй `/handoff` возвращает выводы. **2. `/to-spec`** — превращает разговор в спецификацию. Второго допроса не устраивает: собирает то, что уже обсуждено, и сверяет с вами только швы для тестов. В шаблоне — проблема глазами пользователя, решение, длинный список пользовательских историй, решения по реализации и тестам, что вне рамок. Путей к файлам и кусков кода в спецификации быть не должно: они устаревают быстрее, чем решения. **3. `/to-tickets`** — режет спецификацию на задачи-«трассирующие пули». Каждая проходит тонким, но полным срезом через все слои — схему данных, API, интерфейс, тесты — и проверяется сама по себе. У каждой указаны блокеры: какие задачи должны закончиться раньше. Задачу без блокеров можно брать сразу. Прежде чем публиковать, агент спрашивает вас, не слишком ли мелко или крупно нарезано. **4. `/implement`** — по одной задаче. Внутри гоняет `tdd`, регулярно проверяет типы, в конце прогоняет весь набор тестов и `code-review`, потом коммитит. Небольшую задачу маршрут пропускает через укороченную ветку: без спецификации и нарезки, `/implement` сразу в том же окне. ### Гигиена контекста Эта часть мне кажется самой полезной, потому что применима к любой работе с агентом: - **Допрос, спецификация и нарезка — в одном непрерывном окне.** Без сжатия и очистки: все три шага строятся на одном и том же мышлении. - **Каждый `/implement` — с чистого листа.** Между задачами — `/clear`. Задача самодостаточна, контекст предыдущей не нужен. - **Следите за «умной зоной».** Автор оценивает её примерно в 150 тысяч токенов у современных моделей: в этих пределах модель ещё рассуждает чётко. Если окно подходит к пределу раньше нарезки — сжимайте на ближайшей границе этапа, а не тяните дальше на деградировавшем контексте. Подробнее о том, почему [контекст портится раньше, чем кажется](/blog/claude-code-rukovodstvo-inzhenera/). У маршрута есть два входа сбоку. **`/triage`** разбирает входящие баг-репорты и запросы, которые создали не вы, и превращает их в задачи, готовые для агента. **`/wayfinder`** — для огромных туманных проектов, которые не помещаются в одну сессию: чертит карту задач-решений и закрывает их по одной, пока путь не прояснится. Автор называет его самым тяжёлым потоком и советует не тратить на хорошо очерченные фичи. ## Ревью по двум осям Если забирать из репозитория что-то одно, я бы начал с `code-review`. Он проверяет изменения с фиксированной точки — коммита, ветки, тега — по двум независимым осям. - **Стандарты.** Соответствует ли код правилам репозитория и базовому набору «запахов» Мартина Фаулера: загадочные имена, дублирование, функция, которая больше работает с чужими данными, чем со своими, правка, разбросанная по десятку файлов. Правило репозитория всегда главнее базового набора, а каждый запах — повод присмотреться, а не приговор. - **Спецификация.** Делает ли код то, что просили: чего не хватает, что добавлено сверх заказа, что реализовано, но похоже на ошибку. Каждое замечание — с цитатой из спецификации. Обе проверки идут параллельно, в отдельных субагентах, чтобы одна не засоряла контекст другой. И результаты намеренно не сливаются в общий список. Причина простая: изменение может пройти одну ось и провалить другую. Код написан по всем правилам, но делает не то — стандарты пройдены, спецификация провалена. Код делает ровно то, что просили, но ломает соглашения проекта — наоборот. В общем списке одно маскирует другое. Как устроены такие параллельные ветки с проверкой свежим контекстом, разбирал в статье про [инженерию графов](/blog/inzheneriya-grafov/). ## Что забрать, даже если вы не пишете код Половина идей работает за пределами программирования — автор сам вынес их в группу Productivity. - **`/grill-me`** — тот же допрос, но без репозитория и без записи файлов. Подходит для плана запуска, структуры лендинга, коммерческого предложения. - **`/to-questionnaire`** — когда ответ знает не вы, а другой человек: клиент, юрист, подрядчик. Скилл расспрашивает вас не о теме, а об отправке — кому, что нужно получить назад — и собирает анкету в Markdown. - **`/wait-what`** — на случай, когда ответ агента не дошёл. Он пересказывает простым языком, добавляя недостающий контекст и слова из словаря проекта. - **`/handoff`** — сжимает разговор в документ для следующей сессии или коллеги. Со списком рекомендуемых скиллов, со ссылками вместо копий того, что уже записано, и с вырезанными ключами и паролями. - **`/teach`** — учит новой теме за несколько сессий и хранит прогресс в папке. Ниже — промпт по мотивам `grilling` для любой задачи. Это не перевод скилла, а его принцип, который работает в обычном чате: ```text Проведи со мной жёсткое интервью по плану ниже, пока мы не договоримся по каждому решению. Правила: 1. Разложи план на дерево решений: каждое решение тянет за собой те, что от него зависят. 2. Задавай вопросы раундами. В раунд попадают только вопросы, на которые можно ответить сейчас, не зная ответов на ещё открытые. 3. Нумеруй вопросы и к каждому сразу пиши свой рекомендуемый ответ. 4. Всё, что можно узнать из приложенных материалов, выясняй сам, не спрашивай меня. Решения оставляй мне. 5. После моих ответов пересобери дерево и задай следующий раунд. 6. Закончи, когда открытых решений не останется. Ничего не делай, пока я не подтвержу, что мы договорились. План: <опишите задачу> ``` ## Как установить Путей два, и за ними две философии. Ставить оба не нужно — получите каждый скилл дважды. Если сам формат скиллов для вас в новинку, начните с разбора [что такое скиллы AI-агента и чем они отличаются от MCP и CLAUDE.md](/blog/chto-takoe-skilly-ai-agenta/). **Claude Code — плагином.** Он есть в официальном маркетплейсе и обновляется сам, когда автор выпускает изменения. Вы подписываетесь на набор, а не копируете его: ```bash claude plugins install mattpocock-skills ``` **Codex и другие агенты — копией файлов.** Скиллы ложатся в проект обычными файлами, которые можно править. Этот путь подходит и для Claude Code, если хотите переделывать скиллы под себя. Обновления — вручную, командой `npx skills update`. Нативного плагина для Codex пока нет, он в планах. ```bash npx skills@latest add mattpocock/skills ``` **Дальше — один раз на каждый репозиторий:** `/setup-matt-pocock-skills`. Он спросит, где вести задачи — GitHub, Linear или локальные файлы, — какими метками размечать входящие и куда складывать документы. При установке через `npx` отметьте этот скилл в списке: без него инженерные скиллы не знают, куда писать. Если вы ещё не работали в терминальном агенте, начните с разбора [Claude Code для нетехнарей](/blog/claude-code-dlya-netehnarey/). ## Честно о границах - **Это процесс, и он медленнее.** Допрос по дереву решений занимает время. Для правки в три строки он не нужен, и сам маршрут это учитывает. - **Нужен трекер задач.** Инженерная часть рассчитана на то, что спецификации и задачи где-то живут. Хватит и локальных файлов, но настроить придётся. - **Тесты — ваша инфраструктура.** `tdd` и `diagnosing-bugs` сильны ровно настолько, насколько быстро проект позволяет прогнать тест. Где тестов нет, начинать придётся с них. - **Скиллы на английском.** Агенту это не мешает, человеку при чтении и правке — возможно. - **Это не спасение.** Автор пишет так про обзор архитектуры, но относится это ко всему набору: запутанный проект скиллы не распутают, они дают дисциплину на будущее. ## Вывод Главное в репозитории — не конкретные скиллы, а мысль, на которой они построены: в эпоху агентов основы разработки важнее, чем раньше. Непонимание задачи, жаргон, отсутствие обратной связи и расползающаяся архитектура — старые болезни. Агенты их не лечат, а ускоряют. Три вещи стоит унести, даже если ничего не устанавливать: 1. **Сначала договориться, потом писать.** Допрос раундами с рекомендуемыми ответами отсекает большую часть «сделал не то». 2. **Общий словарь проекта.** Одно слово вместо двадцати экономит и токены, и путаницу в каждой сессии. 3. **Проверять по двум осям отдельно.** «Сделано по правилам» и «сделано то, что просили» — разные вопросы. **Следующий шаг:** возьмите задачу, которую собирались отдать агенту на этой неделе, и перед тем как просить код, прогоните её через промпт-допрос выше. Посчитайте, сколько решений вы собирались оставить агенту на угадывание. ## Читайте также
как Claude Code раздаёт работу субагентам и собирает результат обратно такой же набор скиллов, только для маркетинга: SEO, CRO, тексты и аналитика 33 навыка и один файл-начальник, который распределяет между ними задачи
Хотите выстроить такой процесс работы с агентом под свой проект — [напишите мне в Telegram](https://t.me/uspeshnyy).