workflow-ai 1.0.41 → 1.0.43

package/src/skills/create-report/SKILL.md

@@ -1,156 +0,0 @@
----
-name: create-report
-description: Сформировать отчёт о выполненных задачах. Используй по завершении итерации для документирования прогресса. Собирает информацию из done/ тикетов и создаёт отчёт в .workflow/reports/.
----
-
-# Создание отчёта
-
-Этот skill формирует отчёт о выполненных задачах на основе завершённых тикетов.
-
-## Когда использовать
-
-- Завершилась итерация работ
-- Накопились выполненные задачи в done/
-- Нужно зафиксировать прогресс
-- Перед принятием решений о следующих шагах
-
-## Шаги выполнения
-
-### 1. Собрать информацию
-
-Прочитать все тикеты из:
-- `.workflow/tickets/done/` — выполненные
-- `.workflow/tickets/blocked/` — заблокированные
-- `.workflow/tickets/in-progress/` — в работе
-
-### 1.5. Проверка аномалий: in-progress тикеты с заполненным результатом
-
-**Важно:** Перед формированием отчёта проверить in-progress тикеты на наличие заполненных результатов.
-
-**Автоматическая проверка (рекомендуется):**
-
-Использовать скрипт `.workflow/src/scripts/check-anomalies.js`:
-
-```bash
-node .workflow/src/scripts/check-anomalies.js
-```
-
-Скрипт выводит результат в формате:
-```
----RESULT---
-status: ok|anomalies_found|error
-anomalies_count: N
-anomalies: [{"id": "IMPL-001", "title": "...", "recommendation": "..."}]
----RESULT---
-```
-
-**Ручная проверка (если скрипт недоступен):**
-
-Для каждого тикета в `.workflow/tickets/in-progress/`:
-1. Прочитать содержимое файла
-2. Найти раздел `## Результат выполнения` (или `## Result`)
-3. Проверить подраздел `### Summary` (или `### Что сделано`)
-4. Если подраздел содержит непустой текст (не только `<!-- ... -->` комментарии) — это аномалия
-
-**Критерии заполнения:**
-- Раздел содержит текст, отличный от шаблонов `<!-- ... -->`
-- Есть конкретное описание выполненной работы
-- Указаны изменённые файлы или конкретные результаты
-
-**Действия при обнаружении аномалии:**
-- Добавить тикет в секцию "Аномалии" отчёта
-- Указать рекомендацию: "Проверьте тикет и переместите в done/ или review/ если выполнен"
-
-### 2. Определить период
-
-```
-Период: от последнего отчёта до сейчас
-
-Если отчётов нет — от создания первого тикета
-```
-
-### 3. Для каждой выполненной задачи
-
-Извлечь:
-- ID и название
-- Время выполнения (created_at → completed_at)
-- Результат (из секции Result)
-- Проблемы (если были)
-
-### 4. Сформировать статистику
-
-```
-Выполнено: N задач
-В работе: M задач
-Заблокировано: K задач
-В очереди: L задач
-
-По типам:
-- IMPL: X
-- FIX: Y
-- DOCS: Z
-```
-
-### 5. Выделить проблемы и аномалии
-
-**Проблемы:**
-
-Для каждой заблокированной задачи:
-- Причина блокировки
-- Как разблокировать
-
-Для задач с problems:
-- Описание проблемы
-- Как была решена
-
-**Аномалии:**
-
-Если на шаге 1.5 найдены in-progress тикеты с заполненным результатом:
-- Создать подсекцию "Аномалии"
-- Для каждого тикета указать:
-  - ID и название
-  - Рекомендацию: "Проверьте тикет и переместите в done/ или review/ если выполнен"
-
-### 6. Связать с планом
-
-Если есть активный план:
-- Какой процент выполнен
-- Какие задачи из плана закрыты
-- Что осталось
-
-### 7. Сохранить отчёт
-
-1. Прочитай шаблон: `.workflow/templates/report-template.md`
-2. Определи следующий ID: найди все файлы `REPORT-*.md` в `.workflow/reports/`, возьми максимальный номер и прибавь 1. Если файлов нет — начни с `REPORT-001`.
-3. Сохрани в: `.workflow/reports/REPORT-{NNN}.md`
-
-### 8. Вывести структурированный результат
-
-После сохранения **обязательно** выведи блок результата:
-
-```
----RESULT---
-status: default
-report_id: REPORT-001
----RESULT---
-```
-
-## Пример использования
-
-```
-Создай отчёт о выполненных задачах за последнюю неделю.
-```
-
-## Результат
-
-Файл `.workflow/reports/REPORT-001.md` содержащий:
-- Период отчёта
-- Список выполненных задач с результатами
-- Статистику
-- Проблемы и их решения
-- Прогресс по плану
-
-## Связанные skills
-
-- `analyze-report` — анализ отчёта
-- `create-plan` — создание плана на основе выводов

