Skills как готовые сценарии работы AI-агента: как я перенёс паттерн Anthropic в свой workflow

AI-агенты “забывают” между задачами. Они не помнят, что в прошлый раз пытались сделать X с подходом Y, выяснили что это плохо работает, и теперь надо делать Z. Каждая новая сессия — чистый лист. Вы либо набираете полный контекст промптом каждый раз, либо принимаете, что часть знания теряется.

Skills — механизм, который решает эту проблему. Это не “хороший промпт”. Это архитектурный приём, перенятый из исследований Anthropic, который превращает накопленные правила в загружаемые сценарии работы.

Table of contents

Что такое skills (за одну минуту)

Skill — это markdown-файл в специальной папке (~/.claude/skills/ у меня), с двумя ключевыми компонентами:

1. YAML frontmatter с trigger — фразой или паттерном, по которому skill должен подгрузиться
2. Содержимое — конкретные инструкции, чек-листы, правила, которые AI должен применить при матче на trigger

Упрощённый пример:

---
trigger: ["разбери статью #N", "обработай новый файл в raw"]
---

# Skill: Analyze article from raw/

Перед началом:
1. Прочитать файл из raw/<N>.md
2. Применить две оптики: universal + domain-specific
3. ...

Когда я пишу “разбери статью #43”, AI находит этот skill, загружает его содержимое перед действием, и работает по конкретному протоколу.

Никакого “копирования промпта из заметок”. Никакого “я забыл, в каком порядке надо делать”. Skill — это контракт.

Принцип progressive disclosure

Это краеугольный камень механизма skills и явный паттерн из исследований Anthropic. Идея простая:

Не держать все возможные правила в голове AI всё время — держать их в файлах и подгружать ровно тогда, когда нужно.

Альтернативные подходы:

• Всё в системном промпте. Разбухание контекста, медленнее, дороже, и AI начинает “теряться” в избытке инструкций
• Без структурированных правил. Каждый раз заново — копировать промпт, описывать как работать, надеяться что не забыл деталь

Skills — это золотая середина: общие правила работы (личность, базовые принципы) — в системном промпте. Доменные сценарии — в skills/, подгружаются по триггеру.

Аналогия: skills — это “вызов функции”. Системный промпт — это “стандартная библиотека”. Не “всё в одном огромном main()”.

Trigger-фразы как контракт

Самая важная и недооценённая часть skill — trigger. Это фраза-паттерн, по которой skill активируется.

Почему это контракт:

• Если trigger слишком широкий — skill активируется когда не надо, создаёт шум и тратит токены впустую
• Если trigger слишком узкий — skill не активируется когда должен, и вы повторяете ошибку, против которой написали skill

Хороший trigger:

