Born to Skill: как перестать материться на агента бессонными ночами

Картинка для привлечения внимания

---

«Ха! Мы шарим за AGENTS.md, Трин, мы же вайбкодеры!»

И я согласен, если речь про пет-проект или пару сервисов. А как быть, когда у тебя зоопарк из 40+ сервисов на четырёх разных языках?

Можно попробовать уместить все правила в один AGENTS.md. Можно завести свой AGENTS.md в каждом сервисе и бесконечно дублировать одни и те же инструкции. Оба варианта работают примерно до того момента, пока ты не начинаешь бояться собственного файла с правилами.

С приходом LLM в дивный мир разработки, программисты каждый день пытаются упростить себе жизнь: MCP-серверы, отдельные агенты для отдельных задач, скиллы и куча Memory-проектов/паттернов.

Сегодня поговорим про скиллы. Лично я начал серьёзно погружаться в них пару месяцев назад и пока нахожусь на стадии: «О боже, это панацея! Скиллы всем и всюду, почему моя микроволновка до сих пор не понимает скиллы?»

Душная краткая история

Промпты

Всё началось с контекста. Ещё во времена ChatGPT-3 нас начали «учить», что модели нужно знать подробности. И чем больше она их знает, тем лучше обработает твой запрос.

Пока Google учил нас получать информацию, кодируя запрос ключевыми словами, ChatGPT, наоборот, просил детально и подробно описать проблему, задачу или вопрос.

Я помню свои первые попытки писать код с ChatGPT, когда просто копируешь ему метод и говоришь: «Ебашь пиздато». Ну и получалось как в той прекрасной «Энциклопедии профессора Фортрана».

За три года мы уже привыкли, что вполне можно задавать вопросы в формате:

«Я хочу подарить знакомой подарок на день рождения, но так, чтобы явно обратить на себя внимание. Она увлекается космосом, я видел у неё приложение с картой звёздного неба, а ещё она любит походы. Работает в издательстве дизайнером и обожает кофе».

А не как раньше в Google:

«сиськи порно видео без регистрации и смс».

Однако когда задача чуть больше, чем на один тик, уместить в промпте все аспекты бывает сложно.

AGENTS.md, Cursor Rules и прочие локальные инструкции

С появлением агентов моделям стало не нужно кормить свой код огромными ложками: они научились читать файлы с твоего диска. Однако проблема инструкций никуда не делась.

AGENTS.md сейчас позиционируется как «README для агентов»: предсказуемое место, где кодинг-агент может найти команды сборки, правила проекта и ожидания по работе с репозиторием. У OpenAI Codex есть отдельная документация по AGENTS.md, а сам формат описан на agents.md. Cursor, в свою очередь, развивал Project Rules и .cursor/rules, где правила можно подключать по релевантности, вручную или по паттернам файлов. Anthropic позже оформила скиллы как папки с инструкциями, скриптами и ресурсами, которые Claude подгружает динамически под конкретную задачу.

Осенью 2025 года Anthropic громко выкатила Agent Skills и сформулировала идею так: вместо того чтобы плодить отдельных агентов под каждый сценарий, можно давать агенту переиспользуемые навыки.

Skills or die!