package/src/skills/decompose-gaps/SKILL.md

@@ -1,167 +0,0 @@
----
-name: decompose-gaps
-description: Декомпозировать недочёты (gaps) из анализа отчёта в новые тикеты. Используй после analyze-report когда план выполнен не полностью. Создаёт тикеты в .workflow/tickets/backlog/ на основе выявленных пробелов, а не на основе исходного плана.
----
-
-# Декомпозиция недочётов в тикеты
-
-Этот skill создаёт новые тикеты на основе **недочётов (gaps)**, выявленных при анализе отчёта. В отличие от `decompose-plan`, он работает не с исходным планом, а с конкретными пробелами — что не было сделано, что сделано некорректно, что требует доработки.
-
-## Когда использовать
-
-- Анализ отчёта выявил пробелы (`status: has_gaps`)
-- Нужно создать точечные задачи на доработку
-- Требуется закрыть конкретные недочёты, а не декомпозировать весь план заново
-
-## Входные данные (из context)
-
-| Параметр | Описание |
-|----------|----------|
-| `gaps` | Описание недочётов из analyze-report |
-| `report_id` | ID отчёта, в котором выявлены недочёты |
-| `plan_id` | ID исходного плана (для ссылки) |
-
-## Шаги выполнения
-
-### 1. Прочитать описание недочётов
-
-Из context-переменной `gaps` извлечь:
-- Какие задачи не были выполнены
-- Какие результаты не соответствуют ожиданиям
-- Какие доработки требуются
-
-### 2. Прочитать отчёт для полного контекста
-
-```
-Путь: .workflow/reports/REPORT-{report_id}.md
-```
-
-Извлечь:
-- Что было выполнено (для понимания текущего состояния)
-- Какие проблемы возникли
-- Какие файлы были затронуты
-
-### 3. Прочитать исходный план (опционально)
-
-```
-Путь: .workflow/plans/current/PLAN-{plan_id}.md
-```
-
-Сверить gaps с исходными требованиями плана, чтобы понять:
-- Задача была пропущена или выполнена некорректно?
-- Нужна доработка или переделка?
-
-### 3.5. Проверить scope каждого gap
-
-**ОБЯЗАТЕЛЬНО** перед созданием тикетов выполнить три проверки:
-
-#### Проверка 1: Источник gap
-
-Gap — это исключительно то, что **не выполнено или выполнено некорректно** из явного списка задач плана. Источник gap — только эти секции отчёта:
-- «Выполненные задачи» — задачи со статусом failed/skipped где DoD не выполнен
-- «Заблокированные задачи» — задачи, заблокированные по техническим причинам (не по внешним зависимостям)
-- «Риски и проблемы» — только конкретные сбои в выполненных задачах
-
-**НЕ являются источником gaps следующие секции отчёта:**
-- «Рекомендации для Architect» — это советы, не пробелы
-- «План на следующий период» — это новые инициативы, не пробелы
-- «Потенциальные риски» — это гипотезы, не пробелы
-- Любые упоминания будущих задач (GML-005, стратегия, следующий этап и т.п.)
-
-#### Проверка 2: Принадлежность к scope исходного плана
-
-**Gap в scope (создавать тикет):**
-- Задача была в исходном плане, но не выполнена или выполнена некорректно
-- Доработка существующего результата, который не соответствует DoD плана
-- Исправление ошибки в уже сделанной работе по плану
-
-**Gap вне scope (НЕ создавать тикет):**
-- Новая работа, которой не было в исходном плане
-- Расширение scope за рамки первоначальных требований
-- Задачи, созданные другими тикетами как часть их DoD (например, quick win тикеты созданные GML-004 — это deliverables, не gaps)
-- Задачи из секций «Рекомендации», «План на следующий период», «Следующие шаги»
-
-#### Проверка 3: Статус плана
-
-Если план завершён (`status: completed`) или все его ключевые задачи выполнены — decompose-gaps **не создаёт тикеты**. Gaps в завершённом плане = новые инициативы для следующего плана.
-
-**Для gap вне scope:** НЕ создавать тикет. Вместо этого записать в секцию «Новые требования» в результате выполнения:
-
-```markdown
-### Новые требования (вне scope плана)
-- [описание gap] — причина: [почему это вне scope]
-```
-
-Эти требования будут рассмотрены при создании следующего плана.
-
-### 4. Для каждого gap создать тикет
-
-Каждый gap → 1 или несколько тикетов.
-
-Критерии хорошего тикета на доработку:
-- **Точечный** — исправляет конкретный недочёт, а не переделывает всё
-- **Атомарный** — одна конкретная работа
-- **С контекстом** — ссылается на отчёт и исходную задачу
-- **Выполнимый** — понятно что делать без дополнительных вопросов
-
-### 5. Определить тип каждого тикета
-
-Прочитай актуальные типы задач из `.workflow/config/config.yaml` (секция `task_types`). Используй **только** префиксы, определённые в конфиге. Не используй типы, которых нет в конфиге.
-
-### 6. Назначить приоритеты
-
-Приоритеты для тикетов-доработок обычно выше, чем для обычных задач:
-
-| Приоритет | Значение |
-|-----------|----------|
-| 1 | Critical — блокирует завершение плана |
-| 2 | High — важный пробел |
-| 3 | Medium — мелкий недочёт |
-
-### 6.5. Пути для output-артефактов
-
-**⛔ ВАЖНО:** Артефакты НИКОГДА не складываются в `.workflow/`. Директория `.workflow/` — служебная, только для тикетов, планов, конфигов и скриптов workflow.
-
-Output-артефакты сохраняются в **корневой** директории. При указании `output` в тикете используй путь от корня репо, а не `.workflow/...`.
-
-### 7. Создать тикеты
-
-1. Прочитай шаблон: `.workflow/templates/ticket-template.md`
-2. Для каждого тикета:
-   - Определи следующий ID: найди все файлы `{TYPE}-*.md` во всех папках `.workflow/tickets/`, возьми максимальный номер для этого префикса и прибавь 1. Если файлов нет — начни с `{TYPE}-001`.
-   - Заполни шаблон
-   - **Если доработка относится к плану** — заполни `parent_plan: "plans/current/PLAN-{plan_id}.md"`. Это обязательно, если `plan_id` передан в context.
-   - В описании укажи: `Доработка по результатам REPORT-{report_id}`
-   - Сохрани в `.workflow/tickets/backlog/{TYPE}-{NNN}.md`
-
-### 8. Вывести структурированный результат
-
-После создания тикетов **обязательно** выведи блок результата:
-
-```
----RESULT---
-status: default
-created_tickets: IMPL-010, FIX-011
----RESULT---
-```
-
-## Пример использования
-
-```
-Декомпозируй недочёты в новые тикеты.
-
-Context:
-  gaps: Не реализована валидация входных данных; отсутствует обработка ошибок в runner.mjs
-  report_id: REPORT-003
-  plan_id: PLAN-006
-```
-
-## Результат
-
-- Новые тикеты в `.workflow/tickets/backlog/`
-
-## Связанные skills
-
-- `analyze-report` — предшествующий шаг, выявляет gaps
-- `check-conditions` — следующий шаг, проверяет готовность новых тикетов
-- `decompose-plan` — похожий skill, но для декомпозиции всего плана

