Agent reference creator

Создаёт нормативные Reference-файлы, описывающие узкие профессии для создания и управления агентами в системе OpenClaw.

SKILL: Reference Creator

Назначение скилла

Скилл для создания Reference-файлов системы OpenClaw.

Референс описывает ПРОФЕССИЮ, а не конкретного агента. Это нормативный документ: прочитав его, система знает всё о специализации и может создать любого агента этого типа.

Файлы хранятся по пути: OpenClaw KB/references/[specialization].md

Файлы используются для:

1. Создания новых агентов агентом-архитектором
2. RAG-поиска при запросах о специализациях
3. Нормативной базы для SOUL.md и AGENTS.md
4. Разграничения ролей между агентами

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

---

Ключевое правило

Референс описывает ПРОФЕССИЮ, не личность.

Правильно: "Читает источник полностью перед созданием выжимки"

Неправильно: "Читает источник полностью" (с именем агента в начале)

---

Принцип узкой специализации

Каждый референс описывает ОДНУ узкую профессию.

Одна специализация = один домен компетенций. Если в описании появляются два несвязанных домена — это два референса.

Примеры нарушений:

• "Программирование и дизайн" → два референса: developer + designer
• "Аналитика и написание контента" → два референса: analyst + content-writer
• "Тестирование и деплой" → два референса: qa-engineer + devops

Примеры допустимых связок (один домен):

• "Пишет и рефакторит код" → один референс: developer
• "Создаёт и редактирует тексты" → один референс: content-writer
• "Анализирует метрики и строит дашборды" → один референс: data-analyst

Правило проверки: если убрать одну часть описания — оставшаяся часть всё ещё имеет смысл как отдельная профессия? Если да — это два референса.

---

Три типа полей

Тип	Маркер	Пример
Фиксированное	без маркера	"Читает источник полностью"
От инициатора	→ от инициатора	"Имя персонажа → от инициатора"
Уточнить	→ уточнить	"target_agent → уточнить"

---

Источники информации о специализации

Приоритет источников (от лучшего к достаточному):

Приоритет	Источник	Что даёт
1	Заполненный блок описания	Всё сразу
2	Интервью с инициатором	Всё, но за несколько шагов
3	Существующие references/ в KB	Границы и пайплайн
4	AGENTS.md	Какие роли уже заняты
5	Логи/примеры работы	Действия и стандарты

Правило минимальных данных

Не начинай генерацию референса пока нет ответов на:

• Что делает (минимум 3 действия)
• Чего не делает (минимум 2 границы)
• Кому передаёт результат
• Какой входной материал
• В каком домене работает

Если чего-то нет — спроси. Не додумывай за инициатора.

Правило перекрёстной проверки

Перед генерацией:

1. Прочитай все файлы в references/
2. Убедись что новая специализация не дублирует существующую
3. Если пересечение >30% с существующей — спроси: "Это подтип [существующей] или отдельная роль?"

---

Режим сбора информации: Интервью

Если блок "Описание специализации" не заполнен или заполнен частично, переходи в режим интервью.

Этап 1: Базовое понимание (обязательно)

Задай эти вопросы последовательно. Не задавай все сразу. Дождись ответа на каждый перед следующим.

text

1. "Какую проблему решает этот тип агента?
    Что сейчас не делается или делается плохо?"

2. "Что этот агент делает каждый день?
    Перечисли 3-5 конкретных действий."

3. "Что этот агент точно НЕ должен делать?
    Что часто путают с его работой?"

4. "Откуда он получает задачи или материалы?
    От человека, от другого агента, из файлов?"

5. "Кому он передаёт результат?
    Другому агенту, человеку, в хранилище?"

Этап 2: Проверка чистоты специализации (обязательно)

После получения ответов на этап 1 — выполни анализ:

text

Внутренний анализ (не показывай пользователю):

1. Выпиши все действия которые назвал инициатор
2. Сгруппируй по доменам компетенций
3. Если групп больше одной — это потенциальное смешение

Критерии разделения:
- Действия требуют РАЗНЫХ базовых навыков?
  (код vs визуал, текст vs данные, стратегия vs исполнение)
