mattpocock/skills: разбор всех скиллов — как они устроены и зачем они нужны

Привет, друзья! Сегодня у меня для вас разбор, который я делала несколько дней. Репозиторий mattpocock/skills на GitHub — это 276 617 звёзд, 23 180 форков и одна из самых обсуждаемых коллекций скиллов для кодинг-агентов. Автор — Мэтт Покок, известный по TypeScript-туториалам и курсам по Total TypeScript. По сути это его «.agents» каталог, вытащенный наружу и упакованный так, чтобы им мог пользоваться любой.

Внутри — 24 скилла, разделение на user-invoked и model-invoked, отдельная настройка под каждый репозиторий, и ссылки на полки с классикой вроде The Pragmatic Programmer и Domain-Driven Design. Под капотом — десятилетия инженерного опыта, упакованные в маленькие, хакабельные Markdown-файлы. Разбираю всё, что нашла: архитектуру, формат SKILL.md, что внутри каждого скилла, где это применять и какие грабли собрать по дороге.

Зачем вообще нужны скиллы

Мэтт открывает с цитаты из «Прагматичного программиста»: «Никто точно не знает, чего хочет». И дальше разворачивает четыре ключевые проблемы, с которыми сталкивается любой, кто работает с coding agent — Claude Code, Codex или чем-то ещё:

1. Агент сделал не то, что я хотел. Это проблема выравнивания. Самый частый сбой в разработке — и с людьми, и с ИИ. Решение — «сессия прожарки»: агент задаёт вам подробные вопросы, пока вы вместе не выстроите общее понимание задачи. Для этого есть /grill-me (общая версия) и /grill-with-docs (инженерная, дополнительно строит модель предметной области и пишет ADR — про них подробно расскажу ниже).

2. Агент слишком многословен. В начале проекта разработчики и домен-эксперты говорят на разных языках. Агент вынужден разбирать жаргон на ходу и тратит по 20 слов там, где хватит одного. Решение — общий язык: документ, который помогает агенту понимать терминологию проекта. В одном из примеров: до прожарки разработчик пишет «есть проблема, когда урок внутри секции курса становится 'реальным' (то есть получает место в файловой системе)», а после — просто «проблема с каскадом материализации». Коротко, понятно, экономит токены сессия за сессией.

3. Код не работает. Допустим, вы выровнялись. Что если агент всё равно выдаёт мусор? Смотрим на петли обратной связи. Без обратной связи о том, как код запускается, агент летит вслепую. Нужны статические типы, доступ к браузеру, автотесты. И — ключевая вещь — цикл «красный → зелёный → рефакторинг» (сначала падающий тест, потом код, потом чистка). Для этого есть /tdd и /diagnosing-bugs.

4. Кодовая база превратилась в шар из грязи. Агенты радикально ускоряют написание кода — но и ускоряют энтропию кодовой базы. Решение — встроенный фокус на дизайн. Это пропитано во всём: /to-spec расспрашивает, какие модули вы трогаете, прежде чем писать спецификацию. /improve-codebase-architecture сканирует кодовую базу на «углубление» модулей — то есть ищет места, где модуль можно сделать глубже: больше поведения за тем же простым интерфейсом. Концепция из книги «A Philosophy of Software Design» Джона Оустерхаута. Рекомендуется запускать раз в несколько дней.

Эти четыре проблемы — каркас всего репо. Под каждую — свои скиллы.

Две философии установки

Установить можно двумя способами, и они несовместимы — выбирайте один, иначе получите каждый скилл дважды.

Claude Code plugin — ставит весь набор как управляемый пакет «только для чтения». Когда Мэтт выпускает обновления, они приходят к вам автоматически. Вы подписываетесь, а не форкаете. Это для тех, кто хочет «работает и не трогай».

npx skills@latest add mattpocock/skills — копирует файлы SKILL.md в ваш проект, чтобы вы могли их менять. Это для тех, кто хочет «сделать по-своему».

