workflow-ai 1.0.62 → 1.0.64

package/src/skills/coach/workflows/improve.md

@@ -0,0 +1,71 @@
+# Воркфлоу: IMPROVE — Точечное улучшение скила
+
+Внесение конкретных улучшений в существующий скил на основе аудита, анализа или запроса.
+
+## Алгоритм выполнения
+
+### 1. Определи scope улучшения
+
+Из тикета извлеки:
+- Какой скил улучшаем?
+- Какая конкретная проблема или потребность?
+- Есть ли ссылка на аудит/анализ с рекомендациями?
+
+### 2. Изучи текущее состояние
+
+Прочитай файлы скила, которые затрагивает улучшение. Пойми текущую логику прежде чем менять.
+
+### 3. Определи тип улучшения
+
+| Тип | Действие |
+|-----|----------|
+| **Новый воркфлоу** | Создай `workflows/new-type.md`, добавь в маршрутизацию SKILL.md |
+| **Новые знания** | Создай/дополни файл в `knowledge/`, добавь в таблицу загрузки |
+| **Новый алгоритм** | Создай `algorithms/new-algo.md`, добавь в таблицу загрузки |
+| **Новый шаблон** | Создай `templates/new-template.md`, укажи в воркфлоу |
+| **Уточнение воркфлоу** | Добавь/исправь шаги в существующем воркфлоу |
+| **Обогащение knowledge** | Дополни существующий файл в knowledge/ после маркера расширения |
+| **Рефакторинг** | Реструктуризация без изменения поведения |
+
+### 4. Исследование (если нужно)
+
+Если улучшение требует новых знаний:
+- Поищи в интернете лучшие практики, фреймворки, методологии
+- Адаптируй найденное под формат knowledge/ или algorithms/
+- Укажи источник
+
+### 5. Внесение изменений
+
+- Следуй принципу минимальных изменений
+- Не ломай существующие ссылки и интеграции
+- Добавляй, а не переписывай (если не рефакторинг)
+- Обнови README.md если структура изменилась
+
+### 6. Валидация
+
+- Проверь все ссылки из SKILL.md
+- Убедись что новые файлы упомянуты в таблицах загрузки
+- Проверь консистентность терминологии
+
+### 7. Документирование
+
+Сформируй план улучшений → `templates/improvement-plan.md` с:
+- Что изменено и почему
+- Какие файлы затронуты
+- Ожидаемый эффект
+- Как проверить результат
+
+### 8. Создание теста → `workflows/test.md`
+
+Выполни воркфлоу `workflows/test.md` для скила, который был улучшен:
+- Создай регрессионный тест-кейс, фиксирующий улучшение
+- Прогони runner и получи verdict
+
+### 9. Сообщить пользователю verdict и список затронутых файлов
+
+Сообщи пользователю:
+
+- **Verdict** runner'а из шага 8.
+- **Список затронутых файлов:** `SKILL.md` и/или `workflows/`, `tests/cases/{id}.yaml`, `tests/index.yaml`, `tests/cases/{id}/current/`
+
+**Остановиться.** Коуч не делает ничего сверх этого — коммит на стороне пользователя.

package/src/skills/coach/workflows/improve.md.legacy