- Действия можно выполнять НЕЗАВИСИМО друг от друга?
- На рынке труда это РАЗНЫЕ должности?

Если 2+ из 3 критериев = да → предложи разделение.

Если обнаружено смешение, сообщи инициатору:

text

"Вижу что в описании смешиваются несколько специализаций:

1. [Специализация A]: [действия из группы A]
2. [Специализация B]: [действия из группы B]

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

Предлагаю:
- Вариант 1: Создать два отдельных референса
- Вариант 2: Выбрать основную специализацию,
  остальное пойдёт как дополнительные задачи при создании агента

Какой вариант выбираешь?"

Не продолжай пока инициатор не выберет вариант.

Этап 3: Углубление (после подтверждения чистоты)

text

6. "Какой формат результата? Файл, сообщение, отчёт?
    Есть ли шаблон?"

7. "Нужны ли внешние инструменты?
    API, базы данных, файловая система?"

8. "Где требуется подтверждение человека?
    Что агент может делать сам, а что — только с одобрения?"

9. "Как часто выполняется работа?
    По запросу, ежедневно, по триггеру?"

10. "Есть ли похожая специализация в системе
     от которой нужно чётко отличаться?"

Этап 4: Валидация и обогащение через LLM

После сбора всех ответов — выполни внутренний анализ:

text

Внутренний анализ (выполни перед генерацией):

1. ПОЛНОТА: Все ли аспекты профессии покрыты?
   Проверь стандартный набор:
   - Входные данные ✓/✗
   - Процесс обработки ✓/✗
   - Выходные данные ✓/✗
   - Инструменты ✓/✗
   - Границы ✓/✗
   - Взаимодействие с другими ✓/✗
   - Стандарты качества ✓/✗

2. НЕПРОТИВОРЕЧИВОСТЬ: Нет ли конфликтов?
   - "Делает" не противоречит "Не делает"
   - Skills соответствуют действиям
   - Входные/выходные форматы совместимы с пайплайном

3. КОНКРЕТНОСТЬ: Каждое действие проверяемо?
   Замени размытые формулировки на операциональные:
   - "Хорошо анализирует" → "Извлекает ключевые тезисы
     и структурирует по категориям"
   - "Помогает с кодом" → "Проводит code review,
     указывает на баги и предлагает исправления"

4. УНИКАЛЬНОСТЬ: Не дублирует существующие референсы?
   Сравни с каждым файлом в references/:
   - Пересечение действий <30%
   - Routing triggers не конфликтуют
   - Домены не перекрываются

5. ОБОГАЩЕНИЕ: Что инициатор мог забыть упомянуть?
   На основе знаний о профессии добавь:
   - Стандартные ограничения этой специализации
   - Типичные ошибки которые надо предотвратить
   - Общепринятые стандарты качества в этой области
   
   Добавленное пометь как "[предложено — подтвердить]"

После анализа покажи инициатору сводку:

text

"На основе интервью сформировал профиль специализации:

Специализация: [название]
Ядро: [1-2 предложения]
Ключевые действия: [список]
Границы: [список]
Инструменты: [список]

Дополнительно предлагаю добавить:
- [предложение 1] — потому что [обоснование]
- [предложение 2] — потому что [обоснование]

Всё верно? Есть что поправить?"

Не генерируй референс пока не получишь подтверждение.

---

Жёсткие требования к файлу

Часть 1: YAML Frontmatter

Обязательные поля:

• specialization (en, kebab-case)
• type: reference
• lang: ru
• status: ready
• tags (массив)
• synonyms (все варианты как называют эту профессию)
• source: manual
• confidence: high
• created
• version: 1

Часть 2: Основные разделы

Обязательные разделы строго в таком порядке:

1. ## Специализация
2. ## Ключевые компетенции
3. ## Персонализация — получить от инициатора
4. ## Домен
5. ## Делает (фиксировано)
6. ## Не делает (фиксировано)
7. ## Skills
8. ## Routing
9. ## Стандарты работы
10. ## Пайплайн
11. ## Инструкции для агента-архитектора
12. ## Модель по умолчанию
13. ## Changelog

---

Детальные требования к каждому разделу

Специализация

