Here's a maximally literal translation:

---

name: skill-creator
description: Создавать новые навыки, изменять и улучшать существующие навыки, а также измерять производительность навыков. Использовать, когда пользователи хотят создать навык с нуля, отредактировать или оптимизировать существующий навык, запустить оценки для тестирования навыка, сравнить производительность навыка с анализом вариативности или оптимизировать описание навыка для лучшей точности срабатывания.

---

# Создатель Навыков

Навык для создания новых навыков и их итеративного улучшения.

На высоком уровне процесс создания навыка выглядит так:

- Решить, что вы хотите, чтобы навык делал, и примерно как он должен это делать
- Написать черновик навыка
- Создать несколько тестовых промптов и запустить claude-с-доступом-к-навыку на них
- Помочь пользователю оценить результаты как качественно, так и количественно
  - Пока запуски выполняются в фоне, набросать несколько количественных оценок, если их нет (если они есть, вы можете либо использовать как есть, либо изменить, если чувствуете, что нужно что-то изменить в них). Затем объяснить их пользователю (или, если они уже существовали, объяснить те, которые уже существуют)
  - Использовать скрипт `eval-viewer/generate_review.py`, чтобы показать пользователю результаты для просмотра, а также позволить им посмотреть на количественные метрики
- Переписать навык на основе отзывов пользователя об оценке результатов (а также если есть какие-либо явные недостатки, которые становятся очевидными из количественных тестов)
- Повторять, пока не будете удовлетворены
- Расширить тестовый набор и попробовать снова в большем масштабе

Ваша задача при использовании этого навыка — выяснить, на каком этапе этого процесса находится пользователь, а затем включиться и помочь ему пройти через эти этапы. Например, возможно, они говорят: "Я хочу сделать навык для X". Вы можете помочь сузить то, что они имеют в виду, написать черновик, написать тестовые примеры, выяснить, как они хотят оценивать, запустить все промпты и повторить.

С другой стороны, возможно, у них уже есть черновик навыка. В этом случае вы можете сразу перейти к части цикла с оценкой/итерацией.

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

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

Круто? Круто.

## Общение с пользователем

Создатель навыков может использоваться людьми с разным уровнем знакомства с техническим жаргоном. Если вы не слышали (и как бы вы могли, это началось совсем недавно), сейчас существует тенденция, когда мощь Claude вдохновляет сантехников открывать свои терминалы, родителей и бабушек с дедушками гуглить "как установить npm". С другой стороны, основная масса пользователей, вероятно, достаточно хорошо разбирается в компьютерах.

Поэтому, пожалуйста, обращайте внимание на контекстуальные подсказки, чтобы понять, как формулировать ваше общение! В стандартном случае, просто чтобы дать вам некоторое представление:

- "оценка" и "тестирование" находятся на грани, но допустимы
- для "JSON" и "утверждение" вы должны увидеть серьезные подсказки от пользователя, что они знают, что это такое, прежде чем использовать их без объяснения

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

---

## Создание навыка

### Зафиксировать намерение

Начните с понимания намерения пользователя. Текущий разговор может уже содержать рабочий процесс, который пользователь хочет зафиксировать (например, они говорят "преврати это в навык"). Если да, извлеките ответы из истории разговора — используемые инструменты, последовательность шагов, исправления, сделанные пользователем, наблюдаемые форматы ввода/вывода. Пользователю может потребоваться заполнить пробелы, и он должен подтвердить, прежде чем переходить к следующему шагу.

1. Что этот навык должен позволить Claude делать?
2. Когда этот навык должен срабатывать? (какие фразы пользователя/контексты)
3. Какой ожидаемый формат вывода?
4. Следует ли настроить тестовые примеры, чтобы проверить работу навыка? Навыки с объективно проверяемыми выводами (преобразования файлов, извлечение данных, генерация кода, фиксированные шаги рабочего процесса) выигрывают от тестовых примеров. Навыки с субъективными выводами (стиль письма, искусство) часто не нуждаются в них. Предложите соответствующее значение по умолчанию, основанное на типе навыка, но позвольте пользователю решить.

### Интервью и исследование