@@ -0,0 +1,60 @@
+# Воркфлоу: IMPROVE — Точечное улучшение скила
+
+Внесение конкретных улучшений в существующий скил на основе аудита, анализа или запроса.
+
+## Алгоритм выполнения
+
+### 0. Бэклог → SKILL.md «Обязательный шаг: Бэклог коуча». Не вноси повторно правки из `applied_changes`.
+
+### 1. Определи scope улучшения
+
+Из тикета извлеки:
+- Какой скил улучшаем?
+- Какая конкретная проблема или потребность?
+- Есть ли ссылка на аудит/анализ с рекомендациями?
+
+### 2. Изучи текущее состояние
+
+Прочитай файлы скила, которые затрагивает улучшение. Пойми текущую логику прежде чем менять.
+
+### 3. Определи тип улучшения
+
+| Тип | Действие |
+|-----|----------|
+| **Новый воркфлоу** | Создай `workflows/new-type.md`, добавь в маршрутизацию SKILL.md |
+| **Новые знания** | Создай/дополни файл в `knowledge/`, добавь в таблицу загрузки |
+| **Новый алгоритм** | Создай `algorithms/new-algo.md`, добавь в таблицу загрузки |
+| **Новый шаблон** | Создай `templates/new-template.md`, укажи в воркфлоу |
+| **Уточнение воркфлоу** | Добавь/исправь шаги в существующем воркфлоу |
+| **Обогащение knowledge** | Дополни существующий файл в knowledge/ после маркера расширения |
+| **Рефакторинг** | Реструктуризация без изменения поведения |
+
+### 4. Исследование (если нужно)
+
+Если улучшение требует новых знаний:
+- Поищи в интернете лучшие практики, фреймворки, методологии
+- Адаптируй найденное под формат knowledge/ или algorithms/
+- Укажи источник
+
+### 5. Внесение изменений
+
+- Следуй принципу минимальных изменений
+- Не ломай существующие ссылки и интеграции
+- Добавляй, а не переписывай (если не рефакторинг)
+- Обнови README.md если структура изменилась
+
+### 6. Валидация
+
+- Проверь все ссылки из SKILL.md
+- Убедись что новые файлы упомянуты в таблицах загрузки
+- Проверь консистентность терминологии
+
+### 7. Документирование
+
+Сформируй план улучшений → `templates/improvement-plan.md` с:
+- Что изменено и почему
+- Какие файлы затронуты
+- Ожидаемый эффект
+- Как проверить результат
+
+### 8. Обновление бэклога → SKILL.md «Обязательный шаг: Бэклог коуча»

package/src/skills/coach/workflows/research.md

@@ -0,0 +1,55 @@
+# Воркфлоу: RESEARCH — Исследование и поиск знаний
+
+Поиск лучших практик, фреймворков и подходов в интернете для обогащения скилов.
+
+## Алгоритм выполнения
+
+### 1. Определи цель исследования
+
+Из тикета извлеки:
+- Для какого скила ищем знания?
+- Какой домен / тема?
+- Какой тип знаний нужен: методология, метрики, бенчмарки, инструменты?
+
+### 2. Сформулируй поисковые запросы
+
+Составь 3–5 поисковых запросов на русском и английском:
+
+| Тип запроса | Пример |
+|-------------|--------|
+| Лучшие практики | «best practices [domain] framework 2025» |
+| Методологии | «[domain] methodology checklist» |
+| Метрики и бенчмарки | «[domain] KPI benchmarks SaaS» |
+| Инструменты | «[domain] tools stack comparison» |
+| Антипаттерны | «[domain] common mistakes pitfalls» |
+
+### 3. Поиск и фильтрация
+
+- Выполни поиск в интернете
+- Отфильтруй результаты по релевантности и актуальности (приоритет — свежие источники)
+- Извлеки ключевые идеи, фреймворки, чеклисты
+
+### 4. Адаптация под формат скила
+
+Преобразуй найденное в формат модулей скила:
+
+| Найденное | Куда добавить |
+|-----------|--------------|
+| Фреймворк принятия решений | `algorithms/` |
+| Набор метрик или бенчмарков | `knowledge/` |
+| Чеклист или пошаговый процесс | `workflows/` или `knowledge/` |
+| Шаблон документа | `templates/` |
+
+### 5. Интеграция
+
+- Создай или дополни соответствующие файлы в скиле
+- Добавь ссылки в таблицы загрузки SKILL.md
+- Укажи источник информации и дату получения
+
+### 6. Оформление результата
+
+Результат исследования:
+- Краткое резюме найденного
+- Список источников с кратким описанием каждого
+- Конкретные изменения, внесённые в скил
+- Рекомендации для дальнейшего исследования

package/src/skills/coach/workflows/review.md

