Matt Pocock Skills: как превратить AI-агента из генератора кода в инженера

Знакомый сценарий. Пишете агенту «сделай мне фичу» — через минуту получаете 800 строк. Код собирается, выглядит солидно и делает не совсем то, что вы имели в виду. Дальше полдня уходит на объяснения, что именно было «не то».

Дело не в модели. Между вами и агентом тот же разрыв, что между заказчиком и разработчиком: вы уверены, что всё объяснили, а он додумал остальное сам.

Мэтт Покок — преподаватель TypeScript, автор Total TypeScript и AI Hero — собрал репозиторий skills как раз вокруг этого разрыва. Это не очередная папка с промптами, а набор небольших инструкций, которые ведут агента по инженерному процессу: понять задачу, записать её, разбить на части и только потом писать код.

Что это за репозиторий

Описание на 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 построен не вокруг списка скиллов, а вокруг поломок — ситуаций, в которых агент подводит. На каждую есть своё лекарство.

1. Агент сделал не то, что вы хотели

Лечится допросом. Скилл grilling и две обёртки над ним — /grill-me и /grill-with-docs — заставляют агента интервьюировать вас, пока не останется ни одного решения, принятого молча. Автор называет их самыми популярными в репозитории и советует запускать перед каждым изменением.

Устроено это аккуратнее, чем «задай мне вопросы»:

• Решения складываются в дерево. Каждое тянет за собой решения, которые от него зависят.
• Вопросы идут раундами. В раунд попадает всё, на что можно ответить прямо сейчас, не угадывая ответы на ещё открытые вопросы.
• К каждому вопросу — рекомендуемый ответ. Вам остаётся согласиться или поправить.
• Факты агент ищет сам. Если для вопроса нужно заглянуть в файлы, он отправляет субагента, а не спрашивает вас. Решения остаются за вами.
• Допрос кончается, когда дерево пройдено целиком. И даже тогда агент ничего не делает, пока вы не подтвердите, что договорились.

flowchart LR
    A["План<br/>или идея"] --> B["Дерево<br/>решений"]
    B --> C["Раунд: вопросы,<br/>на которые можно<br/>ответить сейчас"]
    C --> D["Ваши ответы"]
    D --> E{"Остались<br/>открытые решения?"}
    E -->|да| C
    E -->|нет| F["Подтверждение:<br/>договорились"]

Разница с обычным «уточни детали» — в последнем пункте. Агент не останавливается на трёх вопросах для приличия: он идёт по дереву, пока неизвестных не останется. Это тот же приём, что и поиск «неизвестных» при работе с Claude, только оформленный в процедуру.

2. Агент говорит двадцать слов там, где хватит одного

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

Лекарство взято из предметно-ориентированного проектирования Эрика Эванса — общий язык проекта. В репозитории это файл CONTEXT.md, глоссарий терминов. Пример из README. Было: «проблема возникает, когда урок внутри раздела курса становится "настоящим", то есть получает место в файловой системе». Стало: «проблема с каскадом материализации».

Сам репозиторий ведёт такой словарь для себя. Фрагмент его CONTEXT.md:

**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, 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.

Главный маршрут: от идеи до коммита

Скиллы задуманы как детали, но складываются в маршрут. Его описывает отдельный скилл-навигатор /ask-matt: ему можно описать ситуацию и спросить, с чего начать.

flowchart TD
    A["Идея"] --> B["/grill-with-docs<br/>допрос и словарь"]
    B --> C{"Всё решается<br/>в разговоре?"}
    C -->|"нет, надо пощупать"| P["/handoff → /prototype<br/>→ /handoff с выводами"]
    P --> B
    C -->|да| D{"Работы больше<br/>чем на одну сессию?"}
    D -->|да| E["/to-spec<br/>спецификация"]
    E --> F["/to-tickets<br/>задачи с блокерами"]
    F --> G["/implement<br/>по одной задаче"]
    D -->|нет| G
    G --> H["tdd<br/>красный → зелёный"]
    H --> I["code-review<br/>стандарты и спека"]
    I --> J["Коммит"]

