Набір навичок Метта Поукока: процес «розбір, специфікація, тикети, реалізація, рев’ю»

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, і саме вона тримається, коли магазин уже працює, а код успадковує інший інженер.