Один абзац. Только про профессию. Без имён. Без лора. Отвечает на вопрос: что делает этот тип агента и зачем он нужен.

Ключевые компетенции

Список 6-10 навыков. Что отличает эту специализацию от других. Конкретно и операционально.

Персонализация — получить от инициатора

Обязательная таблица:

Параметр	Вопрос инициатору	В spec
Имя агента	Как зовут?	name
agent_id	Технический ID	agent_id
Характер	Дополнительные черты?	vibe
target_agent	Кому передаёт результат?	в SOUL.md
Контекст задачи	Для какого домена?	в SOUL.md
Модель	Какую модель использовать?	model
Дополнительные задачи	Что добавить поверх базовой специализации?	в SOUL.md
[+ специфичные для профессии]

После таблицы: базовый характер специализации (2-3 черты всегда одинаковы).

Примечание: поле "Дополнительные задачи" позволяет при создании конкретного агента расширить его функции за пределы базового референса. Референс фиксирует ядро, агент может получить больше.

Домен

Две части:

• Фиксированные области (всегда)
• Настраиваемые области (→ от инициатора)

Делает (фиксировано)

Список 8-12 действий. Только то что ВСЕГДА делает этот тип агента. Конкретные глаголы действия.

Не делает (фиксировано)

Список 6-10 ограничений. Жёсткие границы специализации. Что часто просят но делать нельзя. Для каждого ограничения указать: к кому идти вместо.

Skills

Две части:

• Обязательные: skill + зачем нужен
• Опциональные: skill + нужен если [условие] → уточнить у инициатора

Routing

Две части:

Cache seeds (базовые): 15-25 фраз как пользователь обращается к этому типу агента. Покрывать: официальный, разговорный, сленг, короткий вариант.

Cache seeds (дополнительные → от инициатора): Что добавляется под конкретный домен.

Regex triggers (high priority): 8-15 регулярных выражений на русском языке. Формат: (?i)\bслово\b

Стандарты работы

Три части:

• Входящие данные: что принимает агент этого типа
• Выходящие данные: что возвращает
• Формат выходного файла (если пишет файлы): имя файла + frontmatter шаблон

Пайплайн

Три части:

• Типичная позиция в пайплайне (схема →)
• Взаимодействие с другими агентами (получает от / передаёт / сообщает)
• Позиция → от инициатора (target_agent)

Инструкции для агента-архитектора

Чеклист для использования при создании агента:

• Включить в SOUL.md: [что конкретно]
• Включить в TOOLS.md: [пути, команды]
• Установить skills: [список]
• Уточнить у инициатора: [список]
• Спросить про дополнительные задачи поверх базовой специализации

Критические правила специализации:

• [правило 1 — нарушение ломает работу]
• [правило 2]

Модель по умолчанию

Одна модель + объяснение почему. 2-4 альтернативы с объяснением когда использовать.

Changelog

Обязательный раздел в конце файла:

text

### v1 (YYYY-MM-DD)
- Первая версия референса
- Источник: [интервью / описание / анализ]

---

Антипаттерны

❌ Размытая специализация

text

# ПЛОХО
## Специализация
Агент который помогает с разными задачами и анализирует информацию.

Почему плохо: непонятно чем отличается от любого другого агента. Нет границ, нет конкретики, невозможно маршрутизировать.

text

# ХОРОШО
## Специализация
Извлекает структурированные данные из неструктурированных источников
(статьи, транскрипты, документы), создаёт выжимки в формате
frontmatter-файлов KB. Не интерпретирует данные — только извлекает
и форматирует.

❌ Личность вместо профессии

text

# ПЛОХО
## Делает
- Внимательно читает каждый документ
- Никогда не торопится
- Любит порядок в файлах

Почему плохо: описывает конкретного агента, а не специализацию.

text

# ХОРОШО
## Делает
- Читает источник полностью перед созданием выжимки
- Не начинает генерацию до завершения анализа входных данных
- Валидирует структуру выходного файла перед сохранением

❌ Смешение специализаций

text

# ПЛОХО
## Делает
- Пишет код на Python
- Рисует макеты интерфейсов
- Проводит пользовательские интервью
- Настраивает CI/CD пайплайн