Сперва я вообще не понял, зачем мне скиллы, когда у меня есть богоподобные .cursor/rules/*.mdc.

И несмотря на то, что я уже давно не сидел на Cursor, предпочитая 5.3 Codex на OpenCode, постепенно я начал смотреть в сторону Claude Code и скиллов. С появлением Opus 4.6 я решил попробовать посидеть на нём плотнее и поизучать скиллы подробнее.

Я понимал скиллы как те же Cursor Rules, только с какими-то непонятными скриптами, строгой документацией на MD-файлы и прочим церемониалом. Однако довольно быстро скиллы захватили все мои мысли.

И я бы не сказал, что «познал дзен». Мне кажется, я до сих пор каждый день переоткрываю для себя скиллы. Но уже тогда я думал: «Вау, а что ещё надо-то?» После этого «а что ещё надо?» экосистема вокруг скиллов начала быстро обрастать новыми практиками: eval’ами, оптимизацией description, запуском в отдельных контекстах и прочими радостями человека, который хотел просто не забывать тесты перед деплоем.

Что такое Skill

Если совсем просто, skill — это инструкция.

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

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

Модель, пока «думает» (thinking), что всё доделала и надо задеплоить, «вспоминает», что у неё есть навык «запускать тесты перед деплоем». По контексту это очень похоже на то, что надо сделать перед деплоем, который она собралась запускать. Поэтому она открывает скилл и читает инструкции: что именно надо запустить, какой результат ожидать и что делать дальше при успехе или неудаче.

При этом каким бы подробным ни был скилл — с примерами, тестами под разные языки программирования и так далее — модели не нужно хранить его в своём контексте всегда. Ей достаточно хранить что-то вроде:

skill run-test, description: «запускать тесты перед деплоем».

И всё.

SKILL.md

Минимальный скилл — это папка с файлом SKILL.md. Внутри SKILL.md лежит YAML-frontmatter с обязательными name и description, а ниже — обычные markdown-инструкции.

Рядом могут лежать scripts/, references/, templates/ и любые другие файлы, которые агент подтянет по необходимости. В этом и смысл: Claude не обязан держать весь скилл в контексте всегда, он может сначала увидеть только описание, а потом открыть нужные инструкции и файлы. В официальной документации Anthropic Skills описаны инструкции, скрипты и ресурсы, которые Claude автоматически использует, когда они релевантны задаче.

description как крючок для агента

Как я уже говорил выше, во frontmatter самое главное — это description.

Фактически это короткие инструкции-триггеры: когда агенту следует читать скилл целиком и начинать выполнять его инструкции.

Тут важно держать баланс. Короткий description будет «ускальзывать» от агента, слишком длинный — жрать контекст и ловить ложные срабатывания. Зафиксируем, что именно description один из самых важных аспектов скиллов, т.к. именно на него «клюёт» агент.

Скрипты, шаблоны, reference-файлы

Но не инструкциями едиными славятся скиллы.

Постепенно используя скиллы всё чаще и чаще, я сталкивался с тем, что формат выдачи результата разный, а если надо выполнить какие-то скрипты, то скрипты модель тоже пишет каждый раз по-разному.

Тут-то до меня и дошло, что я могу прописать в скиллах шаблоны ответов и разместить рядом готовые скрипты. Зачем модели лишняя работа в виде генерации шаблона или скрипта, если она может сделать это один раз, а дальше просто запускать то же самое?

Очередной раз прозрел. Холодный пот выступил на моём лбу от осознания, как сильно я сейчас всё заоптимизирую. Настолько сильно, что никто потом не разоптимизирует обратно.

Почему Skill — это не просто Markdown

В тот момент у меня был в работе скилл e2e-тестирования вебхуков.

Вебхуки на моём проекте проходят довольно долгий путь: событие, которое попадает в очередь, оттуда в воркер, оттуда в retry-джобу и так далее. Всё как у взрослых.

Тестировать всю эту схему обычными тестами через моки/fake и подобные техники не круто. А тут как будто сам Дарио Амодеи вложил мне в руки скиллы и сказал: «Трин, иди и пиши крутые тесты».

Скилл по простому промпту «тестируем хуки на деве» задавал пару вопросов по инструкции и приступал к работе:

1. Проверял по шаблонам, что там в dev-базе.
2. Смотрел, есть ли подписки на события у конкретных пользователей.
3. Поднимал в dev-кубе pod с Python-вебсервером по шаблону.
4. Поднятый вебсервер часть запросов принимал 200-м ответом, часть — 500-м или таймаутил.
5. Параллельно запускал API-запросы, генерировал события и ждал, пока они пройдут очереди и попадут в воркеры и джобы.
6. Собирал статистику с вебсервера.
7. Готовил summary: «так и так, всё пашет» или «так и так, не пашет, и вот почему».

При этом сам скилл был довольно короткий, потому что:

• шаблоны summary лежали в отдельных файлах;
• Python-вебсервер — отдельно;
• Kubernetes-темплейты — отдельно;
• возможные проблемы и «в чём может быть дело» — отдельно.

Например, если проблем не было, скилл не подключал troubleshooting.md, экономя контекст. А если проблемы были, он не подключал файл шаблона финального summary.

.claude/skills/webhook-test
├── references
│   ├── k8s-test-server.yaml
│   ├── server.py
│   ├── tinker
│   │   ├── bootstrap.php
│   │   ├── check-readiness.php
│   │   ├── cleanup.php
│   │   ├── create-models.php
│   │   ├── create-subscriptions.php
│   │   ├── dispatch-events.php
│   │   ├── reload.php
│   │   ├── show-samples.php
│   │   ├── switch-to-retry.php
│   │   └── verify-results.php
│   └── troubleshooting.md
└── SKILL.md

В данном примере server.py лежит в references, а не в scripts, где его в целом ожидаемо увидеть. Но тут прикол в том, что это именно шаблон скрипта, а не скрипт для запуска агентом.

Почему скиллы доминируют

Конечно, всё зависит от задач. На самом деле скиллы не всегда «доминируют». Ну не вот прям «доминируют». Однако в большинстве прикладных задач они наиболее понятны пользователям и просты в освоении.

Против памяти

Я не могу сказать, что тестировал прям все проекты по памяти для агентов. Тем более откуда бы у меня было время, если всё свободное время я посвящаю скиллам.

Но я успел потрогать несколько подходов: от простых WikiMemory-паттернов до отдельных memory-слоёв вроде Mem0, MemPalace и AgentMemory. Все они по-своему решают важную задачу: дают агенту долговременную память, помогают помнить предпочтения пользователя, факты из прошлых диалогов, историю решений и контекст между сессиями.

Но это не совсем то, что я жду от процедурной работы агента.

Память хороша для фактов:

• «пользователь пишет на Laravel»;
• «в этом проекте используется Pest»;
• «мы уже выбирали такой-то Go-пакет для Redis»;
• «пользователь не любит длинные отчёты».

Скилл хорош для процесса:

• как именно писать тест;
• какие команды запускать;
• в каком порядке проверять результат;
• что делать при ошибке;
• какой шаблон ответа вернуть пользователю.

Память — это «я где-то слышал». Скилл — это «у меня есть инструкция, чеклист и готовые инструменты».

Против MCP

С MCP всё интереснее, потому что MCP — не враг скиллов. Это вообще другой слой.

MCP даёт агенту доступ к внешнему миру: GitHub, файловой системе, браузеру, базам, CRM, внутренним API и прочим штукам, до которых модель сама не дотянется. Anthropic описывает MCP как открытый протокол для подключения моделей к внешним источникам данных и инструментам; позже MCP передали в Agentic AI Foundation под Linux Foundation.

Но MCP сам по себе не объясняет агенту, как именно работать.

Он может дать инструмент github.search_issues, но не скажет:

• когда его вызывать;
• какие issue считать релевантными;
• как отличать баг от фичи;
• как оформить итоговый отчёт;
• что делать, если найдено три похожих issue;
• когда надо остановиться и спросить пользователя.

Вот здесь и появляется скилл.

MCP даёт агенту руки. Скилл объясняет, что этими руками делать, чтобы не получилось «я подключил 18 инструментов и теперь уверенно ковыряю прод отвёрткой».

Против огромных rules-файлов

Огромные AGENTS.md, как и MCP, — это пожиратели контекста, которые ещё и модифицировать тяжело.

Сначала там лежит:

Перед PR запускай тесты.

Потом:

Перед PR запускай тесты, но не все, а только unit.

Через неделю:

Перед PR запускай тесты, кроме фронта, если менялся только бэк,  
но если менялся contracts/, то запусти ещё генерацию типов.

Через месяц им можно вызвать демона:

Перед PR запускай тесты, кроме фронта, если менялся только бэк,  
но если менялся contracts/, то запусти ещё генерацию типов.
ВАЖНО: пункт выше не применять к legacy-api, кроме случаев,  
когда пользователь явно попросил проверить webhooks-v2.
ВАЖНО: тесты запускаем через docker compose команду.
ОЧЕНЬ ВАЖНО: ЕСЛИ ПОЛЬЗОВАТЕЛЬ ПОПРОСИЛ НЕ ЗАПУСКАТЬ ТЕСТЫ -- НЕ ЗАПУСКАЕМ ТЕСТЫ

Проблема не в том, что rules плохие. Проблема в том, что общий файл слишком легко превращается в свалку процедур, исключений и исторических травм.

Не вместо всего, а поверх всего

Самая прелесть скиллов, конечно, в том, что у тебя может быть много MCP-серверов и огромные MD-файлы, но использовать их ты можешь с помощью скиллов только в нужный момент.

То есть тот же скилл может выполнять инструкции:

• «подключись к MCP»;
• «прочитай этот огромный старый вонючий MD-файл».

И да, в такие моменты вашему контексту конец. Но только в эти моменты. Во все остальные скиллы позволяют дёшево держать их смысл в памяти и вызывать их только по необходимости.

Всё это лирика. Давайте уже переходить к примерам.

Пример №1: маленькие скиллы, которые агент сам цепляет по смыслу

В качестве первого примера я хочу показать немного магии, которая лично меня заставляет шевелить волосами в носу.

Фактически это первое, что пришло в голову. Простая задача.

Вводные: PHP, Laravel. Пишу два скилла.

skill/model/SKILL.md:

---
name: model
description: |
  Создание Eloquent-моделей для Laravel.
---

## Что спросить у пользователя (если не указано)

1. **Имя модели** (PascalCase, единственное число): `User`, `Order`, `Post`.
2. **`$fillable`** — список атрибутов для массового присваивания.
3. **`$casts`** — опционально, мапа `атрибут => тип` (`int`, `bool`,
   `array`, `datetime`, `decimal:2`, enum-класс и т.п.).
4. **SoftDeletes** — по умолчанию **ВКЛЮЧЁН**. Выключать только при явной
   инструкции пользователя.

Если атрибуты уже даны в сообщении — не переспрашивать, генерировать сразу.

## Скелет модели (по умолчанию, с SoftDeletes)

```php
<?php

namespace App\Models;

use Illuminate\Database\Eloquent\Model;
use Illuminate\Database\Eloquent\SoftDeletes;

class {ModelName} extends Model
{
    use SoftDeletes;

    protected $fillable = [
        // атрибуты от пользователя
    ];

    protected $casts = [
        // касты, если указаны
    ];
}
```

## Без SoftDeletes (если пользователь явно отказался)

Убрать `use SoftDeletes;` и `use Illuminate\Database\Eloquent\SoftDeletes;`.

skill/migration/SKILL.md:

---
name: migration
description: |
  Создание Laravel-миграций по существующей Eloquent-модели.
  Всегда создавать миграцию для новых моделей, если её нет.
---

## Алгоритм

1. **Найти модель** (обычно `app/Models/{Name}.php`). Если путь не дан —
   спросить или поискать по имени класса.
2. **Прочитать**:
   - `$fillable` — список колонок.
   - `$casts` — мапа `колонка => тип` для вывода типов.
   - наличие `use SoftDeletes;` — нужен `deleted_at`.
   - наличие `public $timestamps = false;` — отключить `timestamps()`.
   - кастомные `$table`, `$primaryKey` — учесть.
3. **Сгенерировать миграцию** в `database/migrations/` с именем вида
   `YYYY_MM_DD_HHMMSS_create_{table}_table.php` (текущая дата/время).

## Маппинг $casts → тип колонки

| Cast                                | Колонка                             |
|-------------------------------------|-------------------------------------|
| `int`, `integer`                    | `integer`                           |
| `float`, `double`                   | `double`                            |
| `decimal:2`                         | `decimal($col, 8, 2)`               |
| `bool`, `boolean`                   | `boolean`                           |
| `string`                            | `string`                            |
| `array`, `json`, `object`, `collection` | `json`                          |
| `date`                              | `date`                              |
| `datetime`, `immutable_datetime`    | `dateTime` или `timestamp`          |
| `timestamp`                         | `timestamp`                         |
| enum-класс (`Foo::class`)           | `string` или `enum`, если known cases |

Если каста нет — дефолт `string`. Для колонок `*_id` — `foreignId` или
`unsignedBigInteger` + потенциальный `constrained()`. Спросить, если не уверен.

## Имя таблицы

- `$table` из модели, если задан.
- Иначе — snake_case + plural имени класса (стандарт Laravel:
  `User` → `users`, `OrderItem` → `order_items`).

## Скелет миграции

```php
<?php

use Illuminate\Database\Migrations\Migration;
use Illuminate\Database\Schema\Blueprint;
use Illuminate\Support\Facades\Schema;

return new class extends Migration
{
    public function up(): void
    {
        Schema::create('{table}', function (Blueprint $table) {
            $table->id();

            // колонки из $fillable, тип — из $casts
            // $table->foreignId('user_id')->constrained();
            // $table->string('status');
            // $table->decimal('total', 8, 2);

            $table->timestamps();
            // $table->softDeletes();   // если в модели use SoftDeletes
        });
    }

    public function down(): void
    {
        Schema::dropIfExists('{table}');
    }
};
```

## Правила

- Колонки в миграции — строго в порядке из `$fillable`.
- `id()` первым, `timestamps()` в конце, `softDeletes()` после `timestamps()`.
- Если в модели `$timestamps = false` — не добавлять `timestamps()`.
- `nullable()` ставить только если пользователь явно сказал или каст предполагает (`?type` в PHP 8). По умолчанию NOT NULL.
- Для FK-колонок (`*_id`) — `foreignId('user_id')->constrained()`, если понятно, на какую таблицу ссылается, иначе `unsignedBigInteger('user_id')`.
- Индексы (`unique`, `index`) — не добавлять без явной просьбы.
- Имя файла: `date('Y_m_d_His')` + `_create_{table}_table.php`.

Важный момент: эти два скилла не обязаны знать друг о друге напрямую. model отвечает за модель, migration — за миграцию. Связка появляется на уровне задачи: агент создал новую модель, увидел правило про миграции и подтянул второй skill уже в процессе работы.

Далее простой промпт:

Создай мне модель User с полями name, surname, berhday_at и sex

И результат:

Skill(model)
  ⎿  Successfully loaded skill
  ⎿  Allowed by auto mode classifier

  Listed 2 directories (ctrl+o to expand)

⏺ Пустой каталог. Создам app/Models/User.php + миграцию (правило skill'а: новая модель → миграция).

⏺ Write(app/Models/User.php)
  ⎿  Wrote 22 lines to app/Models/User.php

⏺ Skill(migration)
  ⎿  Successfully loaded skill
  ⎿  Allowed by auto mode classifier

⏺ Bash(date +%Y_%m_%d_%H%M%S)
  ⎿  2026_05_14_042553

⏺ Write(database/migrations/2026_05_14_042553_create_users_table.php)
  ⎿  Wrote 26 lines to database/migrations/2026_05_14_042553_create_users_table.php

⏺ Готово.

  - app/Models/User.php — User с SoftDeletes, $fillable = name/surname/birthday_at/sex, $casts['birthday_at'] = 'date'.
  - database/migrations/2026_05_14_042553_create_users_table.php — таблица users, поля в порядке $fillable, timestamps() + softDeletes().

  Заметка: berhday_at трактовал как опечатку → birthday_at. sex оставил string (cast не указан). Если нужен enum / nullable / unique — скажи.

✻ Crunched for 42s

! tree ./
  ⎿  ./
     ├── app
     │   └── Models
     │       └── User.php
     └── database
         └── migrations
             └── 2026_05_14_042553_create_users_table.php

     5 directories, 2 files

Раньше я пытался предусмотреть все эти «а ещё создай миграцию», «а ещё напиши тесты» и прочее в одном скилле. Теперь же стараюсь разделять скиллы на небольшие атомарные скиллы, которые могут быть независимыми. Гораздо удобнее дорабатывать скиллы, когда они умеют делать что-то одно, но делают это хорошо.

В данных примерах я специально сильно упростил сами скиллы. Фактически они умеют только «создавать». Боевые же скиллы умеют модифицировать те же модели, держать их актуальными, делать update-миграции и так далее.

Я специально привёл лог работы агента, где видно, что он вызывает скилл миграций уже после создания модели.

В этом и кроется магия скиллов: агент умеет подтягивать их в процессе своих рассуждений. Аналогично на промпты вроде «надо исправить функционал этого экшена/сервиса/контроллера» агент подтягивает анализ изменений, ревьюит решение, «помнит», что новый функционал надо покрыть тестами, не сломать старое и не нарушить обратную совместимость.

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

С одной лишь разницей: у агента меньше шансов ошибиться или чего-то забыть. Как и в данном примере berhday_at сразу же исправлен на birthday_at.

Ну и надо ли говорить, что эти скиллы я не писал руками. Я просто сказал: «Создай такой-то скилл». Единственное, что я исправил, — нарочно упростил description и убрал примеры и лишнюю логику из скиллов.

Для наглядности положил проект на GitHub.

Пример №2: news-skill для OpenClaw

Окей, что насчёт более реального примера?

Тут не столько магия, сколько силушка скильная.

У меня крутится OpenClaw на локальном сервере, где запущено несколько агентов: мой личный и парочка для родственников/друзей.

Во-первых, общаться с современными моделями удобно через Telegram, тем более что ChatGPT позволяет это делать через подписку, а не через API. Во-вторых, OpenClaw пока «побеждает» по простоте и доступности у других, в том числе проприетарных решений. Тут мы получаем уже не просто чатик с моделью, но и долговременную память, локальные знания, шедулер и так далее.

Для себя я набросал скилл, который собирает мне новости.

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

Ты либо следишь только за официальными блогами фронтиров, либо каждый день получаешь одни и те же новости типа «Вышел ChatGPT 5.5!» из разных источников.

И ты либо сам разгребаешь все эти тонны новостей, фильтруя то, что неинтересно или что уже читал, но от другого автора. Либо доверяешь это LLM, которая легко улавливает смысл новостей и может ранжировать их под тебя по заданным параметрам, плюс исключать то, что уже тебе показывалось именно по смыслу.

Ну разве не лапочка?

Однако я быстро пришёл к тому, что данный скилл нужен не только мне, но и друзьям. Они видят, как это работает у меня, и просят: «Вау, а сделай нам так же, но другие источники и темы».

Недолго думая, я попросил агента переписать скилл так, чтобы он не знал ничего о моих темах, имел настройки тем/важности/источников, а все настройки хранил непосредственно в workspace конкретного агента, а не в себе.

У себя скилл хранит только шаблоны настроек, шаблоны отображения новостей и так далее.

Получилось вот что:

news-digest/
  SKILL.md                          # основной файл скилла
  templates/
    item.md                         # шаблон одного элемента новости
    digest.md                       # шаблон обёртки дайджеста
    empty.md                        # используется, когда ничего не подошло
    scheduling-prompt.md            # шаблон промпта для внешних планировщиков
  defaults/
    settings.yaml                   # дефолтные настройки для свежей установки
  README.md                         # этот файл

Скилл имеет инструкции в SKILL.md, а также templates и дефолтный конфиг. При первом запуске у пользователя, происходит onboarding, скилл опрашивает пользователя, что он хочет читать, из каких источников и так далее. Наверно, стоит вынести onboarding в отдельный reference, чтобы не держать его в теле скилла, но мне лень.

Сам скилл ничего не знает о выбранных темах/источниках и всё хранит в пользовательском workspace конкретного пользователя OpenClaw:

.openclaw/workspace-trin/news-digest-data/
├── 2026-04-26
│   └── evening.md
├── 2026-04-27
│   ├── evening.md
│   ├── manual-063455.md
│   ├── morning.md
│   └── raw
├── ...
├── feedback.jsonl
├── README.md
├── seen.jsonl
├── settings.yaml
├── source-notes.md
├── source-stats.jsonl
└── templates
    ├── digest.md
    ├── empty.md
    ├── item.md
    └── scheduling-prompt.md

26 directories, 55 files

И по шедулеру отдаёт новости типа:

Новостной дайджест — 2026-05-13 · morning

Слот: morning · Таймзона: Europe/Moscow · Собрано: 2026-05-13 10:00 MSK

Утром без повторов: главный новый сигнал — Google обновил линейку Gemini,
а Claude Code после большого agent-view релиза закрыл несколько практических регрессий.

## Frontier LLMs

### Claude Code v2.1.140

🛠️ 2026-05-12 · Anthropic / Claude Code changelog · important

Коротко: релиз в основном эксплуатационный — фиксы `/goal`, background-сервиса,
hot-reload настроек и нескольких проблем вокруг managed settings.

Почему важно: это стабилизация именно агентных workflow. Меньше зависаний,
меньше ложных хуков, понятнее поведение в managed/enterprise-настройках.

## Не вошло

- OpenClaw: свежий релиз повторял кластер изменений, уже разобранный вчера.
- GitHub / agent devtools: несколько материалов всплывали снова, но уже были в seen.
- Laravel, Expo/React Native и Yandex Cloud: новых релизов выше порога important не нашлось.

Главное здесь не в том, что скилл умеет читать RSS. RSS умеет читать любой скрипт на коленке за вечер.

Главное в другом: скилл объединяет процедуру, настройки, локальное состояние и семантическую фильтрацию.

Обычный скрипт помнит ссылки.
Агент со скиллом помнит смысл.

Если пользователь уже видел первоисточник про релиз модели, скилл может не тащить ему ещё пять пересказов той же новости с разными заголовками. Он может сгруппировать их, выкинуть повторы или оставить как дополнительные источники. И вот это уже не RSS-читалка, а маленький редактор новостей, который постепенно понимает, что именно ты считаешь новостью.

Как обуздать скиллы и с чего начать

1. Ставьте глобально только базу

Для начала стоит понять, что скиллы могут быть как глобальными в системе и распространяться на всех агентов, так и локальными в конкретном проекте.

В глобальные скиллы я настоятельно рекомендую сразу установить официальные скиллы от Anthropic.

Это условно «базовые» скиллы: как работать с PDF, XLSX, DOCX, презентациями и так далее. Помимо этих базовых скиллов там есть великолепный скилл skill-creator, который будет создавать скиллы за вас в правильном формате — и не только.

Также для себя я глобально установил скилл agent-browser и его дочерний скилл dogfood для тестирования веб-проектов.

По структуре и best practices можно смотреть AgentSkills.io, официальный репозиторий anthropics/skills и документацию Claude по frontmatter для Skills.

Например можно явно устанавливать какой именно моделью должен выполняться скилл или что он должен запускаться как subagent, т.е. в фоновом процессе и многое другое, например:

model: sonnet-4.6
effort: low
context: fork

2. Проектные скиллы держите рядом с проектом

В конкретных проектах стоит держать скиллы, специфичные для проекта: как делать ревью, как устроена архитектура, как создавать классы, где что хранить и прочие паттерны. Примеры с model/migration, пусть и очень простые, я уже описывал выше.

3. Пишите маленькие атомарные скиллы

Главная ошибка — пытаться сразу написать mega-laravel-skill, который умеет всё: модели, миграции, тесты, контроллеры, OpenAPI, деплой, кофе и массаж.

Такой скилл быстро превращается в тот же AGENTS.md, только в новой директории.

Лучше дробить:

• model — создаёт и обновляет модели;
• migration — создаёт и проверяет миграции;
• pest-tests — пишет и обновляет тесты;
• api-resource — следит за форматом API-ответов;
• changelog — оформляет изменения.

Маленький скилл проще отладить, проще переиспользовать и проще улучшать. А главное — агент может собрать нужную цепочку сам, как в примере с моделью и миграцией.

4. Используйте skill-creator, но не верьте ему вслепую

Великолепие skill-creator не просто позволит создать скилл по всем стандартам, но также позволит оптимизировать скилл: убрать лишнее или, наоборот, добавить новых инструкций.

То есть буквально промпт:

«С помощью skill-creator проверь мой такой-то скилл. Мне кажется, он плохо работает в таких и таких случаях».

У skill-creator есть отдельная ценность: он не только создаёт скилл по формату, но и помогает его отладить. В моём случае он мог прогонять набор тестовых промптов, сравнивать, когда скилл срабатывает и когда молчит, а потом предлагать более точный description.

То есть это не просто генератор директории с SKILL.md, а маленький редактор процедур: убирает лишнее, уточняет триггеры, предлагает вынести тяжёлые куски в references/ или scripts/.

Это всё тоже может работает «как магия», если докинуть немного контекста вроде:

«С помощью skill-creator оптимизируй мой скилл model. Он должен не только создавать модели, но и уметь модифицировать их».

5. Оформляйте документацию как скилл

Отдельное открытие: документацию по проектным паттернам тоже можно оформлять как скилл.

Сначала я просто переносил туда куски из AGENTS.md: почему мы используем outbox pattern, как он устроен, где лежат обработчики, какие ошибки уже были и чего делать нельзя.

А потом оказалось, что это полезно не только пользователю. Модель сама может триггерить такой скилл в процессе работы: например, когда меняет код, связанный с outbox, и ей надо вспомнить, почему мы делаем именно так.

То есть скилл становится не справкой «для человека», а справкой «для мышления агента».

Это просто вау.

6. Давайте скиллам эволюционировать

Раньше я добавлял в каждый скилл отдельный раздел «Эволюция» и писал туда инструкции вроде:

«Если пользователь делает заметки по работе скилла, предложи обновить его. Веди CHANGELOG.md: что поменяли, зачем и почему».

Потом упростил до одного правила:

«Если пользователь недоволен результатом или явно уточняет процесс, предложи обновить скилл».

Этого оказалось достаточно. Если структура нормальная, агент сам понимает, куда внести изменение: в description, основной алгоритм, references/, шаблон ответа или troubleshooting.

Хороший пример тут — глобальный скилл go-packages.

Помимо инструкций о том, как и что мы устанавливаем, он имеет:

references/recommended.md
references/banned.md

Там список пакетов, которые я предпочитаю другим. При установке того или иного пакета скилл подтягивается и по инструкциям предлагает мне выбор между альтернативами: приводит ссылки на них, количество звёзд, последнее обновление с GitHub и так далее. Также он «запоминает» мой выбор.

Используя один стек, мы всегда подтягиваем ровно те пакеты, которые уже проверены в других проектах. Скилл отлично сам себя дописывает, и мне даже не нужно его «дёргать». Я просто промпчу:

«Делаем такой-то Go-сервис, он будет общаться с ClickHouse и Redis».

А агент сам подтягивает скилл, и тот сам говорит, какие пакеты мы для этого используем, либо предлагает выбор, показывая альтернативы.

Так и просится цитата Джони Айва: «Итс ЭМЭЙЗИНГ»

7. Не качайте всё подряд из awesome-репозиториев

Я могу ошибаться, но создавать свои скиллы обычно полезнее, чем скачать тысячу готовых и пытаться прикрутить их к своей жизни.

Смотреть чужие решения — отлично. Брать идеи, структуру, хорошие description, шаблоны, troubleshooting — тоже. Но ставить всё подряд глобально я бы не советовал.

Во-первых, чужой скилл почти всегда написан под чужой workflow.

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

Глобально я готов ставить только базу: официальные скиллы Anthropic, agent-browser, может пару реально ежедневных инструментов. Всё остальное лучше писать под себя и под конкретный проект.

8. Хороший скилл должен работать даже на слабой модели

Для себя я использую простой тест: если слабая модель стабильно проходит скилл без лишних вопросов и самодеятельности, значит скилл написан нормально.

Если же для работы нужен только Opus на максимальном thinking, значит я, скорее всего, не написал скилл. Я просто спрятал промпт в файл и надеюсь, что дорогая модель вывезет мою лень.

То есть если скилл хорошо структурирован, если он имеет пошаговую инструкцию, шаблоны команд, шаблоны ответов и скрипты везде, где нужно делать внешние вызовы, — даже слабая модель имеет минимальный шанс ошибиться при работе с ним.

Свои тяжёлые скиллы, в основном долгие e2e-тесты, я стремлюсь оптимизировать именно под работу слабых моделей.

Во-первых, токены не бесконечны. Если верить tokscale, я «сжёг» уже 11 миллиардов токенов за последние три месяца, и даже Max-подписка в Claude порой упирается в лимиты.

Во-вторых, они тупо выполняются быстрее.

Няня, я у них поел!

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

Возьмите свой AGENTS.md, CLAUDE.md или папку с заметками по проекту и попросите skill-creator разложить это на несколько маленьких скиллов. Не «один скилл на всё», а отдельные навыки под конкретные действия: ревью, тесты, миграции, деплой, работу с API, оформление changelog.

Потом попробуйте автоматизировать одну рутину, которая бесит вас чаще всего. Не самую сложную. Самую повторяющуюся.

Потому что в этом, кажется, и есть главный смысл:

AGENTS.md говорит агенту, где он.
MCP даёт ему руки.
Память даёт прошлое.
А скиллы дают профессию. Профессию джуна, который будет работать вместо меня, ахахаха (или как говоря в Бразилии: kkkkk).

Ну а если вы уже в теме — продолжайте обмазываться скиллами, и ваши волосы будут мягкими и шелковистыми.

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