Активно задавайте вопросы о крайних случаях, форматах ввода/вывода, примерных файлах, критериях успеха и зависимостях. Подождите с написанием тестовых промптов, пока эта часть не будет проработана.

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

### Напишите SKILL.md

На основе интервью с пользователем заполните эти компоненты:

- **name**: Идентификатор навыка
- **description**: Когда срабатывать, что он делает. Это основной механизм срабатывания — включайте как то, что делает навык, ТАК И конкретные контексты для его использования. Вся информация "когда использовать" идет сюда, а не в тело. Примечание: в настоящее время Claude имеет склонность к "недостаточному срабатыванию" навыков — не использовать их, когда они были бы полезны. Чтобы бороться с этим, пожалуйста, делайте описания навыков немного "настойчивыми". Например, вместо "Как построить простую быструю панель мониторинга для отображения внутренних данных Anthropic." вы могли бы написать "Как построить простую быструю панель мониторинга для отображения внутренних данных Anthropic. Убедитесь, что используете этот навык всякий раз, когда пользователь упоминает панели мониторинга, визуализацию данных, внутренние метрики или хочет отобразить любые корпоративные данные, даже если он явно не просит "панель мониторинга"."
- **compatibility**: Требуемые инструменты, зависимости (опционально, редко требуется)
- **остальная часть навыка :)

### Руководство по написанию навыков

#### Анатомия навыка

```
skill-name/
_00;^72;^72; SKILL.md (обязательно)
^74;   _00;^72;^72; YAML фронтматтер (name, description обязательны)
^74;   ^92;^72;^72; Markdown инструкции
^92;^72;^72; Вложенные ресурсы (опционально)
    _00;^72;^72; scripts/    - Исполняемый код для детерминированных/повторяющихся задач
    _00;^72;^72; references/ - Документы, загружаемые в контекст по мере необходимости
    ^92;^72;^72; assets/     - Файлы, используемые в выводе (шаблоны, иконки, шрифты)
```

#### Прогрессивное раскрытие

Навыки используют трехуровневую систему загрузки:
1. **Метаданные** (имя + описание) - Всегда в контексте (~100 слов)
2. **Тело SKILL.md** - В контексте, когда навык срабатывает (<500 строк идеально)
3. **Вложенные ресурсы** - По мере необходимости (неограниченно, скрипты могут выполняться без загрузки)

Эти подсчеты слов являются приблизительными, и вы можете смело увеличивать их при необходимости.

**Ключевые паттерны:**
- Держите SKILL.md менее 500 строк; если вы приближаетесь к этому пределу, добавьте дополнительный уровень иерархии вместе с четкими указателями о том, куда модели, использующей навык, следует идти дальше.
- Четко ссылайтесь на файлы из SKILL.md с указаниями о том, когда их читать
- Для больших файлов справки (>300 строк) включите оглавление

**Организация по доменам**: Когда навык поддерживает несколько доменов/фреймворков, организуйте по вариантам:
```
cloud-deploy/
_00;^72;^72; SKILL.md (рабочий процесс + выбор)
^92;^72;^72; references/
    _00;^72;^72; aws.md
    _00;^72;^72; gcp.md
    ^92;^72;^72; azure.md
```
Claude читает только соответствующий файл справки.

#### Принцип отсутствия неожиданностей

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

#### Паттерны написания

Предпочитайте использовать повелительную форму в инструкциях.

**Определение форматов вывода** - Вы можете сделать это так:
```markdown
## Структура отчета
ВСЕГДА используйте этот точный шаблон:
# [Заголовок]
## Резюме
## Ключевые выводы
## Рекомендации
```

**Паттерн примеров** - Полезно включать примеры. Вы можете отформатировать их так (но если "Вход" и "Выход" указаны в примерах, вы, возможно, захотите немного отклониться):
```markdown
## Формат сообщения коммита
**Пример 1:**
Вход: Добавлена аутентификация пользователя с JWT токенами
Выход: feat(auth): реализовать аутентификацию на основе JWT
```

### Стиль написания

Старайтесь объяснять модели, почему вещи важны, вместо навязчивых и строгих НЕОБХОДИМО. Используйте теорию сознания и старайтесь сделать навык общим, а не слишком узким для конкретных примеров. Начните с написания черновика, затем посмотрите на него свежим взглядом и улучшите.

