Skill: rodrigo09313/agent-reference-creator (version 1.0.0)

# 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: Базовое понимание (обязательно) Задай эти вопросы последовательно. Не задавай все сразу. Дождись ответа на каждый перед следующим. ``` 1. "Какую проблему решает этот тип агента? Что сейчас не делается или делается плохо?" 2. "Что этот агент делает каждый день? Перечисли 3-5 конкретных действий." 3. "Что этот агент точно НЕ должен делать? Что часто путают с его работой?" 4. "Откуда он получает задачи или материалы? От человека, от другого агента, из файлов?" 5. "Кому он передаёт результат? Другому агенту, человеку, в хранилище?" ``` ### Этап 2: Проверка чистоты специализации (обязательно) После получения ответов на этап 1 — выполни анализ: ``` Внутренний анализ (не показывай пользователю): 1. Выпиши все действия которые назвал инициатор 2. Сгруппируй по доменам компетенций 3. Если групп больше одной — это потенциальное смешение Критерии разделения: - Действия требуют РАЗНЫХ базовых навыков? (код vs визуал, текст vs данные, стратегия vs исполнение) - Действия можно выполнять НЕЗАВИСИМО друг от друга? - На рынке труда это РАЗНЫЕ должности? Если 2+ из 3 критериев = да → предложи разделение. ``` Если обнаружено смешение, сообщи инициатору: ``` "Вижу что в описании смешиваются несколько специализаций: 1. [Специализация A]: [действия из группы A] 2. [Специализация B]: [действия из группы B] Референс должен описывать одну узкую профессию. При создании конкретного агента ему можно будет добавить дополнительные задачи поверх базовой специализации. Предлагаю: - Вариант 1: Создать два отдельных референса - Вариант 2: Выбрать основную специализацию, остальное пойдёт как дополнительные задачи при создании агента Какой вариант выбираешь?" ``` Не продолжай пока инициатор не выберет вариант. ### Этап 3: Углубление (после подтверждения чистоты) ``` 6. "Какой формат результата? Файл, сообщение, отчёт? Есть ли шаблон?" 7. "Нужны ли внешние инструменты? API, базы данных, файловая система?" 8. "Где требуется подтверждение человека? Что агент может делать сам, а что — только с одобрения?" 9. "Как часто выполняется работа? По запросу, ежедневно, по триггеру?" 10. "Есть ли похожая специализация в системе от которой нужно чётко отличаться?" ``` ### Этап 4: Валидация и обогащение через LLM После сбора всех ответов — выполни внутренний анализ: ``` Внутренний анализ (выполни перед генерацией): 1. ПОЛНОТА: Все ли аспекты профессии покрыты? Проверь стандартный набор: - Входные данные ✓/✗ - Процесс обработки ✓/✗ - Выходные данные ✓/✗ - Инструменты ✓/✗ - Границы ✓/✗ - Взаимодействие с другими ✓/✗ - Стандарты качества ✓/✗ 2. НЕПРОТИВОРЕЧИВОСТЬ: Нет ли конфликтов? - "Делает" не противоречит "Не делает" - Skills соответствуют действиям - Входные/выходные форматы совместимы с пайплайном 3. КОНКРЕТНОСТЬ: Каждое действие проверяемо? Замени размытые формулировки на операциональные: - "Хорошо анализирует" → "Извлекает ключевые тезисы и структурирует по категориям" - "Помогает с кодом" → "Проводит code review, указывает на баги и предлагает исправления" 4. УНИКАЛЬНОСТЬ: Не дублирует существующие референсы? Сравни с каждым файлом в references/: - Пересечение действий <30% - Routing triggers не конфликтуют - Домены не перекрываются 5. ОБОГАЩЕНИЕ: Что инициатор мог забыть упомянуть? На основе знаний о профессии добавь: - Стандартные ограничения этой специализации - Типичные ошибки которые надо предотвратить - Общепринятые стандарты качества в этой области Добавленное пометь как "[предложено — подтвердить]" ``` После анализа покажи инициатору сводку: ``` "На основе интервью сформировал профиль специализации: Специализация: [название] Ядро: [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 Обязательный раздел в конце файла: ``` ### v1 (YYYY-MM-DD) - Первая версия референса - Источник: [интервью / описание / анализ] ``` --- ## Антипаттерны ### ❌ Размытая специализация ``` # ПЛОХО ## Специализация Агент который помогает с разными задачами и анализирует информацию. ``` Почему плохо: непонятно чем отличается от любого другого агента. Нет границ, нет конкретики, невозможно маршрутизировать. ``` # ХОРОШО ## Специализация Извлекает структурированные данные из неструктурированных источников (статьи, транскрипты, документы), создаёт выжимки в формате frontmatter-файлов KB. Не интерпретирует данные — только извлекает и форматирует. ``` ### ❌ Личность вместо профессии ``` # ПЛОХО ## Делает - Внимательно читает каждый документ - Никогда не торопится - Любит порядок в файлах ``` Почему плохо: описывает конкретного агента, а не специализацию. ``` # ХОРОШО ## Делает - Читает источник полностью перед созданием выжимки - Не начинает генерацию до завершения анализа входных данных - Валидирует структуру выходного файла перед сохранением ``` ### ❌ Смешение специализаций ``` # ПЛОХО ## Делает - Пишет код на Python - Рисует макеты интерфейсов - Проводит пользовательские интервью - Настраивает CI/CD пайплайн ``` Почему плохо: четыре разных профессии в одном референсе. Developer, UI Designer, UX Researcher, DevOps. ``` # ХОРОШО — только developer ## Делает - Пишет код на Python по техническому заданию - Рефакторит существующий код - Пишет unit-тесты для нового кода - Проводит code review ``` ### ❌ Пересечение границ ``` # ПЛОХО — референс аналитика ## Делает - Анализирует данные - Ставит задачи по результатам анализа ← работа менеджера - Пишет код для обработки данных ← работа разработчика - Отправляет отчёт клиенту ← работа секретаря ``` Почему плохо: один агент залезает в зоны других. ### ❌ Непроверяемые стандарты ``` # ПЛОХО ## Стандарты работы - Делает качественные выжимки - Работает быстро и аккуратно - Хорошо понимает контекст ``` Почему плохо: нельзя проверить. ``` # ХОРОШО ## Стандарты работы - Выжимка содержит все поля frontmatter без пропусков - Synonyms минимум 3 варианта для каждой сущности - Файл проходит YAML-валидацию без ошибок ``` ### ❌ Пустой routing ``` # ПЛОХО ## 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 ``` ## 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 (скорость, частые операции). --- ## Полный пайплайн работы скилла ``` ВХОД: запрос на создание референса │ ▼ ┌─ Блок описания заполнен? ─┐ │ │ │ ДА │ НЕТ / ЧАСТИЧНО │ │ ▼ ▼ Проверка чистоты Режим интервью специализации (Этап 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]) - Первая версия референса - Источник: [интервью / описание / анализ] ``` --- ## Описание новой специализации (заполни перед запуском) Если блок ниже заполнен — перейди к проверке чистоты и генерации. Если не заполнен — перейди в режим интервью. ``` ОПИСАНИЕ СПЕЦИАЛИЗАЦИИ: Название специализации (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 (если есть идея): [имя или "на усмотрение"] ``` --- ## Чеклист после генерации Перед финальным выводом проверь: **Структура:** - [ ] 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` - [ ] Файл можно использовать без дополнительных правок - [ ] Агент-архитектор сможет создать агента только по этому референсу


Security scan verdicts — ClawScan: clean | static analysis: clean | VirusTotal: clean | SkillSpector: clean (LOW)