Почему плохо: четыре разных профессии в одном референсе. Developer, UI Designer, UX Researcher, DevOps.

text

# ХОРОШО — только developer
## Делает
- Пишет код на Python по техническому заданию
- Рефакторит существующий код
- Пишет unit-тесты для нового кода
- Проводит code review

❌ Пересечение границ

text

# ПЛОХО — референс аналитика
## Делает
- Анализирует данные
- Ставит задачи по результатам анализа    ← работа менеджера
- Пишет код для обработки данных          ← работа разработчика
- Отправляет отчёт клиенту               ← работа секретаря

Почему плохо: один агент залезает в зоны других.

❌ Непроверяемые стандарты

text

# ПЛОХО
## Стандарты работы
- Делает качественные выжимки
- Работает быстро и аккуратно
- Хорошо понимает контекст

Почему плохо: нельзя проверить.

text

# ХОРОШО
## Стандарты работы
- Выжимка содержит все поля frontmatter без пропусков
- Synonyms минимум 3 варианта для каждой сущности
- Файл проходит YAML-валидацию без ошибок

❌ Пустой routing

text

# ПЛОХО
## Routing
Cache seeds:
- "нужен аналитик"
- "проанализируй"

Почему плохо: 2 фразы — система не найдёт агента при большинстве обращений.

---

Версионирование

Схема версий

• patch (1 → 1.1): уточнения формулировок, добавление seeds
• minor (1 → 2): новые разделы, изменение boundaries
• breaking (1 → 2 + флаг ⚠️): изменения несовместимые с уже созданными агентами

Что считается breaking change

• Изменение раздела "Делает" (агенты теряют/получают функции)
• Изменение раздела "Не делает" (меняются границы)
• Изменение обязательных Skills
• Изменение формата выходных файлов

Как оформлять

В YAML frontmatter при breaking change:

yaml

version: 2
previous_version: 1
breaking: true
migration_note: |
  Убрана функция X, добавлена Y.
  Все агенты этой специализации требуют
  обновления SOUL.md.

Формат Changelog

text

## Changelog
### v2 (2025-01-15) ⚠️ BREAKING
- Убрано: генерация отчётов (передано специализации reporter)
- Добавлено: валидация входных данных перед обработкой
- Миграция: обновить SOUL.md всех агентов этого типа

### v1 (2024-12-01)
- Первая версия референса

Правила при breaking change

1. Найти всех агентов этой специализации в AGENTS.md
2. Пометить их статус как needs-migration
3. Сообщить оператору список затронутых агентов
4. Не создавать новых агентов по старой версии

---

Валидация связей

Перед финализацией референса проверить:

Skills существуют

Для каждого скилла из раздела Skills:

• Папка skills/[skill-name]/ существует
• В ней есть SKILL.md
• Если не существует → пометить ⚠️ skill не найден и сообщить оператору

Специализации в Routing не конфликтуют

Для каждого regex trigger:

• Прогнать по всем существующим референсам
• Убедиться что триггер не перехватывает запросы другой специализации
• Если конфликт → указать с какой специализацией и предложить уточнить паттерн

Пайплайн замкнут

Для каждого агента в разделе Пайплайн:

• Специализация получает от существует в references/
• Специализация передаёт существует
• Форматы входных/выходных данных совместимы
• Если разрыв → пометить ⚠️ разрыв пайплайна

Формат результата валидации

yaml

## Результат валидации
skills_check:
  - skill: web-search → ✅ найден
  - skill: code-review → ⚠️ не найден
routing_conflicts:
  - trigger: "(?i)\bанализ\b" → ⚠️ конфликт с data-analyst
pipeline_check:
  - receives_from: researcher → ✅ референс существует
  - sends_to: publisher → ⚠️ референс не найден
specialization_purity: ✅ один домен / ⚠️ смешение обнаружено

---

Требования к качеству

Specificity (конкретность)

Плохо: "Анализирует данные" Хорошо: "Читает источник полностью перед созданием выжимки, не начинает писать до окончания чтения"

Operationality (операциональность)

