Ask HN: как разработчики управляют skills-файлами ИИ-агентов

На Hacker News прошло масштабное обсуждение формата Ask HN: как вы управляете skills-файлами для ИИ-агентов? Автор треда (284 балла, 258 комментариев) спрашивает, где люди находят skills, как их организуют, как убеждаются, что они реально работают, и улучшают ли их со временем. Попутно он озвучивает распространённое опасение: «полагаю, skills рано или поздно будут поглощены возможностями самих моделей».

Ответы получились показательными: от «skills — это змеиный жир» до «без них я не представляю свою работу». Разбираем главное.

Свои skills против скачанных коллекций

Самый залайканный ответ — не искать skills, а писать свои. Пользователь picklenerd формулирует так: он делает skills только для повторяющихся воркфлоу, хранит их в git и symlinks-ом подключает к папкам всех агентов. Скачивать чужие наборы он сравнивает с «коллекциями из тысяч закладок, куда ты никогда не кликнешь». В его наборе — такие навыки:

• убирать «агентский жаргон» из кода и документации;
• задавать вопросы в удобном ему порядке;
• объяснять агенту, как пользоваться jj (jujutsu);
• dispatch субагентов с шестью наборами приоритетов;
• вести локальный MD-трекер задач.

Пользователь 70rd добавляет: skills нужны, чтобы направлять конкретную модель к поведению, которого она не проявляет по умолчанию. «Это не покемон-карты. Они засоряют контекст, иногда с нулевой пользой». А в самом жёстком варианте — от avaer — скачивание skills названо «змеиным жиром»: если skills у вас столько, что ими нужно управлять, «это code smell».

Противовес — user itishappy, который приводит внутренние замеры компании: skills снижают расход токенов на флагманских моделях в 2–4 раза, и этот показатель растёт с новыми моделями — вероятно, из-за всё более активного использования субагентов, которым приходится заниматься собственным prompt engineering. Плюс хороший набор skills создаёт переносимую базу: поднимает нижнюю планку качества и даёт единообразный опыт по всей организации.

Skills как «кэш воркфлоу»

Одна из самых точных формулировок треда: «Skills — это кэши воркфлоу» (someguynamedq). Пользователь bastawhiz советует относиться к ним как к runbook, а не как к способу «превратить агента в эксперта». А jrockway описывает skill для релизов на работе: как согласовать canary (два сообщения в Slack), за чем следить во время rollout (инциденты, error rate относительно недренированных подов), как повторить для следующих тиров и обновлять тикет со статусом. Это, по его словам, «человекочитаемые компьютерные программы» — слишком ad-hoc для обычного скрипта, но слишком повторяющиеся, чтобы каждый раз объяснять заново.

Типичные категории рабочих skills из треда:

Интересный контр-инсайт от wongarsu: чем выше квалификация разработчика, тем меньше пользы от skills. Опытному хватает одной-двух фраз для планирования или запуска реализации. А вот тем, кто не разработчик, не хватает словаря: «если вы не знаете, что такое tenant isolation, ваше приложение получит сломанную модель безопасности — потому что вы не можете об этом попросить». Skills отчасти компенсируют этот пробел.

Где хранить: dotfiles, symlinks и маркетплейсы

Практическая часть треда свелась к нескольким устоявшимся паттернам:

• Отдельный git-репозиторий + symlinks — доминирующий подход. Skills живут в одном «источнике истины», а в ~/.claude/skills, ~/.codex/skills и прочие папки подключаются симлинками. KerrickStaley уточняет: Codex и Claude Code понимают общий каталог ~/.agents/skills, отдельные папки для каждого харнесса не обязательны.
• Через менеджеры dotfiles: chezmoi (jameshiew), guix home (ssivark), кто-то пинает версии через nix. ssivark делает ссылки двунаправленными, чтобы редактировать skills из любого харнесса.
• Скрипты синхронизации: yatsyk держит два репозитория (приватный и публичный) и агентописанный скрипт синка, который проверяет, что локальных правок «на месте» нет.
• Плагин-маркетплейсы: jve упаковал свои skills в плагин и подключил git-репозиторий как marketplace — claude plugin marketplace add <url> и установка одной командой без возни с симлинками. mceachen показывает свой публичный набор с инкрементом версий для автообновлений.

Для команд joshuanapoli описывает bootstrap-скрипт, который раскатывает корпоративные skills в личные папки разработчиков, а хуки Codex и Claude Code обновляют их на старте.

Skills против AGENTS.md

Отдельная линия спора — чем skills отличаются от обычного AGENTS.md. Технический ответ в треде дал oakesm9: в контексте постоянно находится только description из frontmatter — по нему агент решает, стоит ли читать остальное. Это progressive disclosure: детальная инструкция подгружается лишь при необходимости.

У AGENTS.md свой плюс — swingboy напоминает, что его содержимое попадает в system prompt и выигрывает от prompt caching. Отсюда рабочее разделение: AGENTS.md — компактные «высокоуровневые истины» (стек, инварианты, структура файлов), skills — то, что нужно часто, но не всегда. Пользователь distances довёл идею до предела: крошечный AGENTS.md-роутер, который отправляет LLM к десяткам маленьких MD-файлов по типу задачи. Не все согласны: notatoad считает, что «skills — это просто AGENTS.md, разбитый на куски», только с неудобным воркфлоу для шаринга.