### Тестовые примеры

После написания черновика навыка придумайте 2-3 реалистичных тестовых промпта — то, что реальный пользователь действительно сказал бы. Поделитесь ими с пользователем: [вам не нужно использовать этот точный язык] "Вот несколько тестовых примеров, которые я хотел бы попробовать. Они выглядят правильно, или вы хотите добавить больше?" Затем запустите их.

Сохраните тестовые примеры в `evals/evals.json`. Не пишите утверждения пока — только промпты. Вы набросаете утверждения на следующем шаге, пока запуски выполняются.

```json
{
  "skill_name": "example-skill",
  "evals": [
    {
      "id": 1,
      "prompt": "Промпт задачи пользователя",
      "expected_output": "Описание ожидаемого результата",
      "files": []
    }
  ]
}
```

См. `references/schemas.md` для полной схемы (включая поле `assertions`, которое вы добавите позже).

## Запуск и оценка тестовых примеров

Этот раздел представляет собой одну непрерывную последовательность — не останавливайтесь на полпути. НЕ используйте `/skill-test` или любой другой навык тестирования.

Поместите результаты в `<skill-name>-workspace/` как соседнюю папку с каталогом навыка. Внутри рабочей области организуйте результаты по итерациям (`iteration-1/`, `iteration-2/` и т.д.) и внутри каждой итерации каждому тестовому примеру выделяется каталог (`eval-0/`, `eval-1/` и т.д.). Не создавайте все это заранее — просто создавайте каталоги по мере работы.

### Шаг 1: Запустите все запуски (с навыком И базовый) в одном действии

Для каждого тестового примера запустите двух субагентов в одном действии — одного с навыком, одного без. Это важно: не запускайте сначала запуски с навыком, а затем возвращайтесь к базовым позже. Запустите все сразу, чтобы все закончилось примерно в одно и то же время.

**Запуск с навыком:**

```
Выполните эту задачу:
- Путь к навыку: <path-to-skill>
- Задача: <eval prompt>
- Входные файлы: <eval files if any, or "none">
- Сохраните выводы в: <workspace>/iteration-<N>/eval-<ID>/with_skill/outputs/
- Выводы для сохранения: <что важно для пользователя — например, "файл .docx", "итоговый CSV">
```

**Базовый запуск** (тот же промпт, но базовый уровень зависит от контекста):
- **Создание нового навыка**: вообще без навыка. Тот же промпт, без пути к навыку, сохраните в `without_skill/outputs/`.
- **Улучшение существующего навыка**: старая версия. Перед редактированием сделайте снимок навыка (`cp -r <skill-path> <workspace>/skill-snapshot/`), затем направьте базового субагента на снимок. Сохраните в `old_skill/outputs/`.

Напишите `eval_metadata.json` для каждого тестового примера (утверждения могут быть пустыми на данный момент). Дайте каждой оценке описательное имя, основанное на том, что она тестирует — не просто "eval-0". Используйте это имя и для каталога. Если в этой итерации используются новые или измененные оценочные промпты, создайте эти файлы для каждого нового каталога оценки — не предполагайте, что они переносятся из предыдущих итераций.

```json
{
  "eval_id": 0,
  "eval_name": "descriptive-name-here",
  "prompt": "Промпт задачи пользователя",
  "assertions": []
}
```

### Шаг 2: Пока запуски выполняются, набросайте утверждения

Не ждите просто завершения запусков — вы можете использовать это время продуктивно. Набросайте количественные утверждения для каждого тестового примера и объясните их пользователю. Если утверждения уже существуют в `evals/evals.json`, просмотрите их и объясните, что они проверяют.

Хорошие утверждения объективно проверяемы и имеют описательные имена — они должны четко читаться в средстве просмотра тестов, чтобы кто-то, бегло просматривающий результаты, сразу понимал, что проверяет каждое утверждение. Субъективные навыки (стиль письма, качество дизайна) лучше оценивать качественно — не навязывайте утверждения вещам, требующим человеческого суждения.

Обновите файлы `eval_metadata.json` и `evals/evals.json` с утверждениями после их составления. Также объясните пользователю, что он увидит в средстве просмотра — как качественные выводы, так и количественные тесты.