После установки в корне репозитория один раз запускается /setup-matt-pocock-skills. Этот скилл задаст три вопроса: где у вас живут задачи (GitHub, GitLab или локальные файлы — это называется «баг-трекер» или «трекер задач»); какие ярлыки-метки у вас для триажа (это использует /triage); и где хранить доменную документацию (GLOSSARY.md и ADR'ы — ниже объясню подробно). Без setup'а большинство инженерных скиллов работают криво: они читают настройки, которые пишет именно setup.

Архитектура: user-invoked vs model-invoked

Это, по-моему, ключевая идея репо. Все скиллы делятся на два типа по одному критерию: кто их может вызвать.

User-invoked — срабатывают, только когда вы вводите /имя в чате. Их работа — оркестрировать. Например, /grill-me или /implement.

Model-invoked — доступны и вам, и агенту автоматически, когда задача подходит. В них живёт переиспользуемая дисциплина. Например, /tdd или /grilling (примитив «прожарки», на котором построен /grill-me).

User-invoked может вызывать model-invoked, но не наоборот. Эта асимметрия — фундамент, на котором держится композиция.

Инженерные скиллы — полный разбор

Всего 17 инженерных скиллов. Делю по группам: ежедневные, для спецификации и работы с задачами, для архитектуры, для отладки, для исследований, для процесса.

User-invoked, для оркестрации

/setup-matt-pocock-skills — точка входа. Один раз на репозиторий. Сканирует репозиторий, узнаёт, какие агенты уже стоят, настраивает трекер задач, метки для триажа, путь к глоссарию и к ADR'ам. Без него ничего не работает как надо.

/ask-matt — роутер. Если не знаете, какой скилл вызвать, скажите ему «что мне делать» — он подскажет. Это, по сути, документация в форме живого помощника.

/grill-with-docs — главный скилл для старта. Инженерная версия «прожарки», которая вместе с интервью строит модель предметной области проекта: обновляет GLOSSARY.md, пишет ADR для важных решений. Сам автор называет её «магической» частью репо. Я бы начинала любой новый проект именно с этого скилла.

/triage — сортировщик входящих задач. Работает как конечный автомат, который двигает задачи в трекере по заранее определённым состояниям. У каждой задачи есть два «тега»: категория — bug (что-то сломано) или enhancement (новая фича или улучшение); и состояние — needs-triage (нужна оценка), needs-info (ждём ответа от автора задачи), ready-for-agent (задача описана достаточно, чтобы агент мог её взять), ready-for-human (нужен человек, например, для дизайн-решений) или wontfix (делать не будем). Pull request — это по сути та же задача, только с готовым кодом; для неё состояния читаются похоже — ready-for-agent значит «к брифу прикреплён код, агент может брать в работу». Каждая задача должна иметь ровно один тег категории и один тег состояния. Если состояния конфликтуют, скилл остановится и попросит подтверждения у мейнтейнера.

Запускается просто: мейнтейнер пишет /triage и описывает, что хочет — обычным языком. Например: «покажи всё, что требует моего внимания» или «давай посмотрим на #42» или «переведи #42 в ready-for-agent». Скилл сам интерпретирует запрос и действует.

Важная деталь: каждый комментарий, который скилл пишет в трекер, начинается с пометки «Сгенерировано ИИ во время триажа» — прозрачность прежде всего. Никто не перепутает автоматический комментарий с человеческим.

/to-spec — превращает текущий разговор в спецификацию и публикует её в трекере задач с меткой ready-for-agent. Никакого интервью — синтез того, что вы уже обсудили. Использует готовый шаблон из четырёх разделов: «В чём проблема» → «Как решаем» → «Пользовательские истории» (большой нумерованный список) → «Принятые технические решения».

/to-tickets — бьёт спецификацию или план на отдельные «трассирующие» тикеты. Это маленькие задачи, каждая из которых проверяет конкретный кусок системы от начала до конца (не отдельный слой, а тонкий вертикальный срез). Каждый такой тикет явно объявляет, от каких других тикетов зависит — без них он не начнётся. Зависимости можно хранить либо в локальных файлах-черновиках, либо как нативные «ссылки-блокировки» прямо в реальном трекере (например, GitHub умеет блокировать одну задачу другой через специальный синтаксис в описании).

/implement — реализует работу из спецификации или набора тикетов. Подключает /tdd на заранее согласованных «швах» (то есть границах между модулями, через которые мы наблюдаем поведение — например, публичные методы класса), регулярно запускает проверку типов и одиночные тесты, в конце делает полный прогон и /code-review. Готовый результат коммитит в текущую ветку.

/implement-spec — расширенная версия. Реализует целую спецификацию на одной интеграционной ветке, запускает несколько подагентов-исполнителей параллельно по готовым задачам, в конце — /code-review. Для больших фич.

/wayfinder — для огромных кусков работы, которые один агент не вытянет за сессию. Скилл планирует их как общую карту задач-решений в трекере, и решает их по одной, пока путь к цели не станет ясен. По сути — «разведка маршрута» перед большим переходом.

/improve-codebase-architecture — сканирует репозиторий на «точки углубления» (модули, которые можно углубить — больше поведения за тем же интерфейсом). Генерирует визуальный HTML-репорт, потом «прожаривает» вас по выбранному кандидату. Это обзор, а не спасение: на по-настоящему старой кодовой базе найдёт кандидатов, но разгребать грязь придётся вам.

/retro — после сессии. Предлагает улучшения среды агента: навигация, авто-проверки, правила оформления кода, steering-файлы (то есть Markdown-инструкции, которые лежат в корне репозитория и направляют агента), инструменты. Сортирует по серьёзности. Это «ретроспектива» после работы с агентом.

/pr — форма, которую должен принять body pull request'а: краткое описание, что именно поменялось и зачем; доказательства, что до изменений было плохо, а после — хорошо (скриншоты, логи, метрики); оценка риска слияния — можно откатить без последствий («one-way door») или нет («two-way door»), плюс масштаб последствий, если что-то пойдёт не так.

/wizard — генерирует интерактивный bash-визард для шагов, которые может выполнить только человек: создание инфраструктуры в облаке, ввод учётных данных или CI-секретов, прохождение незнакомого дашборда, разовые миграции или переключение трафика.

Model-invoked, для дисциплины

/tdd — разработка через тестирование, цикл «красный → зелёный → рефакторинг». Главное правило: «сначала красный». Сначала пишется падающий тест, потом только минимальный код, чтобы он прошёл. Никакого угадывания будущих тестов и добавления «на всякий случай». Тесты проверяют поведение через публичные интерфейсы, а не через детали реализации (то есть не через приватные методы или моки внутренних компонентов). Если тест ломается при рефакторинге, хотя само поведение системы не менялось — это плохой тест, он завязан на реализацию, а не на контракт. Тесты живут на «швах» — заранее согласованных публичных границах между модулями. До написания теста швы должны быть подтверждены с пользователем: нельзя просто взять и начать тестировать, надо сначала договориться, через какие именно границы мы наблюдаем поведение. Если форма самой границы вызывает вопросы (насколько модуль «глубок», где проходит шов, что именно должен выставлять наружу интерфейс), скилл подключает codebase-design за общим словарём: «модуль», «интерфейс», «глубина», «шов», «адаптер», «рычаг» и «локальность» — это всё термины из той же книги Джона Оустерхаута. Главные анти-паттерны, которые скилл ловит и блокирует: тесты, завязанные на реализацию; тавтологические тесты (которые «правы по построению» — например, проверяют, что функция сложения вернула сумму, посчитанную тем же способом); и горизонтальное нарезание (все тесты сразу, потом вся реализация — это проверяет «форму» кода, а не поведение). Правильный путь — вертикальные срезы: один тест, одна минимальная реализация, повторить. Каждый срез — трассирующая пуля, которая показывает, что система работает на этом куске.

/diagnosing-bugs — дисциплинированный цикл для сложных багов и регрессий по производительности: построить петлю обратной связи, которая падает на этом баге → минимизировать воспроизведение → сформулировать гипотезу → добавить логи и диагностику → починить → добавить регрессионный тест. Каждая фаза закрывается перед переходом к следующей.

/research — исследует вопрос по надёжным первоисточникам и сохраняет находки как Markdown-файл с цитатами в репозиторий. Запускается как фоновый агент.

/prototype — одноразовый код, который отвечает на вопрос. Две ветки: логика (один HTML-файл с кнопками и пошаговыми сценариями, прогоняющий автомат состояний через сложные случаи) и интерфейс (несколько радикально разных визуальных вариаций на одном маршруте, переключаемых через параметр в адресе). Без сохранения состояния по умолчанию, без тестов, без полировки. Цель — быстро чему-то научиться, а не сделать готовый продукт.

/domain-modeling — активное построение и заточка модели предметной области проекта: проверка терминов против глоссария, стресс-тест краевых сценариев, обновление GLOSSARY.md и ADR на лету.

/codebase-design — общая дисциплина и словарь для проектирования глубоких модулей: много поведения за маленьким интерфейсом, размещённым на чистом шве, тестируемым через этот интерфейс.

/code-review — ревью изменений в коде по двум осям: стандарты (соответствует ли репозиторий принятым правилам оформления + базовые «запахи кода» по Фаулеру) и спецификация (точно ли реализует то, что просили в задаче или спецификации). Запускается как параллельные подагенты, чтобы ни один не загрязнял оценку другого.

Скиллы продуктивности — для общения и работы

Вторая большая группа — скиллы не про код, а про то, как вы работаете с агентом вообще.

/grill-me — вызывается пользователем. Запускает «прожарку» по плану или дизайну. Это просто тонкая обёртка над примитивом /grilling, который «прожаривает» вас до тех пор, пока каждая ветка дерева решений не будет закрыта. Примитив работает в «раундах»: на каждом раунде вычисляется фронт — все вопросы, чьи предварительные условия уже решены, — и вы получаете их списком с нумерацией и рекомендованными ответами. Вы отвечаете — фронт пересчитывается. Сессия заканчивается, когда фронт пуст. Факты ищет сам агент (через подагентов, которые копаются в окружении), решения — ваши.

/wait-what — остановись, последнее сообщение не зашло, перескажи. Говорит по упрощённому техническому английскому (стандарт ASD-STE100), использует общую лексику из GLOSSARY.md. Если в репо несколько глоссариев — смотрит GLOSSARY-MAP.md, чтобы выбрать правильный.

/handoff — сворачивает текущий разговор в handoff-документ (документ «передачи дел») для следующего агента. Сохраняет во временную папку операционной системы, не в рабочее пространство проекта. Включает секцию «suggested skills» — какие скиллы следующий агент должен вызвать. Не дублирует контент, который уже зафиксирован в спецификациях, планах, ADR'ах, задачах и коммитах, ссылается на них по пути или по ссылке. Перед сохранением вырезает чувствительное: API-ключи, пароли, персональные данные (PII — personally identifiable information).

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

/to-questionnaire — превращает решение, которое вы не можете принять в одиночку, в Markdown-анкету для того, кто может. Анкету можно заполнить асинхронно или вместе на встрече. Важный нюанс: скилл «прожаривает» вас про саму отправку (кому уйдёт анкета, в каком виде, что вы хотите получить обратно), а не про тему анкеты. Если отправить некому или неясно, чего вы хотите на выходе, скилл не даст перейти к самой анкете.

/writing-for-agents — model-invoked, 10 886 символов, самый длинный из productivity-скиллов. Про то, как писать документы для агентов: скиллы, AGENTS.md/CLAUDE.md и любые другие документы, на которые агент ссылается. Это инструкция по стилю для самой системы скиллов — то, как Мэтт пишет сами SKILL.md.

Дополнительные ресурсы в репо

Помимо скиллов, в репо есть важные структурные элементы.

Глоссарий (GLOSSARY.md) — общий язык проекта. Это словарь терминов вашей предметной области, в котором каждому понятию даётся короткое определение, понятное и человеку, и агенту. Строится и обновляется через /grill-with-docs прямо во время сессии прожарки: когда выясняется, что какое-то слово в проекте означает конкретную вещь, скилл дописывает его в глоссарий. Если в репозитории несколько глоссариев (например, для разных подсистем), есть GLOSSARY-MAP.md — карта, которая указывает, какой глоссарий применять в каком контексте. Это не манифест и не «документ для галочки», а рабочий инструмент, на который ссылается большинство скиллов и который экономит токены при каждом вызове. Старое название того же файла — CONTEXT.md, у некоторых старых репозиториев Мэтта (например, course-video-manager) оно до сих пор используется.

ADR (Architecture Decision Records) — записи об архитектурных решениях. Это короткие Markdown-файлы, лежат в docs/adr/. Каждый ADR фиксирует одно важное архитектурное решение: что мы выбрали, какие альтернативы рассматривали, почему именно это и какие последствия. Формат простой: номер по порядку, дата, заголовок с глаголом («Выбираем PostgreSQL для хранения», а не «PostgreSQL»). Внутри — разделы «Контекст» (какую проблему решаем), «Решение» (что именно делаем), «Последствия» (что становится лучше и что хуже), иногда «Рассмотренные альтернативы». Полный шаблон лежит в файле ADR-FORMAT.md.

Зачем это нужно, если у нас есть Git и коммиты? Потому что в комментариях к коммиту решение теряется среди других изменений, а в коде — вообще не проговаривается. ADR — это явный след: «вот тогда-то мы выбрали именно так, потому что так». Через полгода, когда кто-то спросит «а почему у нас монолит, а не микросервисы?» — открываешь docs/adr/0007-monolith.md и читаешь. Без ADR эта информация просто исчезает вместе с уволившимися сотрудниками.

В репозитории Мэтта ADR создаются и обновляются автоматически: скилл /grill-with-docs дописывает их во время прожарки, когда вы принимаете важное решение, а /improve-codebase-architecture ссылается на них, чтобы не пересматривать одни и те же вопросы заново. То есть это не «формальность для аудиторов», а живая часть рабочего процесса.

AGENTS.md и CLAUDE.md — находятся в корне репозитория. Это steering-файлы: Markdown-инструкции, которые агент читает в самом начале сессии, прежде чем браться за любую задачу. Сюда пишут то, что важно именно для вашего проекта: «не трогай папку legacy/ без согласования», «перед коммитом всегда запускай pnpm lint», «в этом проекте мы используем ESM, а не CommonJS». Скилл setup'а проверяет, существуют ли эти файлы, и либо создаёт их, либо оставляет как есть.

Per-skill вспомогательные файлы (sibling-файлы). У некоторых скиллов в той же директории лежат дополнительные Markdown-файлы — сиблинги (то есть «братья-сёстры» основного файла). На них ссылается сам SKILL.md через относительный путь. Это «подсказки на подумать» — отдельные инструкции, которые агент подгружает по ходу работы. Например, у /grill-with-docs рядом лежат ADR-FORMAT.md (подробный шаблон для ADR) и CONTEXT-FORMAT.md (шаблон для глоссария). У /improve-codebase-architecture — DEEPENING.md, INTERFACE-DESIGN.md, LANGUAGE.md (три отдельных файла с деталями по каждому аспекту углубления модулей). У /tdd — deep-modules.md, interface-design.md, mocking.md, refactoring.md, tests.md (пять файлов с конкретными примерами и анти-паттернами). У /prototype — LOGIC.md и UI.md (подробные инструкции для каждой из двух веток прототипирования). У /setup-matt-pocock-skills — шаблоны для GitHub, GitLab, локального режима, для меток триажа, и domain.md (правила для глоссария). Эти файлы — рабочие лошадки, не удаляйте их при копировании, иначе скилл будет молча игнорировать подсказки.

Журнал изменений (CHANGELOG.md) — у Мэтта очень активный. Несколько скиллов уже в папке deprecated/ (то есть официально устаревших — ubiquitous-language, qa, request-refactor-plan, design-an-interface): их функциональность поглощена /grill-with-docs и /improve-codebase-architecture. Если у вас остались старые символьные ссылки (symlinks — особый тип файлов в системе, который указывает на другой файл) на эти скиллы, обновлений они больше не получают.

Формат скилла: что внутри SKILL.md

SKILL.md — это Markdown с YAML frontmatter. Стандартный набор полей:

name — имя скилла (становится слеш-командой).
description — однострочное или многострочное описание. Для model-invoked скиллов описание критично: агент решает по нему, нужен ли скилл для текущей задачи.
disable-model-invocation — если true, скилл может вызвать только пользователь (user-invoked).

argument-hint — подсказка, какие аргументы скилл ожидает (например, у /handoff это «Для чего будет использоваться следующая сессия?»).

Тело SKILL.md — это буквально инструкция агенту. Никакого API, никакого отдельного движка, который надо запускать. Просто Markdown-промпт. Хотите изменить поведение скилла, открывайте SKILL.md и переписывайте формулировки. В этом и прелесть: всё хакается на раз.

Типичные грабли

Когда я готовила этот разбор, я нашла несколько мест, где чаще всего спотыкаются. Вот они.

Запускают инженерные скиллы до setup'а. /triage, /to-issues, /to-prd, /diagnose, /tdd, /improve-codebase-architecture, /zoom-out читают настройки, которые пишет /setup-matt-pocock-skills. Без setup'а они выдают generic (то есть шаблонный, не учитывающий ваш проект) или сломанный вывод. Документация по этому поводу — отдельный ADR 0001-explicit-setup-pointer-only-for-hard-dependencies.md.

Удаляют или перемещают SKILL.md, оставляя sibling-файлы. grill-with-docs и improve-codebase-architecture ссылаются на ADR-FORMAT.md, DEEPENING.md и другие файлы по относительному пути. Если перенести только SKILL.md, ссылки ломаются молча — агент не упадёт с ошибкой, просто проигнорирует подсказки.

Путают /grill-me с /grilling. /grill-me — user-invoked обёртка для не-кодовых задач. /grilling — model-invoked примитив, который вызывают другие скиллы. Если вы хотите «прожариться» по дизайну кода, используйте /grill-with-docs, не /grill-me.

Принимают /prototype как production. Скилл явно говорит, что код — одноразовый, и в подсказках прямо написано «не пишите production-ready код». Использовать /prototype и потом шипнуть его в прод — анти-паттерн, который скилл спроектирован предотвратить.

CONTEXT.md устаревает. Общий язык остаётся точным только если вы запускаете /grill-with-docs при введении новых концепций. Устаревший CONTEXT.md дезориентирует агента в терминологии.

Ставят оба варианта установки. Claude Code plugin + skills.sh одновременно = каждый скилл дважды, конфликты конфигов. В описании прямо сказано: «выберите один».

Где это стоит применять

По-моему, mattpocock/skills особенно хорошо ложится на проекты, где:

— Вы работаете в команде, где у каждого своё понимание домена. /grill-with-docs реально экономит токены и убирает неоднозначность.
— Кодовая база большая, и «грязь» уже накапливается. /improve-codebase-architecture + /codebase-design дают язык и процесс для постепенной чистки.
— У вас зрелый процесс работы с задачами, и вы хотите, чтобы агент его уважал, а не выдумывал свой. /triage + /setup-matt-pocock-skills — пара для этого.
— Вы пишете тесты, но не всегда знаете, какие именно писать. /tdd дисциплинирует и учит отличать тест на поведение от теста на реализацию.

Если вы работаете в одиночку над маленьким проектом — большая часть этих скиллов будет избыточна. Начните с /grill-me и /wait-what, и постепенно добавляйте остальные по мере роста задач.

Чем это отличается от GSD, BMAD и Spec-Kit

В описании репозитория Мэтт прямо пишет: подходы вроде GSD, BMAD и Spec-Kit пытаются помочь, отбирая у вас контроль над процессом. Но если в самом процессе ошибка — разрулить её потом почти невозможно. Его скиллы — маленькие, адаптивные, легко комбинируются между собой. Работают с любой моделью. Основаны на десятилетиях инженерного опыта. Хакните их под себя, сделайте своими.

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

Что делать нам

Если вы ещё не пробовали — возьмите /grill-me на текущей задаче. Серьёзно. Просто наберите его в Claude Code или Codex и посмотрите, как агент начнёт задавать вам вопросы. С этого проще всего начать.

Если вы работаете в команде — договоритесь хотя бы про /setup-matt-pocock-skills и один общий регламент триажа. Остальные скиллы лягут сверху естественно.

Если вы пишете свои агенты — посмотрите на /writing-for-agents. Это инструкция, как писать сами SKILL.md: на что ставить описание, как формулировать инструкции, что выносить в sibling-файлы. Пригодится, когда будете делать свои скиллы.

Я ставлю на то, что к концу года у каждой крупной команды, работающей с coding agent, будет свой «.agents» каталог по мотивам этого репо. mattpocock/skills задал планку, и возвращаться к «вайбкодингу без дисциплины» после неё уже не хочется.

С вами была я, Ками. Пока-пока!

Источники: репозиторий mattpocock/skills (276 617 звёзд, MIT-лицензия), описание проекта, все SKILL.md, GitHub API (метаданные репо).