Каждый новый проект у меня начинался с копирования скиллов из соседнего. Через несколько месяцев в тринадцати репозиториях лежали тринадцать версий одного и того же, разошедшихся по мелочам.
Прежде чем это чинить, я решил посмотреть, что вообще совпадает. Посчитал вхождения по всем .ai/skills/ и получил картинку, которая меня удивила своей резкостью.
Что показал подсчёт
13 из 13 visual-qa, repo-discovery, frontend-design, developer,
code-review, a11y-check
12 из 13 seo-structured-data, legal-pages
11 из 13 seed-content, filament-resource
8 из 13 generate-image, ecosystem-map
5 из 13 ckeditor-shared-sync
4 из 13 publish-workflow
1 из 13 hosting-providers, solution-catalog, photo-pipeline,
note-content-styles, module-architecture, translations,
sql-migrations, archive-content, profile-content и ещё несколькоРаспределение не плавное, а ступенчатое. Есть шесть скиллов, которые есть везде. Есть длинный хвост из единичных. Между ними — почти ничего.
Промежуточная группа объясняется стеком: filament-resource и seed-content стоят в одиннадцати проектах на Laravel и отсутствуют в двух на Symfony. Это не ядро, это признак фреймворка.
Шестёрка
Скиллы, которые есть во всех тринадцати репозиториях:
developer — повседневные стандарты бэкенда. Порядок чтения задачи, где живёт логика, за какими побочными эффектами следить.
code-review — порядок ревью патча и чеклист.
repo-discovery — построение карты до правок: маршрут, контроллер, сервис, модель, побочные эффекты, шаблон.
visual-qa — визуальная проверка после изменений вёрстки: темы, ширины, переполнение, кроп.
a11y-check — доступность: клавиатура, фокус, метки форм, заголовки, контраст.
frontend-design — правки интерфейса в рамках визуального языка проекта, без generic-эстетики.
Общее у всех шести: они про способ работы, а не про предметную область. Ни один не знает, чем занимается продукт. Блог, каталог хостингов, трекер задач, фотоархив — процедура ревью в них одинаковая, потому что она про то, как я смотрю на код, а не про то, что этот код делает.
Проверяется просто. Если из скилла убрать все упоминания стека и продукта и он всё ещё осмысленный — это кандидат в ядро. Из developer останется «прочитай flow, держи контроллер тонким, проследи побочки, повтори стиль соседей». Из hosting-providers не останется ничего.
Что меняется, а что нет
Одинаковый скилл в тринадцати проектах не означает тринадцать одинаковых файлов. Меняется в них ровно один слой.
Скелет developer во всех проектах один:
1. Подтверди flow от маршрута до побочных эффектов.
2. Держи контроллеры тонкими, логику — там, где это принято в репозитории.
3. Проследи побочные эффекты явно.
4. Повтори стиль соседних файлов, не изобретай новую раскладку.Дальше идёт слой конкретики, и он разный. В Laravel-проекте это Eloquent, очереди, уведомления, Blade, папки app/ и resources/views/. В Symfony-проекте — модули, контракт сервиса на возврат строки ошибки вместо исключения, репозитории с интерфейсом в домене и реализацией в инфраструктуре, переводы в трёх локалях, миграции Doctrine.
Что не должно меняться, но у меня разъехалось: язык. В части репозиториев скиллы на русском, в части на английском, и это следствие того, что писались они в разные месяцы под разное настроение. На работу не влияет, на сравнение файлов влияет сильно: два скилла с одинаковым смыслом невозможно сличить построчно.
Пограничные случаи
Два скилла ведут себя странно и стоят отдельного разбора.
frontend-design формально в ядре: он в тринадцати из тринадцати. Но его содержимое ближе к предметной области, чем у соседей по группе, — в нём палитра, темы, типографика конкретного сайта. Общий у него только запрет на безликую эстетику и требование сначала посмотреть на существующие компоненты. Я держу его в ядре ради этого запрета, а тело переписываю в каждом проекте почти целиком.
local-dev — обратный случай. Он есть только в двух Symfony-проектах, где запуск через .local/docker-compose.yml неочевиден и легко перепутать с корневой заглушкой. В Laravel-проектах той же роли не досталось отдельного скилла: команда запуска через контейнер уместилась в три строки CLAUDE.md.
По логике это одна и та же потребность — «как здесь вообще запускать команды». В одном стеке она стоит скилла, в другом строки. Единого решения я не нашёл и, честно говоря, не уверен, что оно нужно.
Ядро как стартовый набор
Практическая польза от шестёрки одна: новый проект начинается не с пустого места.
Порядок, которым я поднимаю скиллы в новом репозитории:
1. Копирую шесть скиллов ядра из ближайшего проекта того же стека.
2. Правлю в них слой конкретики: пути, команды, имена сущностей.
3. Скелет и порядок разделов не трогаю.
4. Доменные скиллы не завожу вообще, пока не появится третий повтор.Четвёртый пункт — самый важный и самый нарушаемый. Соблазн сразу написать скилл про предметную область велик, потому что в начале проекта кажется, что правила понятны. Они не понятны: половина того, что я записал бы на старте блога, через месяц оказалась бы неверной.
Когда скилл уходит из ядра
Признак один: в теле появились правила, которые верны только здесь.
code-review в блоге постепенно оброс проверками про экранирование пользовательского HTML и про политику безопасности содержимого. Оба пункта важные, оба специфичны для проекта, где контент хранится как HTML в базе. При копировании в фотоархив они бессмысленны.
Правильное действие — вынести их в отдельный доменный скилл или в AGENTS.md проекта, а code-review вернуть в общий вид. Я это сделал наполовину: часть вынес, часть оставил, потому что руки не дошли. Так что мой code-review сейчас не совсем ядро, и я это знаю.
Что осталось
Шесть скиллов ядра — это меньше, чем я ожидал до подсчёта. Мне казалось, что общего сильно больше, а на деле совпадает только способ работы. Вся ценность накопленных наборов лежит в единичных доменных скиллах, тех самых, которые встречаются по одному разу.
Из этого следует неприятное: ядро копируется легко и стоит дёшево, а полезное не копируется вообще. Каждый новый проект получает готовый способ работы за десять минут и накапливает собственные правила месяцами.
Про то, как ядро расходится по репозиториям и что я с этим делаю, — в статье про синхронизацию. Спойлер: скрипт есть, эталонного репозитория нет, и это узкое место.