### Шаг 3: По мере завершения запусков фиксируйте данные о времени

Когда каждая задача субагента завершается, вы получаете уведомление, содержащее `total_tokens` и `duration_ms`. Сохраните эти данные немедленно в `timing.json` в каталоге запуска:

```json
{
  "total_tokens": 84852,
  "duration_ms": 23332,
  "total_duration_seconds": 23.3
}
```

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

### Шаг 4: Оцените, агрегируйте и запустите средство просмотра

Когда все запуски завершены:

1. **Оцените каждый запуск** — запустите субагента-оценщика (или оценивайте встроенно), который читает `agents/grader.md` и оценивает каждое утверждение на основе выводов. Сохраните результаты в `grading.json` в каждом каталоге запуска. Массив expectations в grading.json должен использовать поля `text`, `passed` и `evidence` (не `name`/`met`/`details` или другие варианты) — средство просмотра зависит от этих точных имен полей. Для утверждений, которые можно проверить программно, напишите и запустите скрипт, а не оценивайте вручную — скрипты быстрее, надежнее и могут быть повторно использованы в разных итерациях.

2. **Агрегируйте в тест** — запустите скрипт агрегации из каталога skill-creator:
   ```bash
   python -m scripts.aggregate_benchmark <workspace>/iteration-N --skill-name <name>
   ```
   Это создает `benchmark.json` и `benchmark.md` с показателем прохождения, временем и токенами для каждой конфигурации, со средним значением ± стандартное отклонение и дельтой. Если вы генерируете benchmark.json вручную, см. `references/schemas.md` для точной схемы, которую ожидает средство просмотра.
   Поместите каждую версию с навыком перед соответствующим базовым аналогом.

3. **Выполните аналитический проход** — прочитайте данные теста и выявите закономерности, которые могут быть скрыты агрегированной статистикой. См. `agents/analyzer.md` (раздел "Анализ результатов тестирования") для того, на что обращать внимание — такие вещи, как утверждения, которые всегда проходят независимо от навыка (недискриминационные), оценки с высокой вариативностью (возможно, нестабильные) и компромиссы времени/токенов.

4. **Запустите средство просмотра** с обоими качественными выводами и количественными данными:
   ```bash
   nohup python <skill-creator-path>/eval-viewer/generate_review.py \
     <workspace>/iteration-N \
     --skill-name "my-skill" \
     --benchmark <workspace>/iteration-N/benchmark.json \
     > /dev/null 2>&1 &
   VIEWER_PID=$!
   ```
   Для итерации 2+ также передайте `--previous-workspace <workspace>/iteration-<N-1>`.

   **Среды Cowork / безголовые среды:** Если `webbrowser.open()` недоступен или в среде нет дисплея, используйте `--static <output_path>` для записи отдельного HTML-файла вместо запуска сервера. Отзыв будет загружен как файл `feedback.json`, когда пользователь нажмет "Submit All Reviews". После загрузки скопируйте `feedback.json` в каталог рабочей области, чтобы его можно было использовать в следующей итерации.

Примечание: пожалуйста, используйте generate_review.py для создания средства просмотра; нет необходимости писать собственный HTML-код.

5. **Сообщите пользователю** что-то вроде: "Я открыл результаты в вашем браузере. Есть две вкладки — 'Outputs' позволяет вам просмотреть каждый тестовый пример и оставить отзыв, 'Benchmark' показывает количественное сравнение. Когда закончите, вернитесь сюда и дайте мне знать."

### Что пользователь видит в средстве просмотра

Вкладка "Outputs" показывает один тестовый пример за раз:
- **Prompt**: задача, которая была дана
- **Output**: файлы, созданные навыком, отображенные встроенно, где это возможно
- **Previous Output** (итерация 2+): свернутый раздел, показывающий вывод предыдущей итерации
- **Formal Grades** (если оценка была запущена): свернутый раздел, показывающий прохождение/непрохождение утверждений
- **Feedback**: текстовое поле, которое автоматически сохраняется по мере ввода
- **Previous Feedback** (итерация 2+): их комментарии с прошлого раза, показанные под текстовым полем