1. /grill-with-docs — допрос. Если вопрос не решить на словах — нужно увидеть логику, состояние или интерфейс, — маршрут делает крюк: /handoff переносит разговор в отдельную сессию, /prototype отвечает на вопрос одноразовым кодом, второй /handoff возвращает выводы.

2. /to-spec — превращает разговор в спецификацию. Второго допроса не устраивает: собирает то, что уже обсуждено, и сверяет с вами только швы для тестов. В шаблоне — проблема глазами пользователя, решение, длинный список пользовательских историй, решения по реализации и тестам, что вне рамок. Путей к файлам и кусков кода в спецификации быть не должно: они устаревают быстрее, чем решения.

3. /to-tickets — режет спецификацию на задачи-«трассирующие пули». Каждая проходит тонким, но полным срезом через все слои — схему данных, API, интерфейс, тесты — и проверяется сама по себе. У каждой указаны блокеры: какие задачи должны закончиться раньше. Задачу без блокеров можно брать сразу. Прежде чем публиковать, агент спрашивает вас, не слишком ли мелко или крупно нарезано.

4. /implement — по одной задаче. Внутри гоняет tdd, регулярно проверяет типы, в конце прогоняет весь набор тестов и code-review, потом коммитит.

Небольшую задачу маршрут пропускает через укороченную ветку: без спецификации и нарезки, /implement сразу в том же окне.

Гигиена контекста

Эта часть мне кажется самой полезной, потому что применима к любой работе с агентом:

• Допрос, спецификация и нарезка — в одном непрерывном окне. Без сжатия и очистки: все три шага строятся на одном и том же мышлении.
• Каждый /implement — с чистого листа. Между задачами — /clear. Задача самодостаточна, контекст предыдущей не нужен.
• Следите за «умной зоной». Автор оценивает её примерно в 150 тысяч токенов у современных моделей: в этих пределах модель ещё рассуждает чётко. Если окно подходит к пределу раньше нарезки — сжимайте на ближайшей границе этапа, а не тяните дальше на деградировавшем контексте. Подробнее о том, почему контекст портится раньше, чем кажется.

У маршрута есть два входа сбоку. /triage разбирает входящие баг-репорты и запросы, которые создали не вы, и превращает их в задачи, готовые для агента. /wayfinder — для огромных туманных проектов, которые не помещаются в одну сессию: чертит карту задач-решений и закрывает их по одной, пока путь не прояснится. Автор называет его самым тяжёлым потоком и советует не тратить на хорошо очерченные фичи.

Ревью по двум осям

Если забирать из репозитория что-то одно, я бы начал с code-review. Он проверяет изменения с фиксированной точки — коммита, ветки, тега — по двум независимым осям.

• Стандарты. Соответствует ли код правилам репозитория и базовому набору «запахов» Мартина Фаулера: загадочные имена, дублирование, функция, которая больше работает с чужими данными, чем со своими, правка, разбросанная по десятку файлов. Правило репозитория всегда главнее базового набора, а каждый запах — повод присмотреться, а не приговор.
• Спецификация. Делает ли код то, что просили: чего не хватает, что добавлено сверх заказа, что реализовано, но похоже на ошибку. Каждое замечание — с цитатой из спецификации.

flowchart LR
    D["Изменения<br/>с фиксированной точки"] --> S["Субагент<br/>«Стандарты»"]
    D --> P["Субагент<br/>«Спецификация»"]
    S --> R["Два отчёта рядом,<br/>без общего рейтинга"]
    P --> R

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

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

Что забрать, даже если вы не пишете код

Половина идей работает за пределами программирования — автор сам вынес их в группу Productivity.