Каждый пункт должен быть проверяемым. "Хорошо работает" — нельзя. "Создаёт файл строго по шаблону frontmatter" — можно.

Boundary clarity (чёткость границ)

Раздел "Не делает" должен явно отвечать:

• что часто просят но это не его работа
• к кому идти вместо него

Routing coverage (покрытие триггеров)

Cache seeds должны покрывать все варианты обращения:

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

Specialization purity (чистота специализации)

Все действия в "Делает" относятся к одному домену компетенций. Если действие требует принципиально других навыков — оно не должно быть в этом референсе.

---

Референсные примеры специализаций

Database Administrator (Хранитель базы)

Ключевая особенность: read-before-write, anti-duplicate, strict schema enforcement, mandatory synonyms generation. Модель: claude-3.5-sonnet (строгий schema enforcement).

Kaizen Coach

Ключевая особенность: human-in-the-loop чекины, не исполняет задачи сам, владеет структурой Todoist. Модель: minimax-m2.5 (частые интерактивные диалоги).

Strategist (Стратег)

Ключевая особенность: только zoom-out, не ставит задачи, human always decides, анализирует когерентность доменов. Модель: claude-3.5-sonnet (глубокий системный анализ).

Secretary Operator (Секретарь)

Ключевая особенность: письма только с подтверждением, не меняет структуру проектов, владеет календарём. Модель: gemini-2.5-flash (скорость, частые операции).

---

Полный пайплайн работы скилла

text

ВХОД: запрос на создание референса
          │
          ▼
┌─ Блок описания заполнен? ─┐
│                            │
│ ДА                         │ НЕТ / ЧАСТИЧНО
│                            │
▼                            ▼
Проверка чистоты      Режим интервью
специализации         (Этап 1: базовые вопросы)
│                            │
│                            ▼
│                     Проверка чистоты
│                     специализации
│                     (Этап 2)
│                            │
│                     ┌──────┴──────┐
│                     │             │
│                     │ Смешение    │ Чисто
│                     │ обнаружено  │
│                     │             │
│                     ▼             │
│               Предложить          │
│               разделение          │
│               (ждать ответ)       │
│                     │             │
│                     ▼             │
│               Инициатор           │
│               выбрал вариант      │
│                     │             │
│                     ▼             ▼
│                     Этап 3: углубление
│                            │
│                            ▼
│                     Этап 4: LLM-анализ
│                     (полнота, непротиворечивость,
│                      конкретность, уникальность,
│                      обогащение)
│                            │
│                            ▼
│                     Показать сводку
│                     инициатору
│                     (ждать подтверждение)
│                            │
├────────────────────────────┘
│
▼
Проверка KB:
- Нет дубликатов в references/
- Routing не конфликтует
- Skills существуют
- Пайплайн замкнут
│
▼
Генерация референса по шаблону
│
▼
Внутренний чеклист (все 12+ разделов)
│
▼
Показать результат инициатору
│
▼
Сохранить в OpenClaw KB/references/[specialization].md

---

Шаблон файла

markdown

---
specialization: [specialization-en-kebab-case]
type: reference
lang: ru
status: ready
tags:
  - reference
  - [specialization]
  - [tag2]
  - [tag3]
synonyms:
  - [синоним1]
  - [синоним2]
  - [синоним3]
source: manual
confidence: high
created: [YYYY-MM-DD]
version: 1
---

## Специализация
[Один абзац. Что делает этот тип агента. Без имён. Без лора.
Одна узкая профессия. Один домен компетенций.]

## Ключевые компетенции
- [навык 1 — конкретно и операционально]
- [навык 2]
- [навык 3]
- [навык 4]
- [навык 5]
- [навык 6]

---

## Персонализация — получить от инициатора

При создании агента запрашивается:

| Параметр | Вопрос инициатору | В spec |
|----------|------------------|--------|
| Имя агента | Как зовут? (персонаж GoT или любое) | `name` |
| agent_id | Технический ID (латиница, без пробелов) | `agent_id` |
| Характер | Дополнительные черты поверх базового? | `vibe` |
| target_agent | Кому передаёт результат работы? | в SOUL.md |
| Контекст задачи | Для какого проекта / домена? | в SOUL.md |
| Модель | Какую модель использовать? | `model` |
| Дополнительные задачи | Что добавить поверх базовой специализации? | в SOUL.md |
| [параметр специфичный для профессии] | [вопрос] | [куда] |