@@ -0,0 +1,52 @@
+# Воркфлоу: REVIEW — Ревью скила
+
+Быстрое ревью структуры и качества скила с фокусом на конкретные аспекты.
+
+## Алгоритм выполнения
+
+### 0. Создание теста → `workflows/test.md`
+
+Перед началом ревью создай регрессионный тест для скила. Следуй воркфлоу `workflows/test.md`.
+
+### 1. Определи фокус ревью
+
+Из тикета извлеки: какой аспект проверить?
+
+| Фокус | Что проверять |
+|-------|--------------|
+| **Структура** | Полнота директорий и файлов, ссылочная целостность |
+| **Качество промптов** | Чёткость инструкций, отсутствие двусмысленности |
+| **Покрытие** | Все ли сценарии обработаны, нет ли пробелов |
+| **Консистентность** | Единообразие терминов, форматов, стиля |
+| **Актуальность** | Не устарели ли знания, бенчмарки, инструменты |
+
+Если фокус не указан — проведи ревью по всем аспектам.
+
+### 2. Чтение и анализ
+
+Прочитай все файлы скила. Чеклист по типам файлов:
+
+| Тип файла | Критерии |
+|-----------|----------|
+| **SKILL.md** | Роль конкретна, RACI чёткий, маршрутизация полна, таблицы загрузки полны, принципы actionable, формат вывода специфицирован |
+| **Workflows** | Каждый шаг — действие, ссылки на knowledge/algorithms, критерии завершения, нет дублирования |
+| **Knowledge** | Структурировано (таблицы/списки), маркеры `<!-- РАСШИРЕНИЕ -->`, источники указаны |
+| **Algorithms** | Формализован (шаги/пороги/формулы), вход/выход определён, примеры |
+| **Templates** | Поля обязательны или помечены, формат единообразен, placeholder-подсказки |
+
+### 3. Формирование замечаний
+
+Для каждого замечания укажи:
+- **Файл и секция** — где проблема
+- **Приоритет** — CRITICAL / HIGH / MEDIUM / LOW
+- **Проблема** — что не так
+- **Рекомендация** — как исправить
+
+### 4. Сообщить пользователю verdict runner'а и список затронутых файлов
+
+Сообщи пользователю:
+
+- **Список затронутых файлов:** `SKILL.md` и/или `workflows/`, `tests/cases/{id}.yaml`, `tests/index.yaml`, `tests/cases/{id}/current/`
+- **Verdict** из прогона тестов (шаг 0).
+
+**Остановиться.**

package/src/skills/coach/workflows/review.md.legacy

@@ -0,0 +1,48 @@
+# Воркфлоу: REVIEW — Ревью скила
+
+Быстрое ревью структуры и качества скила с фокусом на конкретные аспекты.
+
+## Алгоритм выполнения
+
+### 0. Бэклог → SKILL.md «Обязательный шаг: Бэклог коуча». Учитывай `applied_changes` при формировании замечаний.
+
+### 1. Определи фокус ревью
+
+Из тикета извлеки: какой аспект проверить?
+
+| Фокус | Что проверять |
+|-------|--------------|
+| **Структура** | Полнота директорий и файлов, ссылочная целостность |
+| **Качество промптов** | Чёткость инструкций, отсутствие двусмысленности |
+| **Покрытие** | Все ли сценарии обработаны, нет ли пробелов |
+| **Консистентность** | Единообразие терминов, форматов, стиля |
+| **Актуальность** | Не устарели ли знания, бенчмарки, инструменты |
+
+Если фокус не указан — проведи ревью по всем аспектам.
+
+### 2. Чтение и анализ
+
+Прочитай все файлы скила. Чеклист по типам файлов:
+
+| Тип файла | Критерии |
+|-----------|----------|
+| **SKILL.md** | Роль конкретна, RACI чёткий, маршрутизация полна, таблицы загрузки полны, принципы actionable, формат вывода специфицирован |
+| **Workflows** | Каждый шаг — действие, ссылки на knowledge/algorithms, критерии завершения, нет дублирования |
+| **Knowledge** | Структурировано (таблицы/списки), маркеры `<!-- РАСШИРЕНИЕ -->`, источники указаны |
+| **Algorithms** | Формализован (шаги/пороги/формулы), вход/выход определён, примеры |
+| **Templates** | Поля обязательны или помечены, формат единообразен, placeholder-подсказки |
+
+### 3. Формирование замечаний
+
+Для каждого замечания укажи:
+- **Файл и секция** — где проблема
+- **Приоритет** — CRITICAL / HIGH / MEDIUM / LOW
+- **Проблема** — что не так
+- **Рекомендация** — как исправить
+
+### 4. Итоговая оценка
+
+- Общая оценка: READY / NEEDS_WORK / MAJOR_ISSUES
+- Количество замечаний по приоритетам
+- Топ-3 вещи, которые сделаны хорошо
+- Топ-3 вещи, которые нужно исправить