• /grill-me — тот же допрос, но без репозитория и без записи файлов. Подходит для плана запуска, структуры лендинга, коммерческого предложения.
• /to-questionnaire — когда ответ знает не вы, а другой человек: клиент, юрист, подрядчик. Скилл расспрашивает вас не о теме, а об отправке — кому, что нужно получить назад — и собирает анкету в Markdown.
• /wait-what — на случай, когда ответ агента не дошёл. Он пересказывает простым языком, добавляя недостающий контекст и слова из словаря проекта.
• /handoff — сжимает разговор в документ для следующей сессии или коллеги. Со списком рекомендуемых скиллов, со ссылками вместо копий того, что уже записано, и с вырезанными ключами и паролями.
• /teach — учит новой теме за несколько сессий и хранит прогресс в папке.

Ниже — промпт по мотивам grilling для любой задачи. Это не перевод скилла, а его принцип, который работает в обычном чате:

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

Правила:
1. Разложи план на дерево решений: каждое решение тянет за собой те,
   что от него зависят.
2. Задавай вопросы раундами. В раунд попадают только вопросы, на которые
   можно ответить сейчас, не зная ответов на ещё открытые.
3. Нумеруй вопросы и к каждому сразу пиши свой рекомендуемый ответ.
4. Всё, что можно узнать из приложенных материалов, выясняй сам,
   не спрашивай меня. Решения оставляй мне.
5. После моих ответов пересобери дерево и задай следующий раунд.
6. Закончи, когда открытых решений не останется. Ничего не делай,
   пока я не подтвержу, что мы договорились.

План: <опишите задачу>

Как установить

Путей два, и за ними две философии. Ставить оба не нужно — получите каждый скилл дважды. Если сам формат скиллов для вас в новинку, начните с разбора что такое скиллы AI-агента и чем они отличаются от MCP и CLAUDE.md.

Claude Code — плагином. Он есть в официальном маркетплейсе и обновляется сам, когда автор выпускает изменения. Вы подписываетесь на набор, а не копируете его:

claude plugins install mattpocock-skills

Codex и другие агенты — копией файлов. Скиллы ложатся в проект обычными файлами, которые можно править. Этот путь подходит и для Claude Code, если хотите переделывать скиллы под себя. Обновления — вручную, командой npx skills update. Нативного плагина для Codex пока нет, он в планах.

npx skills@latest add mattpocock/skills

Дальше — один раз на каждый репозиторий: /setup-matt-pocock-skills. Он спросит, где вести задачи — GitHub, Linear или локальные файлы, — какими метками размечать входящие и куда складывать документы. При установке через npx отметьте этот скилл в списке: без него инженерные скиллы не знают, куда писать.

Если вы ещё не работали в терминальном агенте, начните с разбора Claude Code для нетехнарей.

Честно о границах

• Это процесс, и он медленнее. Допрос по дереву решений занимает время. Для правки в три строки он не нужен, и сам маршрут это учитывает.
• Нужен трекер задач. Инженерная часть рассчитана на то, что спецификации и задачи где-то живут. Хватит и локальных файлов, но настроить придётся.
• Тесты — ваша инфраструктура. tdd и diagnosing-bugs сильны ровно настолько, насколько быстро проект позволяет прогнать тест. Где тестов нет, начинать придётся с них.
• Скиллы на английском. Агенту это не мешает, человеку при чтении и правке — возможно.
• Это не спасение. Автор пишет так про обзор архитектуры, но относится это ко всему набору: запутанный проект скиллы не распутают, они дают дисциплину на будущее.

Вывод

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

Три вещи стоит унести, даже если ничего не устанавливать:

1. Сначала договориться, потом писать. Допрос раундами с рекомендуемыми ответами отсекает большую часть «сделал не то».
2. Общий словарь проекта. Одно слово вместо двадцати экономит и токены, и путаницу в каждой сессии.
3. Проверять по двум осям отдельно. «Сделано по правилам» и «сделано то, что просили» — разные вопросы.

Следующий шаг: возьмите задачу, которую собирались отдать агенту на этой неделе, и перед тем как просить код, прогоните её через промпт-допрос выше. Посчитайте, сколько решений вы собирались оставить агенту на угадывание.

Исходники на GitHubmattpocock/skills

Читайте также

Хотите выстроить такой процесс работы с агентом под свой проект — напишите мне в Telegram.