workflow-ai 1.0.40 → 1.0.42

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,161 +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 — мелкий недочёт |
-
-### 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,168 +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` заполнен и указывает на текущий план?
-- [ ] Задача необходима для критериев успеха текущего плана?
-
-### 5. Назначить приоритеты
-
-| Приоритет | Значение |
-|-----------|----------|
-| 1 | Critical — блокирует всё |
-| 2 | High — важно для прогресса |
-| 3 | Medium — стандартная работа |
-| 4 | Low — можно отложить |
-| 5 | Someday — когда-нибудь |
-
-### 6. Создать тикеты
-
-1. Прочитай шаблон: `.workflow/templates/ticket-template.md`
-2. Для каждого тикета:
-   - Определи следующий 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/execute-task/SKILL.md

@@ -1,161 +0,0 @@
----
-name: execute-task
-description: Выполнить задачу из тикета. Используй когда нужно выполнить конкретный тикет из in-progress. Читает описание задачи, выполняет работу, записывает результат. Перемещение в done/blocked выполняется отдельным stage.
----
-
-# Выполнение задачи
-
-Этот skill выполняет задачу из тикета и записывает результат.
-
-## ⛔ КРИТИЧЕСКИЕ ОГРАНИЧЕНИЯ (прочитай ПЕРЕД выполнением)
-
-**Execute-task — скил ИСПОЛНЕНИЯ. Он НЕ создаёт артефакты workflow.**
-
-При выполнении задачи **КАТЕГОРИЧЕСКИ ЗАПРЕЩЕНО:**
-
-1. **Создавать файлы тикетов** в `.workflow/tickets/` (любая папка: backlog, ready, in-progress)
-2. **Создавать файлы планов** в `.workflow/plans/`
-3. **Вызывать скилы** `decompose-plan`, `decompose-gaps`, `create-plan`
-4. **Интерпретировать DoD буквально**, если DoD содержит «создать тикеты» или «декомпозировать в тикеты» — это рекомендация для следующего плана, а НЕ инструкция к действию
-
-**Если задача требует создания тикетов/планов как deliverable:**
-→ Зафиксируй рекомендации в секции `### Рекомендации для следующего плана` результата тикета
-→ Человек решит, создавать ли следующий план
-
-**Почему:** Без этого ограничения возникает каскад: execute-task создаёт план → decompose-plan создаёт тикеты → backlog разрастается без контроля человека. Это уже происходило дважды.
-
----
-
-## Когда использовать
-
-- Есть тикет в `in-progress/`
-- Нужно выполнить конкретную задачу
-- Перемещение в done/blocked будет выполнено отдельным stage пайплайна
-
-## Шаги выполнения
-
-### 1. Прочитать тикет
-
-**ОБЯЗАТЕЛЬНО:** Используй ТОЛЬКО `ticket_id` из секции Context промпта. Запрещено выбирать другой тикет.
-
-```
-Путь: .workflow/tickets/in-progress/{TICKET-ID}.md
-```
-
-Если тикет не найден в `in-progress/`, проверь `review/` (при повторном выполнении тикет может быть там).
-
-**Важно:** НЕ перемещай тикет. Перемещение выполняется отдельным stage пайплайна.
-
-Извлечь:
-- Описание задачи
-- Критерии готовности (Definition of Done)
-- Контекст (файлы, ссылки, заметки)
-
-### 2. Понять задачу
-
-Убедиться что понятно:
-- Что нужно сделать
-- Какой результат ожидается
-- Какие есть ограничения
-
-Если не хватает информации:
-- Создать подзадачу на уточнение
-- Или вывести `status: blocked` в блоке результата (перемещение выполнит pipeline)
-
-### 3. Выполнить работу
-
-В зависимости от типа задачи:
-
-| Тип | Действия |
-|-----|----------|
-| IMPL | Написать код |
-| FIX | Исправить баг |
-| DOCS | Написать документацию |
-| REVIEW | Проверить код/документы |
-| PLAN | Создать план |
-| ADMIN | Выполнить настройку (см. 3.1) |
-
-#### 3.1. Специальные правила для `type: admin`
-
-Admin-задачи требуют **реального изменения файлов**. Цикл выполнения:
-
-1. **Read** — прочитать все файлы из `context.files` инструментом Read
-2. **Edit/Write** — внести требуемые изменения инструментом Edit или Write
-3. **Verify** — перечитать изменённые файлы для верификации результата
-
-**Запрещено для admin-задач:**
-- Завершать задачу без реального изменения файлов
-- Оставлять секцию «Результат выполнения» пустой или с заглушкой
-- Описывать изменения только в Summary без внесения их в целевые файлы
-
-**Чеклист самопроверки перед завершением admin-задачи:**
-- [ ] Все файлы из `context.files` прочитаны?
-- [ ] Изменения внесены инструментом Edit/Write (не просто описаны)?
-- [ ] Изменённые файлы перечитаны и верифицированы?
-- [ ] Секция «Результат выполнения» содержит конкретный результат (не заглушку)?
-
-### 4. Проверить критерии готовности
-
-Для каждого критерия из Definition of Done:
-- Выполнен ли он?
-- Если нет — что нужно доделать?
-
-### 5. Записать результат
-
-Добавить в тикет секцию Result:
-
-```markdown
-## Result
-
-### Что сделано
-- ...
-
-### Изменённые файлы
-- ...
-
-### Заметки
-- ...
-```
-
-### 6. Перемещение выполняется отдельным stage
-
-**Важно:** Этот skill НЕ перемещает тикет. НЕ выполняй никаких операций с файлами тикетов кроме записи результата.
-
-Запрещено:
-- Перемещать файл тикета в другую папку
-- Обновлять `status` в frontmatter
-- Добавлять `completed_at`
-- Вызывать `move-ticket.js` вручную
-
-Всё это выполняется автоматически скриптом перемещения на следующем stage пайплайна.
-
-### 7. Закрыть внешние ресурсы
-
-Если задача использовала **MCP-browser (Playwright)** — **обязательно** вызови `browser_close` перед выводом результата. Незакрытый браузер блокирует профиль и мешает следующему запуску.
-
-### 8. Вывести структурированный результат
-
-После выполнения **обязательно** выведи блок результата:
-
-```
----RESULT---
-status: default
----RESULT---
-```
-
-## Пример использования
-
-```
-Выполни задачу .workflow/tickets/in-progress/IMPL-001.md
-```
-
-## Результат
-
-- Выполненная работа (код, документация и т.д.)
-- Обновлённый тикет с секцией Result
-- Тикет остаётся на месте (перемещение выполняется отдельным stage)
-
-## Связанные skills
-
-- `check-conditions` — после выполнения проверить зависимые задачи
-- `create-report` — включить результат в отчёт