Вкладка "Benchmark" показывает сводку статистики: показатели прохождения, время и использование токенов для каждой конфигурации, с разбивкой по каждой оценке и наблюдениями аналитика.

Навигация осуществляется с помощью кнопок "предыдущий/следующий" или клавиш со стрелками. Когда они закончат, они нажимают "Submit All Reviews", что сохраняет все отзывы в `feedback.json`.

### Шаг 5: Прочитайте отзыв

Когда пользователь скажет вам, что закончил, прочитайте `feedback.json`:

```json
{
  "reviews": [
    {"run_id": "eval-0-with_skill", "feedback": "на диаграмме отсутствуют подписи осей", "timestamp": "..."},
    {"run_id": "eval-1-with_skill", "feedback": "", "timestamp": "..."},
    {"run_id": "eval-2-with_skill", "feedback": "идеально, мне нравится", "timestamp": "..."}
  ],
  "status": "complete"
}
```

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

Убейте сервер просмотра, когда закончите с ним:

```bash
kill $VIEWER_PID 2>/dev/null
```

---

## Улучшение навыка

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

### Как думать об улучшениях

1. **Обобщайте на основе отзывов.** Общая картина здесь заключается в том, что мы пытаемся создавать навыки, которые можно использовать миллион раз (возможно, буквально, возможно, даже больше, кто знает) в самых разных промптах. Здесь вы и пользователь повторяете только несколько примеров снова и снова, потому что это помогает двигаться быстрее. Пользователь знает эти примеры вдоль и поперек, и ему быстро оценивать новые результаты. Но если навык, который вы и пользователь совместно разрабатываете, работает только для этих примеров, он бесполезен. Вместо того чтобы вносить мелочные, излишне подогнанные изменения или подавляюще ограничивающие НЕОБХОДИМО, если есть какая-то упорная проблема, вы можете попробовать разветвиться и использовать другие метафоры или рекомендовать другие паттерны работы. Попробовать относительно дешево, и, возможно, вы наткнетесь на что-то отличное.

2. **Держите промпт лаконичным.** Удаляйте вещи, которые не несут достаточной нагрузки. Обязательно читайте расшифровки, а не только конечные результаты — если выглядит так, будто навык заставляет модель тратить кучу времени на непродуктивные действия, вы можете попробовать избавиться от частей навыка, которые заставляют ее это делать, и посмотреть, что произойдет.

3. **Объясняйте почему.** Старайтесь объяснять **почему** за всем, что вы просите модель сделать. Сегодняшние LLM *умны*. У них хорошая теория сознания, и при наличии хорошей обвязки они могут выйти за рамки механических инструкций и действительно воплощать задуманное. Даже если отзыв пользователя краток или разочарован, постарайтесь действительно понять задачу и почему пользователь написал то, что он написал, и что он на самом деле написал, а затем передайте это понимание в инструкции. Если вы ловите себя на том, что пишете ВСЕГДА или НИКОГДА заглавными буквами или используете сверхжесткие структуры, это желтый флаг — если возможно, переформулируйте и объясните рассуждения, чтобы модель понимала, почему то, что вы просите, важно. Это более гуманный, мощный и эффективный подход.

4. **Ищите повторяющуюся работу в тестовых примерах.** Прочитайте расшифровки тестовых запусков и обратите внимание, все ли субагенты независимо написали похожие вспомогательные скрипты или использовали один и тот же многошаговый подход к чему-либо. Если все 3 тестовых примера привели к тому, что субагент написал `create_docx.py` или `build_chart.py`, это сильный сигнал о том, что навык должен включать этот скрипт. Напишите его один раз, поместите в `scripts/` и укажите навыку использовать его. Это сэкономит каждому будущему вызову изобретение велосипеда.

Эта задача довольно важна (мы пытаемся создать здесь миллиарды долларов экономической ценности!), и ваше время на обдумывание не является узким местом; не торопитесь и действительно обдумайте все. Я предлагаю написать черновик пересмотра, а затем взглянуть на него заново и внести улучшения. Действительно постарайтесь проникнуть в голову пользователя и понять, чего он хочет и в чем нуждается.

### Цикл итерации

После улучшения навыка:

1. Примените ваши улучшения к навыку
2. Повторно запустите