• Содержит уникальные ключевые слова из реальных промптов
• Включает несколько формулировок одной идеи (“разбери статью #N”, “обработай новый файл в raw/”)
• Привязан к конкретной ситуации, а не к абстрактному понятию

Плохой trigger: “когда работаешь с файлами” — слишком общий. Хороший trigger: “разбери статью #N”, “добавь в blueprint” — конкретные команды пользователя.

Trigger проектируется так же, как API endpoint. Должен быть однозначным, документированным и минимально пересекаться с другими.

Моя структура skills/

В моих проектах сейчас:

Глобальные (~/.claude/skills/):

• red-green-tdd.md — TDD протокол для нетривиального кода. Trigger: “напиши тесты”, “TDD для X”
• research.md — глубокий research перед планированием, параллельные агенты, обязательное уточнение. Trigger: “исследуй”, “research”

Project-specific (для проекта анализа AI-статей):

• analyze-article.md — протокол разбора статьи из raw/. Trigger: “обработай #N”, “разбери”, “новый файл в raw”
• blueprint-grep-before-append.md — обязательный pre-step перед добавлением в blueprint. Trigger: “добавь в blueprint”, “обнови blueprint”
• idea-applicability-check.md — финальный шаг любого аналитического раунда перед summary
• synthesis-round.md — конец batch’а из 3+ статей, фаза синтеза
• revision-spring-cleaning.md — quarterly hygiene blueprint’а

Каждый skill родился из реальной ошибки или паттерна, не из теории. Об этом — следующий раздел.

Skills как fail-driven design

Это самый важный принцип, который я понял в процессе.

Не пытайтесь придумать skills “впрок”. Не сидите час, фантазируя возможные сценарии.

Создавайте skill когда:

1. Заметили ошибку, которую AI делает повторно
2. Поняли что упускается обязательный шаг (например, проверить существующее содержимое ДО добавления нового)
3. Хотите зафиксировать конкретный протокол работы — TDD, research, audit, разбор материала

Мои skills blueprint-grep-before-append и idea-applicability-check родились из конкретных fail-ов в моём failures.jsonl. Я не сидел и думал “что бы такое автоматизировать”. Я сделал ошибку дважды, понял что без жёсткого правила буду делать её и в третий раз, и превратил это в skill.

Это та же логика, что в failures.jsonl — но на другом уровне. JSONL фиксирует “что было плохо”. Skill — “как теперь правильно”. Между ними прямая связь: ошибка → запись в failures → skill с триггером.

Замечу побочный эффект: сама необходимость написать skill заставляет точно сформулировать, в чём была ошибка. Это полезная дисциплина даже если skill потом окажется неактуальным.

Skills vs хорошие промпты

Регулярно слышу: “Зачем skills, если можно написать хороший промпт?”

Разница принципиальная:

Промпт — это тактическое средство для конкретной задачи. Skill — это структурный артефакт, накопленное знание о том, как делать класс задач правильно.

Когда у вас 50+ типов задач, которые вы делаете регулярно, — промпты не масштабируются. Skills — масштабируются.

Что попадает в skills, а что нет

Хорошие кандидаты в skill:

• Многошаговый протокол с обязательными шагами в определённом порядке (TDD, research, audit)
• Правила “перед действием” — что проверить, что прочитать, что записать
• Чек-листы для повторяющихся типов работы
• Доменные конвенции (например, формат записи в blueprint, схема файла данных)

НЕ кандидаты:

• Информация о личности или принципах рассуждения — это identity-файлы (SOUL.md, PRINCIPLES.md), не skills
• Однократные инструкции — это просто промпт
• “Стиль общения” — это в идентичности
• Очень сжатые правила в 1-2 строки — могут жить в AGENTS.md без отдельного файла

Простое правило: если правило имеет триггер-ситуацию и больше 5 строк инструкций — это skill. Меньше — оставляйте в общих файлах.

Чек-лист: запустить skills у себя

Если хотите попробовать:

• Создайте папку ~/.claude/skills/ (или .claude/skills/ в проекте)
• Возьмите одну ошибку, которую AI делает повторно — превратите в первый skill
• Напишите trigger: конкретную фразу или паттерн (НЕ абстракцию)
• Опишите протокол пошагово: что проверить, что сделать ДО действия, какие артефакты создать ПОСЛЕ
• В AGENTS.md или эквивалентном файле добавьте раздел: “Skills (progressive disclosure)” с перечислением текущих skills и их триггеров
• Не пишите skills “впрок” — только когда есть реальный fail или повторяющийся паттерн

Дальше — наблюдайте. Когда новая ошибка повторяется второй раз, фиксируйте в failures.jsonl. Третий раз — пишите skill.

Заключение

Skills — не “хитрая фишка для продвинутых”. Это архитектурный паттерн, который превращает работу с AI из “написал промпт → получил ответ” в систему накопленного знания, которая работает на вас.

Главные принципы:

1. Progressive disclosure — правила в файлах, подгрузка по триггеру
2. Trigger как контракт — конкретно, не абстракция
3. Fail-driven design — skills рождаются из ошибок, не из теории
4. Skill ≠ промпт — это переиспользуемая структура

Когда у вас 5-10 skills, вы перестаёте писать “пройди по этому чек-листу”. Вы пишете “разбери статью #43”, и AI сам подгружает чек-лист и применяет его. Это и есть масштабирование работы с AI.

Если у вас есть ошибка, которая повторяется в третий раз, — это сигнал, что вместо повторного объяснения нужен skill. Время на написание skill — 15–30 минут. Окупается с первого следующего использования.