05. Skills: повторяемые рабочие процедуры
← Предыдущий модуль · Оглавление · Следующий модуль →
Если сейчас только читаете: русский разбор ситуации без запуска программ. После него ответьте на вопросы самопроверки модуля; практическое упражнение можно отложить.
Результат модуля: вы можете оценить существующий skill и подготовить проект узкой процедуры без установки непроверенных инструкций.
Skill — каталог с SKILL.md, где обязательны name и description; рядом могут быть scripts, references и assets. Сначала Codex видит метаданные, полные инструкции читает при выборе. Skills могут вызываться явно либо подбираться по описанию. Для локального проекта используется .agents/skills вдоль пути от текущего каталога к корню репозитория; пользовательская область — ~/.agents/skills. Одинаковые имена не означают объединения. В CLI и IDE доступны /skills и упоминание через $; интерфейс desktop может отличаться. Изменения обычно обнаруживаются автоматически; при проблеме документация советует перезапуск. Build skills.
Начните с конкретной повторяющейся ошибки процесса. Например, при разборе тестов забывают указать команду запуска и зависимость от окружения. Для этого полезна узкая процедура. Создавать огромный skill «делай всё программирование правильно» не стоит: трудно определить, когда он действительно нужен, а когда лишь увеличивает объём инструкций.
Ниже приведён только текст учебного SKILL.md. Он не устанавливается этим руководством и не является готовым проверенным расширением:
---
name: explain-test-failure
description: Разбирай предоставленный вывод упавших тестов. Используй, когда нужно объяснить сбой тестовой команды; не используй для реализации новой функции.
---
1. Найди точную команду, рабочий каталог и первый значимый сбой.
2. Раздели наблюдаемые факты и предположения о причине.
3. Укажи недостающие сведения об окружении.
4. Предложи один следующий диагностический шаг.
5. Не меняй рабочие файлы и не публикуй полный журнал.
Верни: команда; упавший тест; свидетельство; возможная причина;
неопределённость; следующий шаг.
В описании одновременно указаны назначение и граница. Это помогает оценивать выбор процедуры. Если запрос касается верстки, такой skill не нужен. Если журнал содержит токен или частные данные, перед передачей уберите их; процедура анализа не требует секретов для объяснения большинства сбоев.
Разделяйте проектные знания и общую последовательность. Команда конкретного теста и путь к сервису относятся к проекту. Порядок «выделить сбой, отделить факты, назвать следующий шаг» можно применять в разных репозиториях. Не зашивайте личные пути Windows в распространяемый skill. Если нужен скрипт, он должен принимать путь как входной параметр и проверять целевой каталог.
Проверка skill состоит не только в чтении красивого Markdown. Подготовьте несколько заданий, для которых он нужен, и несколько соседних, где не нужен. Сравните ответы по заранее выбранным критериям. Полезный результат — меньше пропущенных доказательств или более точная диагностика, а не просто более длинный ответ.
Для первоначального опыта достаточно изучить уже установленный и разрешённый skill. Перед копированием чужого каталога прочитайте инструкции и используемые скрипты. Проверьте, не предполагает ли процедура публикацию, удаление, загрузку данных или доступ к аккаунту. Если skill указывает внешний инструмент, убедитесь, что он действительно доступен и авторизован.
Практика. Выберите разрешённый skill в своей среде. Выпишите его назначение, входные данные, действия и признаки завершения. Дайте ему небольшой обезличенный пример. Затем дайте соседнее задание, где процедура не нужна. Запишите факт выбора и качество результата отдельно: правильный выбор ещё не гарантирует правильного выполнения.
Если подходящего установленного skill нет, проведите упражнение на тексте выше: оцените полноту инструкции и составьте примеры запросов для проверки. Установка для понимания механизма не обязательна.
Для сравнения выберите один и тот же обезличенный журнал и одинаковое требование к ответу. Сначала получите обычный разбор, затем разбор по процедуре. Проверьте, названа ли команда, отделена ли ошибка программы от проблемы окружения, есть ли подтверждение предполагаемой причины и можно ли выполнить предложенный следующий шаг. Не меняйте одновременно данные, инструменты и критерии: иначе нельзя понять, что повлияло на ответ. Если процедура лишь повторяет очевидные советы, оставьте обычный запрос. Если она стабильно предотвращает важный пропуск, появляется основание поддерживать её как отдельный рабочий материал.
Критерий проверки: вы можете объяснить, почему skill нужен, чем он отличается от AGENTS.md, какие действия допускает и как проверить ошибочное срабатывание. Непроверенный сторонний код не установлен.
Самопроверка:
- Почему описание skill влияет на выбор процедуры?
- Какие сведения из примера принадлежат проекту, а какие повторяемому процессу?
- Что докажет, что skill приносит пользу по сравнению с обычным заданием?
Структурная основа: upstream, модуль 05. Проверено 24 октября 2026 года.