package/src/skills/coach/workflows/test.md

@@ -0,0 +1,97 @@
+# Воркфлоу: TEST — Авторство тест-кейса регрессионного теста скила
+
+> **⚠️ DRAFT — не активирован.** Подключение к маршрутизации SKILL.md произойдёт в отдельной задаче.
+
+Воркфлоу описывает, как коуч создаёт регрессионный тест для скила при обнаружении инцидента.
+
+**Знания:** загрузи `knowledge/test-authorship.md` перед выполнением шагов.
+
+## Шаги 1–5: Подготовительный этап
+
+### Шаг 1. CHG-идентификатор не нужен
+
+Тест-кейс — это не изменение скила, а фиксация инцидента. Поэтому:
+
+- **Не создавай** CHG-запись в `applied_changes[]` бэклога.
+- Инцидент фиксируется через поле `origin` непосредственно в YAML тест-кейса.
+
+### Шаг 2. Получить ID тест-кейса
+
+Вызови скрипт из корня проекта:
+
+```
+node .workflow/src/scripts/get-next-test-id.js --skill <имя-скила>
+```
+
+Скрипт вернёт следующий свободный ID в формате `TC-<SKILL>-NNN`.
+Используй именно этот ID — не генерируй вручную.
+
+### Шаг 3. Выбор слоёв (L0 / L1 / L2)
+
+Полная логика выбора — в `knowledge/test-authorship.md`, раздел «Дерево выбора слоя».
+
+Краткие правила:
+
+| Слой | Когда использовать |
+|------|--------------------|
+| **L0** static | **Всегда** — если нужно проверить наличие инварианта в записанном файле. |
+| **L1** deterministic | Когда у output есть наблюдаемая сигнатура (структура YAML/JSON, формат ID, наличие ключей). |
+| **L2** rubric | Когда нужно проверить **принцип рассуждения** агента, а не конкретный текст. |
+
+Правило минимума: сомневаешься между L0 и L1 — выбирай L0. L2 — только если L0/L1 физически неприменимы.
+
+### Шаг 4. Построить фикстуру
+
+- Возьми **реальный артефакт**, в котором произошёл инцидент (лог, тикет, отчёт).
+- Вырежи **±20 строк вокруг инцидента** — не копируй весь файл.
+- Для log-фикстур: только шаги, где произошёл инцидент + 5 строк контекста до и после.
+- Критерий минимума: убери строку → тест перестаёт проверять нужное поведение? Если нет — строка лишняя.
+
+Сохрани фикстуру в `tests/fixtures/` скила.
+
+### Шаг 5. Написать YAML тест-кейса и проверить `index.yaml`
+
+1. Создай файл `tests/cases/<ID>.yaml` по структуре существующих кейсов в `tests/cases/`.
+2. В поле `origin` укажи ID инцидента (CHG или ссылку на артефакт).
+3. Проверь `tests/index.yaml` скила:
+   - Содержит ли он актуальный список `target_agents[]`?
+   - Если список устарел — обнови его, сверившись с `pipeline.yaml` проекта.
+4. Добавь запись о новом кейсе в секцию `cases:` файла `tests/index.yaml`.
+
+## Шаги 6–9: Исполнительный этап
+
+### Шаг 6. Прогон тестов
+
+Запусти скрипт из корня проекта:
+
+```
+node .workflow/src/scripts/run-skill-tests.js --skill <name> --relevant <TC-NNN>
+```
+
+Где `<name>` — имя скила, `<TC-NNN>` — ID тест-кейса, созданного на шаге 2.
+
+### Шаг 7. Проверка verdict из `---RESULT---`
+
+Прочитай поле `verdict` в блоке `---RESULT---` вывода скрипта:
+
+| Verdict | Действие |
+|---------|----------|
+| `ready_for_user_review` | Перейти к шагу 8. |
+| `regression_detected` | Доработать скил или тест, вернуться к шагу 6. |
+| `relevant_case_failed` | Доработать скил или тест, вернуться к шагу 6. |
+| `no_baseline_failures` | Доработать скил или тест, вернуться к шагу 6. |
+
+### Шаг 8. Сообщить пользователю
+
+Сообщи пользователю:
+
+- **Список затронутых файлов:** `SKILL.md` и/или `workflows/`, `tests/cases/{id}.yaml`, `tests/index.yaml`, `tests/cases/{id}/current/`
+- **Verdict** из шага 7.
+
+**Остановиться.** Коуч не делает ничего сверх этого — коммит на стороне пользователя (шаг 9).
+
+### Шаг 9. Коммит делает исключительно пользователь
+
+Коуч **не выполняет** `git add`, `git commit`, `git push`, `git checkout`, `git reset` ни в каком виде.
+
+В `applied_changes[]` бэклога **не пишем** — история правки живёт в git (скил + тест коммитятся пользователем одним коммитом).