package/src/skills/decompose-plan/SKILL.md

@@ -1,219 +0,0 @@
----
-name: decompose-plan
-description: Декомпозировать план на исполняемые тикеты. Используй после создания плана для разбиения высокоуровневых задач на конкретные тикеты с зависимостями и условиями. Создаёт тикеты в .workflow/tickets/backlog/.
----
-
-# Декомпозиция плана на тикеты
-
-Этот skill разбивает высокоуровневый план на исполняемые тикеты для канбан-доски.
-
-## Когда использовать
-
-- Создан новый план
-- Нужно разбить крупную задачу на подзадачи
-- Требуется детальная декомпозиция
-
-## ⛔ Какой план декомпозировать
-
-Декомпозируй план, указанный в секции Instructions твоего промпта. Открой этот файл и сразу переходи к шагу 1. Не сканируй папку plans/current/. Не проверяй статус плана. Не читай другие планы.
-
-## Шаги выполнения
-
-### 1. Прочитать план
-
-```
-Путь: .workflow/plans/current/PLAN-{NNN}.md
-```
-
-Извлечь:
-- Список высокоуровневых задач
-- Зависимости между ними
-- Приоритеты
-- Контекст проекта
-
-### 2. Для каждой задачи определить тикеты
-
-Каждая задача из плана может превратиться в 1+ тикетов.
-
-Критерии хорошего тикета:
-- Атомарный (одна конкретная работа)
-- Выполнимый за 1-4 часа
-- Имеет чёткие критерии готовности
-- Понятно что делать без дополнительных вопросов
-
-### 2.5. Оценить автономность каждой задачи
-
-Для каждой задачи из плана определи: **может ли агент выполнить её полностью автономно?**
-
-| Категория | Критерий | Действие |
-|-----------|----------|----------|
-| **Полностью автономная** | Агент может выполнить все шаги без участия человека (написание кода, документации, анализ данных через WebSearch/WebFetch) | Создать 1 тикет с `executor_type: agent` |
-| **Полностью ручная** | Требует действий, недоступных агенту (доступ к приватным аккаунтам, физические действия, аутентифицированные сервисы) | Создать 1 тикет `type: human` с `executor_type: human` и явными инструкциями для человека |
-| **Гибридная** | Часть работы может сделать агент, часть — только человек | Разбить на 2 тикета: (a) агентский тикет с `executor_type: agent` и (b) HUMAN-тикет с `executor_type: human`, с зависимостью между ними |
-
-**Для HUMAN-тикетов обязательно:**
-- Явные пошаговые инструкции что именно должен сделать человек
-- DoD-критерий: «Результаты внесены непосредственно в файл тикета»
-- Указание в каком формате ожидается результат
-
-**⛔ НЕ создавать conditional/fallback HUMAN-тикеты заранее.**
-Если HUMAN-тикет нужен только при провале агентского тикета (например, «выполнить вручную, если агент не смог пройти auth») — **не создавай его на этапе декомпозиции**. Такие тикеты создаёт `decompose-gaps` когда проблема реально возникла. Иначе они висят в backlog вечно и засоряют доску.
-
-**Пример разбиения гибридной задачи:**
-
-Задача из плана: «Провести конкурентный анализ и настроить трекинг конкурентов в аналитике»
-
-→ Тикет 1 (agent): `PMA-005` — Провести конкурентный анализ через публичные источники (WebSearch: цены, позиционирование, отзывы, ASO). `executor_type: agent`
-
-→ Тикет 2 (human): `HUMAN-010` — Настроить трекинг конкурентов в SimilarWeb Pro (требует auth). `executor_type: human`, `dependencies: [PMA-005]`. Инструкции: «1. Войти в SimilarWeb Pro. 2. Добавить домены конкурентов из PMA-005. 3. Настроить еженедельный отчёт. 4. Вставить ссылку на дашборд в результат тикета.»
-
-### 3. Определить тип каждого тикета
-
-Прочитай актуальные типы задач из `.workflow/config/config.yaml` (секция `task_types`). Используй **только** префиксы, определённые в конфиге. Не используй типы, которых нет в конфиге.
-
-### 4. Определить зависимости
-
-Для каждого тикета:
-- От каких тикетов зависит (`dependencies`)
-- Какие условия должны быть выполнены (`conditions`)
-
-Типы условий:
-- `tasks_completed: [IMPL-001, IMPL-002]` — задачи должны быть выполнены
-- `date_after: "2024-01-15"` — не раньше даты
-- `file_exists: "src/config.py"` — файл должен существовать
-- `manual_approval: true` — требуется одобрение человека
-
-### 4.5. Scope-guard: проверка принадлежности к плану
-
-**ОБЯЗАТЕЛЬНО** перед созданием каждого тикета выполнить проверку scope.
-
-#### Правило: тикеты создаются ТОЛЬКО на работу внутри scope плана
-
-Прочитай секции плана «Scope (Границы)» → «Включено в scope» и «Исключено из scope». Каждый создаваемый тикет **должен** относиться к работе из «Включено в scope».
-
-**Тикет в scope (создавать):**
-- Задача явно описана в высокоуровневых задачах плана
-- Задача является декомпозицией конкретного пункта плана
-- Задача необходима для достижения критериев успеха плана
-
-**Тикет вне scope (НЕ создавать):**
-- Задача относится к работе из «Исключено из scope»
-- Задача является follow-up после завершения плана (стратегия, запуск кампаний и т.д.)
-- Задача появляется из DoD другого тикета как «создать тикеты для команды» — это рекомендация для следующего плана, а не тикет текущего
-- Задача с условием `date_after` за пределами горизонта текущего плана
-
-**Для работы вне scope:** НЕ создавать тикет. Вместо этого записать в секцию «Рекомендации для следующего плана» в результате выполнения:
-
-```markdown
-### Рекомендации для следующего плана (вне scope)
-- [описание задачи] — причина: [почему это следующий этап]
-```
-
-Эти рекомендации будут учтены при создании следующего плана.
-
-#### Чеклист самопроверки перед созданием тикета
-
-- [ ] Задача входит в «Включено в scope» плана?
-- [ ] Задача НЕ входит в «Исключено из scope»?
-- [ ] `parent_plan` заполнен и указывает на текущий план?
-- [ ] Задача необходима для критериев успеха текущего плана?
-
-### 4.6. Дедупликация: проверка на существующие тикеты
-
-**ОБЯЗАТЕЛЬНО** перед созданием каждого тикета выполнить проверку на дубли.
-
-#### Алгоритм
-
-1. Перед созданием каждого тикета — сканировать **ВСЕ** папки `tickets/` (`backlog/`, `ready/`, `in-progress/`, `blocked/`, `review/`, `done/`)
-2. Найти тикеты с тем же префиксом типа (например, все `PMA-*.md` если создаёшь PMA-тикет)
-3. Сравнить `title` и scope создаваемого тикета с существующими
-4. Если совпадение >70% по title/scope → **НЕ создавать** тикет
-
-#### Чеклист самопроверки перед созданием
-
-- [ ] Нет тикета с таким же или очень похожим title?
-- [ ] Нет тикета с пересекающимся scope работы?
-- [ ] Если тикет в `done/` — нужна ли реально повторная работа или результат уже есть?
-
-#### Override: когда дубль допустим
-
-Если дедупликация блокирует создание тикета, но работа реально нужна (например, предыдущий тикет failed или результат устарел) — создать с пометкой:
-
-```yaml
-notes: "Повторная работа, предыдущий: {ID} — причина: {причина}"
-```
-
-### 5. Назначить приоритеты
-
-| Приоритет | Значение |
-|-----------|----------|
-| 1 | Critical — блокирует всё |
-| 2 | High — важно для прогресса |
-| 3 | Medium — стандартная работа |
-| 4 | Low — можно отложить |
-| 5 | Someday — когда-нибудь |
-
-### 5.5. Пути для output-артефактов
-
-**⛔ ВАЖНО:** Артефакты (отчёты, аналитика, спеки, исследования) НИКОГДА не складываются в `.workflow/`. Директория `.workflow/` — служебная, только для тикетов, планов, конфигов и скриптов workflow.
-
-Output-артефакты тикетов сохраняются в **корневой** директории.
-
-При указании `output` в тикете используй путь от корня репо, а не `.workflow/...`.
-
-### 5.6. Соответствие ID тикетов плану
-
-**Если план явно указывает ID тикетов** (например `Тикет: PMA-015`) — **используй именно эти ID**. Не назначай автоинкрементные номера, если план уже задал конкретные. Расхождение ID между планом и тикетами создаёт путаницу при отслеживании прогресса.
-
-**Если план НЕ указывает ID** — используй автоинкремент (шаг 6).
-
-### 5.8. Не указывай инструменты исполнителя в тикете
-
-**⛔ ВАЖНО:** Тикет описывает **что** нужно сделать и **какой результат** ожидается. Тикет **НЕ указывает** конкретные инструменты или методы сбора данных (WebSearch, WebFetch, Playwright и т.д.) — это зона ответственности SKILL.md исполнителя.
-
-Каждый скил имеет свои предписанные инструменты (например, RSH использует `perplexity-research.js`, PMA — Playwright MCP-browser). Если тикет явно указывает другой инструмент — агент следует тикету и нарушает свой workflow.
-
-**Исключение:** `required_capabilities` в frontmatter (например `browser_automation`, `web_research`) — это допустимо, так как описывает **возможность**, а не конкретный инструмент.
-
-### 5.7. Создание ВСЕХ тикетов плана
-
-**ОБЯЗАТЕЛЬНО** создай тикеты для **ВСЕХ** задач плана, включая отложенные фазы (с `date_after` или сложными `conditions`). Если задача запланирована — тикет должен быть создан в `backlog/` с соответствующими условиями. Непокрытые задачи будут забыты.
-
-### 6. Создать тикеты
-
-1. Прочитай шаблон: `.workflow/templates/ticket-template.md`
-2. Для каждого тикета:
-   - Определи ID: если план указал конкретный ID → используй его. Иначе → найди все файлы `{TYPE}-*.md` во всех папках `.workflow/tickets/`, возьми максимальный номер для этого префикса и прибавь 1. Если файлов нет — начни с `{TYPE}-001`.
-   - Заполни шаблон
-   - **Обязательно** заполни `parent_plan: "plans/current/PLAN-{NNN}.md"` — путь к плану, из которого создан тикет
-   - Сохрани в `.workflow/tickets/backlog/{TYPE}-{NNN}.md`
-
-### 7. Обновить план
-
-Добавь в план ссылки на созданные тикеты.
-
-### 8. Вывести структурированный результат
-
-После создания тикетов **обязательно** выведи блок результата:
-
-```
----RESULT---
-status: default
----RESULT---
-```
-
-## Пример использования
-
-```
-Декомпозируй план .workflow/plans/current/PLAN-001.md на тикеты.
-```
-
-## Результат
-
-- Тикеты в `.workflow/tickets/backlog/`
-- Обновлённый план с ссылками на тикеты
-
-## Связанные skills
-
-- `create-plan` — создание плана для декомпозиции
-- `check-conditions` — проверка готовности тикетов