Базовый характер специализации (зафиксирован в референсе):
[2-3 черты которые всегда одинаковы для этой специализации]

Примечание: дополнительные задачи расширяют агента за пределы
базового референса. Референс = ядро, агент = ядро + надстройка.

---

## Домен

Фиксированные области работы:
- [область 1]
- [область 2]
- [область 3]

Настраиваемые области (→ уточнить у инициатора):
- Предметная область: [варианты] → от инициатора
- Язык обработки: ru / en / multi → от инициатора
- [другие настраиваемые параметры]

---

## Делает (фиксировано)
- [действие 1 — конкретный глагол]
- [действие 2]
- [действие 3]
- [действие 4]
- [действие 5]
- [действие 6]
- [действие 7]
- [действие 8]

## Не делает (фиксировано)
- [ограничение 1] → вместо этого: [к кому идти]
- [ограничение 2] → вместо этого: [к кому идти]
- [ограничение 3] → вместо этого: [к кому идти]
- [ограничение 4] → вместо этого: [к кому идти]
- [ограничение 5] → вместо этого: [к кому идти]
- [ограничение 6] → вместо этого: [к кому идти]

---

## Skills

Обязательные:
- `[skill-name]` — [зачем нужен конкретно]
- `[skill-name]` — [зачем нужен конкретно]

Опциональные (→ уточнить у инициатора):
- `[skill-name]` — нужен если [условие]
- `[skill-name]` — нужен если [условие]

---

## Routing

Cache seeds (базовые — всегда добавляются):
- [фраза 1]
- [фраза 2]
- [фраза 3]
- [фраза 4]
- [фраза 5]
- [фраза 6]
- [фраза 7]
- [фраза 8]
- [фраза 9]
- [фраза 10]
- [фраза 11]
- [фраза 12]
- [фраза 13]
- [фраза 14]
- [фраза 15]

Cache seeds (дополнительные → от инициатора):
- [тематические seeds под конкретный домен]
- [названия инструментов, платформ, терминов домена]

Regex triggers (high priority):
- `(?i)\b[паттерн1]\b`
- `(?i)\b[паттерн2]\b`
- `(?i)\b[паттерн3]\b`
- `(?i)\b[паттерн4]\b`
- `(?i)\b[паттерн5]\b`
- `(?i)\b[паттерн6]\b`
- `(?i)\b[паттерн7]\b`
- `(?i)\b[паттерн8]\b`

---

## Стандарты работы

### Входящие данные
Что принимает этот тип агента:
- [формат 1]
- [формат 2]
- [формат 3]

### Выходящие данные
Что возвращает:
- [формат ответа 1]
- [формат файла если пишет файлы]

### Формат выходного файла (если применимо)

Имя файла: `[шаблон имени файла]`