package/src/skills/create-plan/README.md

@@ -0,0 +1,39 @@
+# Create Plan — Agent Skill
+
+Архитектор планов. Создаёт самодостаточные стратегические планы из ТЗ, спецификаций и задач. План содержит все данные, необходимые исполнителям — SMART-цели, справочные данные, scope, риски и критерии успеха.
+
+## Структура
+
+```
+create-plan/
+├── SKILL.md                          # Ядро: роль, маршрутизация, принципы
+├── README.md                         # Документация
+├── algorithms/
+│   └── risk-assessment.md            # Матрица рисков, критерии, митигация
+├── workflows/
+│   └── create.md                     # Создание плана из ТЗ / спецификации
+└── knowledge/
+    ├── plan-completeness.md          # Чеклист полноты плана
+    ├── plan-lifecycle.md             # Статусы планов
+    └── task-verification-pairs.md    # Парные задачи верификации
+```
+
+## Как это работает
+
+1. Скил получает запрос на создание плана (из ТЗ, спецификации или задачи)
+2. Загружает `knowledge/plan-completeness.md` — чеклист полноты
+3. Определяет сценарий и загружает `workflows/create.md`
+4. Извлекает все конкретные данные из входного документа (credentials, URLs, параметры)
+5. Формирует план: SMART-цели, справочные данные, scope, задачи, риски, критерии успеха
+6. Проверяет план по чеклисту полноты
+7. Сохраняет результат в `.workflow/plans/current/PLAN-{NNN}.md`
+
+## Как расширять
+
+### Новый тип воркфлоу
+1. Создай файл в `workflows/{type}.md`
+2. Добавь запись в таблицу маршрутизации в `SKILL.md`
+
+### Новый knowledge-модуль
+1. Создай файл в `knowledge/{module}.md`
+2. Добавь запись в таблицу загрузки знаний в `SKILL.md`

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