package/src/skills/deep-research/README.md

@@ -1,50 +0,0 @@
-# Deep Research — Agent Skill
-
-Агент-исследователь для глубокого анализа тем. Получает задачи на исследование от других скилов и формирует структурированные текстовые отчёты с данными, источниками и выводами.
-
-## Структура
-
-```
-deep-research/
-├── SKILL.md                          # Ядро: роль, маршрутизация, принципы
-├── README.md                         # Документация
-├── workflows/
-│   ├── market.md                     # Исследование рынка
-│   ├── competitor.md                 # Анализ конкурентов
-│   ├── trend.md                      # Исследование трендов
-│   ├── benchmark.md                  # Сбор бенчмарков
-│   ├── technology.md                 # Обзор технологий
-│   └── custom.md                     # Кастомное исследование
-├── knowledge/
-│   ├── research-methodology.md       # Методология исследований
-│   ├── source-evaluation.md          # Оценка надёжности источников
-│   └── data-validation.md            # Валидация данных
-├── algorithms/
-│   ├── source-scoring.md             # Скоринг источников (1-10)
-│   └── synthesis.md                  # Синтез выводов
-└── templates/
-    ├── research-report.md            # Полный исследовательский отчёт
-    └── brief-summary.md              # Краткая справка
-```
-
-## Как это работает
-
-1. Другой скил (GML, PMA, Coach, etc.) создаёт тикет `RSH-*` с исследовательским вопросом
-2. Deep Research определяет тип (MARKET/COMPETITOR/TREND/BENCHMARK/TECHNOLOGY/CUSTOM)
-3. Загружает соответствующий workflow
-4. Проводит исследование: поиск → фильтрация → анализ → синтез
-5. Формирует отчёт с источниками, уровнями уверенности, выводами
-
-## Как расширять
-
-### Новый тип исследования
-1. Создай файл в `workflows/{type}.md`
-2. Добавь запись в таблицу маршрутизации в `SKILL.md`
-
-### Новый knowledge-модуль
-1. Создай файл в `knowledge/{module}.md`
-2. Добавь запись в таблицу загрузки знаний в `SKILL.md`
-
-### Новый шаблон вывода
-1. Создай файл в `templates/{template}.md`
-2. Добавь запись в таблицу шаблонов в `SKILL.md`