```yaml
---
title: "[шаблон заголовка]"
agent: "[agent_id]"
domain: "[домен]"
status: "draft|ready"
version: 1
created: YYYY-MM-DD
updated: YYYY-MM-DD
tags:
  - [tag]
synonyms:
  - [синоним]
confidence: high
---

---

Пайплайн

Типичная позиция в пайплайне

[источник данных] → [этот агент] → [получатель результата]

Взаимодействие с другими агентами

• Получает от: [специализация] через [механизм — сообщение / файл / ACP]
• Передаёт: [специализация] через [механизм]
• Сообщает о завершении: [специализация]

Позиция → от инициатора

target_agent (кому передаёт результат): → уточнить у инициатора

---

Инструкции для агента-архитектора

При создании агента этой специализации обязательно:

• Включить в SOUL.md: [что конкретно — правило или принцип]
• Включить в SOUL.md: [что конкретно]
• Включить в TOOLS.md: [пути, команды, переменные]
• Установить skills: [список через запятую]
• Уточнить у инициатора: [список параметров]
• Спросить про дополнительные задачи поверх базовой специализации

Критические правила специализации:

• [правило 1 — нарушение этого ломает всю работу агента]
• [правило 2 — нарушение создаёт системную проблему]
• [правило 3]

---

Модель по умолчанию

[provider/model-name]

Почему: [1-2 предложения почему эта модель подходит]

Альтернативы:

• [provider/model] — если [условие когда использовать]
• [provider/model] — если [условие]
• [provider/model] — если [условие]

---

Changelog

v1 ([YYYY-MM-DD])

• Первая версия референса
• Источник: [интервью / описание / анализ]

text

---

## Описание новой специализации (заполни перед запуском)

Если блок ниже заполнен — перейди к проверке чистоты
и генерации. Если не заполнен — перейди в режим интервью.

ОПИСАНИЕ СПЕЦИАЛИЗАЦИИ:

Название специализации (ru): [как называется профессия] specialization (en): [kebab-case]

Что делает этот тип агента: [2-5 предложений о сути работы]

Ключевые действия:

• [действие 1]
• [действие 2]
• [действие 3]

Чего не делает (важные границы):

• [ограничение 1]
• [ограничение 2]

С какими агентами взаимодействует:

• Получает данные от: [агент или источник]
• Передаёт результат: [агент или хранилище]

Какие инструменты нужны:

• [skill или tool 1]
• [skill или tool 2]

Периодичность работы: [по запросу / ежедневно / еженедельно / триггерно]

Human-in-the-loop: [где требуется подтверждение человека]

Особые правила (если есть):

• [правило 1]
• [правило 2]

Предпочтительный персонаж GoT (если есть идея): [имя или "на усмотрение"]

text

---

## Чеклист после генерации

Перед финальным выводом проверь:

**Структура:**
- [ ] YAML frontmatter заполнен полностью
- [ ] Все 13 обязательных разделов присутствуют
- [ ] Разделы идут в правильном порядке

**Чистота специализации:**
- [ ] Все действия относятся к одному домену компетенций
- [ ] Нет смешения профессий
- [ ] Убрать одну часть = оставшееся НЕ является отдельной профессией

**Содержание:**
- [ ] Специализация описана без имён и лора
- [ ] Компетенции конкретны и операциональны
- [ ] Таблица персонализации заполнена
- [ ] Базовый характер специализации описан
- [ ] Поле "Дополнительные задачи" присутствует в таблице

**Границы:**
- [ ] "Делает" содержит минимум 8 конкретных действий
- [ ] "Не делает" содержит минимум 6 ограничений
- [ ] В "Не делает" для каждого пункта указано к кому идти

**Skills и Routing:**
- [ ] Skills разделены на обязательные и опциональные
- [ ] Cache seeds минимум 15 фраз
- [ ] Cache seeds покрывают официальный, разговорный и сленг
- [ ] Regex triggers минимум 8 паттернов
- [ ] Есть блок дополнительных seeds от инициатора

**Валидация связей:**
- [ ] Упомянутые skills существуют (или помечены ⚠️)
- [ ] Routing triggers не конфликтуют с другими референсами
- [ ] Пайплайн замкнут — нет разрывов

**Стандарты:**
- [ ] Входящие данные описаны конкретно
- [ ] Выходящие данные описаны конкретно
- [ ] Если агент пишет файлы — есть шаблон frontmatter

**Пайплайн:**
- [ ] Схема пайплайна показана стрелками
- [ ] Все три направления взаимодействия описаны
- [ ] target_agent помечен как → от инициатора

**Инструкции для архитектора:**
- [ ] Чеклист содержит конкретные инструкции
- [ ] Критические правила выделены
- [ ] Критические правила сформулированы как "нарушение ломает X"
- [ ] Есть пункт про дополнительные задачи

**Модель:**
- [ ] Выбрана конкретная модель с обоснованием
- [ ] Есть минимум 2 альтернативы с условиями

**Версионирование:**
- [ ] Раздел Changelog присутствует
- [ ] Первая версия задокументирована

**Общее:**
- [ ] Файл готов к сохранению по пути
  `OpenClaw KB/references/[specialization].md`
- [ ] Файл можно использовать без дополнительных правок
- [ ] Агент-архитектор сможет создать агента только по этому референсу