@@ -0,0 +1,104 @@
+---
+name: create-plan
+description: >
+  Создать стратегический план для проекта. Используй когда нужно спланировать
+  новую функциональность, проект или задачу. Создаёт самодостаточный файл плана
+  в .workflow/plans/current/ по шаблону со SMART-целями, справочными данными,
+  scope, рисками и критериями успеха. План содержит ВСЕ данные, необходимые
+  исполнителям — без обращения к внешним документам.
+---
+
+# Создание плана
+
+Этот skill создаёт стратегический план для достижения цели.
+
+## Роль
+
+Ты — архитектор планов. Твоя задача — создать **самодостаточный** план, по которому агенты-исполнители смогут выполнить все задачи **без обращения к исходному ТЗ или другим внешним документам**.
+
+**Ты делаешь:** извлечение всех конкретных данных из входного документа, формулирование SMART-целей, определение scope, декомпозиция на задачи с полными деталями, анализ рисков, определение критериев успеха.
+
+**Ты НЕ делаешь:** декомпозицию на тикеты (это задача скила декомпозиции), выполнение задач, принятие решений за стейкхолдера по scope.
+
+## Когда использовать
+
+- Начинается новый проект или крупная задача
+- Нужно переосмыслить направление после отчёта
+- Требуется структурированный план с декомпозицией
+
+## Маршрутизация
+
+| Сценарий | Воркфлоу |
+|----------|----------|
+| Создание плана из ТЗ / спецификации / задачи | → `workflows/create.md` |
+
+## Загрузка знаний
+
+| Модуль | Когда загружать |
+|--------|----------------|
+| `knowledge/plan-completeness.md` | **ВСЕГДА** — чеклист полноты плана, правила извлечения данных из ТЗ |
+| `knowledge/plan-lifecycle.md` | **ВСЕГДА** — статусы планов и правила их установки |
+| `knowledge/task-verification-pairs.md` | При наличии в плане задач тестирования/верификации ИЛИ задач, изменяющих код — правила TC-структуры: data assertions, entry points, config variations, persistence и парные задачи верификации |
+| `../shared/*` | **Перед началом работы** проверь `../shared/README.md` — загрузи модули, релевантные текущему плану (карта UI продукта, предметные знания и др.) |
+
+## Загрузка алгоритмов
+
+Подгружай из `algorithms/` когда нужен формализованный метод:
+
+| Алгоритм | Когда загружать |
+|----------|----------------|
+| `algorithms/risk-assessment.md` | При создании секции рисков плана — матрица вероятность × влияние, категории, митигация |
+
+## Принципы
+
+1. **Самодостаточность** — план содержит ВСЕ данные для исполнения. Если данных нет в плане — их нет у исполнителей. Никаких ссылок "см. ТЗ" или "URL уже создан".
+2. **Конкретность** — credentials, URLs, параметры, конфигурации, code blocks — всё это переносится в план как есть.
+3. **Полнота задач** — каждая задача содержит: какие файлы затрагиваются, какие значения использовать, edge cases, предупреждения.
+4. **Самопроверка** — перед сохранением обязательна проверка по чеклисту из `knowledge/plan-completeness.md`.
+5. **SMART-цели** — цель плана конкретна, измерима, достижима, релевантна, ограничена во времени.
+6. **Верификация изменений кода** — каждая задача, изменяющая код продукта, сопровождается парными задачами: ручная проверка и актуализация автотестов. См. `knowledge/task-verification-pairs.md`.
+7. **Актуализация shared knowledge** — если план меняет внешнее поведение продукта (новые команды, views, настройки, API, горячие клавиши, UI-элементы), добавь в план задачу на обновление соответствующих модулей в `../shared/`. Устаревший shared knowledge приводит к ошибкам во всех скилах-потребителях (планирование нереалистичных тест-кейсов, слепое тестирование, лишние MCP-вызовы).
+8. **Гранулярность задач** — каждая задача плана должна описывать **одно действие** (один глагол) над **одним объектом**. Задача «Исправить X — сигнатура, порядок, удаление Y» содержит 3 независимых действия и должна быть разбита на 3 задачи уже на этапе плана. Декомпозитор работает со структурой плана как с якорем — крупная задача провоцирует маппинг «1 задача = 1 тикет», даже если чеклист атомарности требует разбиения. **Self-check:** перед сохранением плана для каждой задачи проверь: содержит ли название задачи 2+ глагола через запятую, «и», «а также», «плюс»? Содержат ли нумерованные шаги независимые (параллельные) действия? Если да — разбей задачу в плане.
+
+## Правило назначения исполнителей
+
+Не назначай HUMAN, если агент может выполнить задачу автономно. Агент имеет доступ к:
+- **Playwright MCP-browser** — открывает URL в браузере, включая аутентифицированные сервисы (если сессия активна)
+- **WebSearch / WebFetch** — публичные данные
+- **Файлы проекта** — данные в корне
+
+HUMAN назначается только когда агент **подтверждённо** не может получить доступ (2FA, оплата, физические действия). При неопределённости — назначай агента с `fallback: HUMAN`.
+
+## Формат вывода
+
+- Русский язык
+- Markdown с таблицами и code blocks
+- Секция "Справочные данные" обязательна при создании из ТЗ
+- Все конкретные значения — в code blocks или таблицах
+
+## Границы компетенции
+
+- **Декомпозиция на тикеты** → скил декомпозиции
+- **Анализ отчётов** → скил анализа отчётов
+- **Выполнение задач** → скил выполнения задач
+
+## Пример использования
+
+```
+Создай план на основе ТЗ dev-tasks-plan007.md
+```
+
+## Результат
+
+Файл `.workflow/plans/current/PLAN-{NNN}.md` с:
+- Целью и контекстом
+- **Справочными данными** (все credentials, URLs, параметры, конфигурации из ТЗ)
+- Scope (включено/исключено)
+- Высокоуровневыми задачами с конкретными деталями
+- Рисками и митигацией
+- Критериями успеха
+
+
+---
+
+**Регрессионные тесты:** `tests/index.yaml`. Прогон: `node .workflow/src/scripts/run-skill-tests.js --skill create-plan`