Как убедиться, что skill работает

Здесь мнения разделились. alexhans предлагает относиться к skills как к коду и проверять их evals — как интеграционными тестами: прогоняешь кейсы, смотришь на регрессии, предпочитаешь структурированный вывод и простые детерминированные ассерты. Возражение от stingraycharles: на практике evals для нетривиальных навыков стоят «в 100 раз больше времени», чем написание самого skill. RicDan парирует: обязательные требования вообще нельзя обеспечивать промптом — для must-критериев нужны детерминированные проверки: хуки, скрипты, CI.

Практичные варианты из треда:

• Скрипты внутри skills: woud420 прикладывает переиспользуемые скрипты для детерминизма (например, валидация PR по шаблону); breckenedge пишет на Python циклы мониторинга CI, потому что даже Opus путает команды; pglevy комбинирует скрипты, шаблоны и JSON-заготовки, а для evals использует метод из официального skill-creator от Anthropic.
• Гибрид «скрипт + инструкция»: Achshar выносит в Python всё детерминированное (валидация, edge cases), а в markdown оставляет «мышление» — получает «скрипт, где рантайм — харнесс, а бизнес-логика — комбинация кода и интеллекта модели».
• Скептик-субагент: Azkar описывает свой воркфлоу из семи шагов (тикет → план → стресс-тест плана → реализация → валидация → ревью PR профильными агентами → фиксы) и называет самым ценным агент-«скептика»: «Ты скептик. Твоя работа — не принимать утверждения на веру... Ты не ревьюер стиля и не чирлидер». На каждое утверждение — вердикт: verified, unverified или contradicted.
• Эволюция со временем: tetha рассказывает, как агент классификации тикетов за 4–6 месяцев «выучил» жаргон и стиль мышления разных отделов — первая версия была невпечатляющей, а сила появилась от постоянных правок после каждого использования.

Ещё одна интересная привычка — просить агента самого обновлять skill после неудачи. Zambyte после каждого фейла с jira-cli спрашивает у модели, почему та не справилась, и просит дописать skill. А kkarpkkarp создаёт, правит и удаляет по skill в день: «увидел, что AI потратил слишком много времени и токенов — говорю Cursor сохранить это как skill».

Антипаттерны и здравый смысл

Из предостережений треда стоит выделить:

• Не копировать чужие наборы вслепую. Udo предлагает радикальные правила: начинать с нуля skills, добавлять только при встрече с нежелательным поведением, никогда не клонировать чужие репозитории skills и периодически удалять лишнее. fallinditch припоминает, что Борис Черныш (создатель Claude Code) советует время от времени удалять skills и хуки и наблюдать, как модель справляется без них.
• Токсичные любительские пакеты. igor_nast: «инфлюенсеры делают all-in-one паки skills — это не имеет смысла». matsemann жёстче: «skills — это тичброк-слово для markdown-файла с инструкциями», большинство публичных skills бесполезны, но вдохновляться идеями можно (например, принципом «заставь агента задавать уточняющие вопросы» из grill-me).
• Безопасность. edf13 напоминает: подписанные skills доказывают происхождение, но не поведение — вопрос доверия к чужим skills до конца не решён (в треде дают ссылку на отдельное обсуждение безопасности).

Экосистема вокруг skills

Обсуждение показало, что вокруг skills уже выросла инфраструктура: nori-skillsets — CLI и реестр для бандлов skills с переключением наборов (админский для слайдов, SWE для кода, отдельный для дебага) — автор theahura также продвигает мета-паттерн SPACE (search, plan, assert, code, evaluate); vercel-labs/skills как пакетный менеджер; agents от bensyverson — «пакетный менеджер для сниппетов AGENTS.md», причём автор замечает, что следование инструкциям из AGENTS.md у моделей лучше, чем adherence к skills; альтернативы вроде Skillshare и SkillCatalog.

Что в итоге

Консенсус треда можно свести к четырём пунктам:

1. Пиши свои skills под свои повторяющиеся воркфлоу, а не собирай чужие коллекции. Максимум — смотри чужие ради идей.
2. Храни их в git как код: dotfiles-репозиторий, symlinks или плагин-маркетплейс — что ближе.
3. Помни про экономику контекста: в AGENTS.md — короткие вечные истины, детали — в skills с хорошим description, обязательные требования — в хуки и скрипты, а не в промпт.
4. Пруни регулярно: skills, которыми вы не пользуетесь, — это технический долг и лишние токены.

И насчёт страха, что модели «съедят» skills: самое трезвое возражение в треде — если skill описывает воркфлоу, специфичный для вашей команды или компании, модель его из training data никак не возьмёт. А вот универсальные «kung fu от селебрити» действительно, скорее всего, умрут вместе с ростом интеллекта моделей.

Обсуждение целиком: Ask HN: How do you manage skills files?