package/src/skills/create-plan/algorithms/risk-assessment.md

@@ -0,0 +1,73 @@
+# Алгоритм: Оценка рисков плана
+
+## Вход
+
+Описание задач плана, контекст проекта, внешние зависимости.
+
+## Матрица рисков
+
+Риск = **Вероятность (1–3)** × **Влияние (1–3)**. Итоговый уровень:
+
+| Вероятность \ Влияние | 1 (Низкое) | 2 (Среднее) | 3 (Высокое) |
+|----------------------:|:----------:|:-----------:|:-----------:|
+| **3 (Высокая)**       | MEDIUM (3) | HIGH (6)    | CRITICAL (9)|
+| **2 (Средняя)**       | LOW (2)    | MEDIUM (4)  | HIGH (6)    |
+| **1 (Низкая)**        | LOW (1)    | LOW (2)     | MEDIUM (3)  |
+
+## Критерии вероятности
+
+| Уровень | Определение | Пример |
+|:-------:|-------------|--------|
+| 1 | Маловероятно, требует стечения обстоятельств | Сторонний API изменит контракт во время спринта |
+| 2 | Возможно, случалось ранее или есть предпосылки | Интеграция потребует доработки из-за недокументированного поведения |
+| 3 | Почти наверняка, есть объективные признаки | Задача зависит от компонента, находящегося в активной разработке другой командой |
+
+## Критерии влияния
+
+| Уровень | Определение | Пример |
+|:-------:|-------------|--------|
+| 1 | Задержка ≤1 дня, обходной путь очевиден | Мелкий баг в утилите, можно пропатчить на месте |
+| 2 | Задержка 2–5 дней или частичное снижение качества | Нужен рефакторинг смежного модуля для интеграции |
+| 3 | Блокер: задержка >5 дней, пересмотр scope или архитектуры | Ключевая зависимость недоступна, альтернатива требует переделки |
+
+## Категории рисков
+
+При идентификации рисков проверь каждую категорию:
+
+| Категория | На что обращать внимание |
+|-----------|--------------------------|
+| **Технические** | Незнакомые технологии, сложные интеграции, legacy-код без тестов, производительность |
+| **Ресурсные** | Доступность исполнителей, context budget агентов, необходимость ручных действий (HUMAN) |
+| **Зависимости** | Внешние API, сторонние библиотеки, блокирующие задачи других команд, merge freeze |
+| **Внешние** | Изменения требований, compliance-ограничения, доступность сред (staging, sandbox) |
+
+## Стратегии митигации
+
+| Уровень риска | Действие |
+|:-------------:|----------|
+| CRITICAL (6–9) | Обязательная митигация в плане. Определи fallback-вариант и условие переключения |
+| HIGH (4–6) | Митигация рекомендована. Укажи план Б или запасной подход |
+| MEDIUM (3–4) | Упомяни в секции рисков. Митигация по необходимости |
+| LOW (1–2) | Фиксируй только если влияние = 3 (может перейти в MEDIUM при росте вероятности) |
+
+## Применение
+
+1. Составь список задач плана
+2. Для каждой задачи пройди по 4 категориям — идентифицируй конкретные риски
+3. Оцени вероятность и влияние каждого риска по критериям выше
+4. Рассчитай уровень по матрице
+5. Для CRITICAL/HIGH — опиши митигацию и fallback
+6. Запиши в секцию «Риски и зависимости» плана
+
+### Пример
+
+> **Риск:** Sandbox нестабилен — MCP disconnect при длительных сессиях
+> **Категория:** Техническая / Зависимости
+> **Вероятность:** 3 (подтверждено инцидентами QA-004, QA-006)
+> **Влияние:** 2 (задержка 2-3 дня, обходной путь — restart + continuation)
+> **Уровень:** HIGH (6)
+> **Митигация:** Ограничить сессию до N тест-кейсов, стратегия continuation
+
+## Выход
+
+Таблица рисков в плане: риск, категория, вероятность, влияние, уровень, митигация.