workflow-ai 1.1.0 → 1.3.0

package/src/skills/coach/tests/rubrics/calibration/evidence-based-bad.md

@@ -1,13 +0,0 @@
-# Calibration: Evidence-Based Bad (ожидаемый score ≤ 2/5)
-
-Этот файл содержит слабый ответ агента, который rubric `evidence-based.md` **обязан оценить ≤ 2/5**.
-
----
-
-## Ответ агента (образец)
-
-**Анализ пайплайна:**
-
-В логе видно, что пайплайн выполнил несколько этапов: сначала была выполнена архивация старых тикетов, затем декомпозиция плана. Возможно, возникла проблема с нумерацией тикетов, так как система могла повторно использовать старые ID. Рекомендую проверить скрипт генерации ID.
-
-В целом пайплайн завершился успешно, декомпозиция создала 5 тикетов. Скорее всего, нужно улучшить механизм присвоения идентификаторов.

package/src/skills/coach/tests/rubrics/calibration/evidence-based-good.md

@@ -1,29 +0,0 @@
-# Calibration: Evidence-Based Good (ожидаемый score ≥ 4/5)
-
-Этот файл содержит образцовый ответ агента, который rubric `evidence-based.md` **обязан оценить ≥ 4/5**.
-
----
-
-## Ответ агента (образец)
-
-**Finding: CRITICAL — Коллизия ID IMPL-002 и IMPL-003 между PLAN-002 и PLAN-003**
-
-**Временна́я диаграмма по ID IMPL-002:**
-
-| Событие | Время | Строка лога |
-|---------|-------|-------------|
-| IMPL-002 создан для PLAN-002 | (ранее) | — (за пределами лога) |
-| IMPL-002: done → archive (PLAN-002 archived) | 16:36:02 | line 28 |
-| decompose-plan создаёт **новый** IMPL-002 для PLAN-003 | 16:40:31 | line 121 |
-
-**Временна́я диаграмма по ID IMPL-003:**
-
-| Событие | Время | Строка лога |
-|---------|-------|-------------|
-| IMPL-003 создан для PLAN-002 | (ранее) | — |
-| IMPL-003: done → archive (PLAN-002 archived) | 16:36:02 | line 29 |
-| decompose-plan создаёт **новый** IMPL-003 для PLAN-003 | 16:40:31 | line 120 |
-
-**Root Cause:** Скил `decompose-plan` использует ручной подбор ID вместо `get-next-id.js`. В 16:36:02 (строки 28-29) IMPL-002 и IMPL-003 были сдвинуты в архив как завершённые тикеты PLAN-002. В 16:40:31 (строки 120-121) `decompose-plan` присвоил те же ID новым тикетам PLAN-003, не сканируя `archive/`. Это коллизия ID — два разных артефакта с одинаковым идентификатором.
-
-**Скил-источник:** `decompose-plan` — физически записывает тикеты с ID в `backlog/` (строки 119-123 лога).

package/src/skills/coach/tests/rubrics/evidence-based.md

@@ -1,26 +0,0 @@
-# Rubric: Evidence-Based Temporal Diagram
-
-## Критерий
-
-**Демонстрирует ли ответ построение временной диаграммы по ID артефакта?**
-
-Агент должен:
-1. Выявить один или несколько ID артефактов (тикет, план, отчёт) из лога.
-2. Проследить **всю историю** каждого ID от первого упоминания до последнего (включая события, разделённые по времени).
-3. Явно сопоставить события, связанные одним ID, — выявить коллизию, противоречие или паттерн.
-4. Обосновать вывод ссылками на **конкретные строки лога** (номера строк или временны́е метки).
-
-## Шкала оценки (1–5)
-
-| Балл | Описание |
-|------|----------|
-| **5** | Временная диаграмма явно построена: агент перечисляет события по каждому ID хронологически, цитирует конкретные строки/метки лога, явно называет коллизию или паттерн, вывод опирается исключительно на данные из лога. |
-| **4** | Временная диаграмма присутствует в неявном виде: все события по ID прослежены, конкретные строки лога процитированы, коллизия/паттерн выявлена, но хронологическая структура изложена нарративно, а не в виде явной диаграммы. |
-| **3** | Частичное построение: агент идентифицирует коллизию и упоминает часть событий, но не прослеживает полную цепочку по ID — либо пропущен один конец цепочки (только archive или только create), либо строки лога не процитированы. |
-| **2** | Коллизия угадана или названа без опоры на конкретные строки лога. Агент использует общие слова («вероятно», «предположительно») или не связывает события одним ID явно. |
-| **1** | Нет признаков построения временной диаграммы: общий вывод без ссылок на лог, либо ID не сопоставлены между событиями, либо ответ не относится к содержимому лога. |
-
-## Calibration
-
-- Ответ, оцениваемый **≥ 4/5**: [`calibration/evidence-based-good.md`](calibration/evidence-based-good.md)
-- Ответ, оцениваемый **≤ 2/5**: [`calibration/evidence-based-bad.md`](calibration/evidence-based-bad.md)

package/src/skills/coach/tests/rubrics/root-cause-first.md

@@ -1,21 +0,0 @@
-# Rubric: Root Cause First
-
-Оцените ответ коуча по шкале 1-5.
-
-## Критерий
-
-Коуч при анализе инцидента:
-1. Начинает с **причины первого порядка** (конкретное невыполненное действие агентом)
-2. Затем анализирует **почему инструкции допустили** это (недостаток машинной защиты, нечёткость формулировки)
-3. При повторном инциденте **эскалирует в машинную защиту**, а не предлагает текстовое усиление
-4. НЕ уходит в абстрактные рассуждения о формулировках до установления root cause
-
-## Шкала
-
-| Балл | Описание |
-|------|----------|
-| 5 | Root cause первого порядка найден, цепочка прослежена, повторный инцидент → эскалация в машинную защиту |
-| 4 | Root cause найден корректно, предложено решение, но эскалация не максимально конкретна |
-| 3 | Root cause найден частично, есть отвлечение на формулировки |
-| 2 | Начал с формулировок, root cause упомянут вторично |
-| 1 | Root cause не найден или предложено только текстовое усиление при повторном инциденте |

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

@@ -1,79 +0,0 @@
-# Воркфлоу: ANALYZE — Анализ эффективности скила
-
-Анализ работы скила на основе завершённых планов, тикетов и отчётов.
-
-## Алгоритм выполнения
-
-### 0. Бэклог → SKILL.md «Обязательный шаг: Тест». Прочитай `analyzed_tickets[]` — исключи уже проанализированные тикеты из выборки.
-
-### 1. Сбор данных
-
-Собери все завершённые артефакты, связанные со скилом.
-**Исключи тикеты, уже присутствующие в бэклоге (`analyzed_tickets`).**
-
-| Источник | Где искать | Что извлечь |
-|----------|-----------|-------------|
-| Завершённые тикеты | `.workflow/tickets/done/` | Результаты, время, качество |
-| Планы | `.workflow/plans/` | Цели, декомпозиция, отклонения |
-| Отчёты | `.workflow/reports/` | Метрики, выводы, проблемы |
-
-Фильтруй по `ticket_prefix` скила.
-
-### 2. Анализ паттернов
-
-**Паттерны успеха:**
-- Какие типы тикетов выполняются хорошо?
-- Какие воркфлоу дают стабильный качественный результат?
-- Какие knowledge-модули используются чаще всего?
-
-**Паттерны проблем:**
-- Какие тикеты завершаются с неполным результатом?
-- Где агент отклоняется от воркфлоу?
-- Какие знания отсутствуют и требуют дополнения?
-- Где агент «додумывает» вместо использования knowledge?
-
-**⚠️ Проверка соответствия процесса (ОБЯЗАТЕЛЬНО):** Для каждого тикета сверь предписанные инструменты/шаги (из SKILL.md скила) с фактически использованными (из «Agent used», «Что сделано»). Расхождение = **finding**, даже если DoD формально ✅ passed.
-
-### 3. Gap-анализ
-
-Применить → `algorithms/gap-analysis.md`
-
-Определи:
-- Типы задач, которые приходят, но не имеют воркфлоу
-- Знания, которые нужны, но отсутствуют в knowledge/
-- Решения, которые принимаются ad-hoc вместо формализованного алгоритма
-
-### 4. Метрики качества
-
-| Метрика | Как считать |
-|---------|------------|
-| Полнота результата | % тикетов с заполненными всеми секциями DoD |
-| Соответствие воркфлоу | % тикетов, где агент следовал шагам воркфлоу |
-| Использование knowledge | Частота обращений к knowledge-модулям |
-| Время выполнения | Среднее время по типам тикетов |
-
-### 5. Формирование выводов
-
-- Топ-3 сильные стороны скила
-- Топ-3 проблемы / узкие места
-- Топ-3 возможности для улучшения
-- Конкретные рекомендации с указанием файлов для изменения
-
-Результат оформи как часть отчёта → `templates/audit-report.md`
-
-### 6. Запись в `analyzed_tickets[]` → обнови `analyzed_tickets[]` в `.workflow/coach-backlog.yaml`: добавь проанализированные тикеты/логи. Обнови `last_updated`.
-
-### 7. Создание теста → `workflows/test.md`
-
-Выполни воркфлоу `workflows/test.md` для скила, который был проанализирован:
-- Создай регрессионный тест-кейс, фиксирующий ключевой finding анализа
-- Прогони runner и получи verdict
-
-### 8. Сообщить пользователю verdict и список затронутых файлов
-
-Сообщи пользователю:
-
-- **Verdict** runner'а из шага 7.
-- **Список затронутых файлов:** `SKILL.md` и/или `workflows/`, `tests/cases/{id}.yaml`, `tests/index.yaml`, `tests/cases/{id}/current/`
-
-**Остановиться.** Коуч не делает ничего сверх этого — коммит на стороне пользователя.

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

@@ -1,64 +0,0 @@
-# Воркфлоу: ANALYZE — Анализ эффективности скила
-
-Анализ работы скила на основе завершённых планов, тикетов и отчётов.
-
-## Алгоритм выполнения
-
-### 0. Бэклог → SKILL.md «Обязательный шаг: Бэклог коуча». Пропусти тикеты из `analyzed_tickets`, не предлагай правки из `applied_changes`.
-
-### 1. Сбор данных
-
-Собери все завершённые артефакты, связанные со скилом.
-**Исключи тикеты, уже присутствующие в бэклоге (`analyzed_tickets`).**
-
-| Источник | Где искать | Что извлечь |
-|----------|-----------|-------------|
-| Завершённые тикеты | `.workflow/tickets/done/` | Результаты, время, качество |
-| Планы | `.workflow/plans/` | Цели, декомпозиция, отклонения |
-| Отчёты | `.workflow/reports/` | Метрики, выводы, проблемы |
-
-Фильтруй по `ticket_prefix` скила.
-
-### 2. Анализ паттернов
-
-**Паттерны успеха:**
-- Какие типы тикетов выполняются хорошо?
-- Какие воркфлоу дают стабильный качественный результат?
-- Какие knowledge-модули используются чаще всего?
-
-**Паттерны проблем:**
-- Какие тикеты завершаются с неполным результатом?
-- Где агент отклоняется от воркфлоу?
-- Какие знания отсутствуют и требуют дополнения?
-- Где агент «додумывает» вместо использования knowledge?
-
-**⚠️ Проверка соответствия процесса (ОБЯЗАТЕЛЬНО):** Для каждого тикета сверь предписанные инструменты/шаги (из SKILL.md скила) с фактически использованными (из «Agent used», «Что сделано»). Расхождение = **finding**, даже если DoD формально ✅ passed.
-
-### 3. Gap-анализ
-
-Применить → `algorithms/gap-analysis.md`
-
-Определи:
-- Типы задач, которые приходят, но не имеют воркфлоу
-- Знания, которые нужны, но отсутствуют в knowledge/
-- Решения, которые принимаются ad-hoc вместо формализованного алгоритма
-
-### 4. Метрики качества
-
-| Метрика | Как считать |
-|---------|------------|
-| Полнота результата | % тикетов с заполненными всеми секциями DoD |
-| Соответствие воркфлоу | % тикетов, где агент следовал шагам воркфлоу |
-| Использование knowledge | Частота обращений к knowledge-модулям |
-| Время выполнения | Среднее время по типам тикетов |
-
-### 5. Формирование выводов
-
-- Топ-3 сильные стороны скила
-- Топ-3 проблемы / узкие места
-- Топ-3 возможности для улучшения
-- Конкретные рекомендации с указанием файлов для изменения
-
-Результат оформи как часть отчёта → `templates/audit-report.md`
-
-### 6. Обновление бэклога → SKILL.md «Обязательный шаг: Бэклог коуча»

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

@@ -1,74 +0,0 @@
-# Воркфлоу: AUDIT — Полный аудит скила
-
-Комплексная проверка существующего скила на полноту, качество и актуальность.
-
-## Алгоритм выполнения
-
-### 0. Бэклог → SKILL.md «Обязательный шаг: Тест». Прочитай `audited_skills[]` — учти score и findings предыдущего аудита этого скила.
-
-### 1. Инвентаризация
-
-Прочитай все файлы скила и составь карту:
-
-| Проверка | Что смотреть |
-|----------|-------------|
-| Структура | Все ли директории и обязательные файлы на месте? |
-| SKILL.md | Все ли секции заполнены? Актуальна ли маршрутизация? |
-| Workflows | Покрыты ли все типы тикетов? Есть ли пробелы? |
-| Knowledge | Актуальны ли знания? Нет ли устаревших данных? |
-| Algorithms | Формализованы ли методы? Есть ли конкретные пороги/формулы? |
-| Templates | Покрыты ли все типы вывода? Консистентны ли форматы? |
-| README | Описывает ли структуру и процесс расширения? |
-
-### 2. Оценка качества
-
-Применить → `algorithms/skill-scoring.md`
-
-Оцени по каждому критерию и выведи итоговый балл.
-
-### 3. Проверка антипаттернов
-
-Загрузи → `knowledge/common-antipatterns.md`
-
-Проверь каждый антипаттерн. Зафиксируй найденные.
-
-### 4. Анализ связности и изоляции
-
-- Все ли ссылки из SKILL.md ведут на существующие файлы?
-- Все ли файлы в knowledge/ и algorithms/ упомянуты в SKILL.md?
-- Есть ли «осиротевшие» файлы без ссылок?
-- Консистентна ли терминология между файлами?
-- **⛔ Изоляция:** нет ли хардкода имён других скилов/ролей? Проверь: `grep -rE "имена конкретных ролей проекта" скил/` — должен быть 0 результатов. Типичные нарушения: таблицы взаимодействия с перечислением ролей, примеры с ID конкретных ролей, границы компетенции с именами скилов. См. `knowledge/common-antipatterns.md` → секция «Антипаттерны изоляции».
-
-### 5. Сравнение с эталоном
-
-Загрузи → `knowledge/skill-anatomy.md`
-
-Сравни скил с эталонной структурой. Какие компоненты отсутствуют или неполны?
-
-### 6. Формирование отчёта
-
-Используй шаблон → `templates/audit-report.md`
-
-Результат должен содержать:
-- Общий балл качества
-- Список найденных проблем с приоритетами
-- Конкретные рекомендации по каждой проблеме
-- План улучшений с приоритизацией
-
-### 7. Запись snapshot score → обнови `audited_skills[]` в `.workflow/coach-backlog.yaml`: skill_name, last_audit_date, coach_ticket, score, status, notes. Обнови `last_updated`. Добавь тикет в `analyzed_tickets[]` (как требует SKILL.md «Обязательный шаг: Тест»).
-
-### 8. Создание теста → `workflows/test.md`
-
-Выполни воркфлоу `workflows/test.md` для скила, который был проверен:
-- Создай регрессионный тест-кейс, фиксирующий ключевой finding аудита
-- Прогони 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/audit.md.legacy

@@ -1,59 +0,0 @@
-# Воркфлоу: AUDIT — Полный аудит скила
-
-Комплексная проверка существующего скила на полноту, качество и актуальность.
-
-## Алгоритм выполнения
-
-### 0. Бэклог → SKILL.md «Обязательный шаг: Бэклог коуча». Учитывай `applied_changes` — не отмечай как проблему то, что уже исправлено.
-
-### 1. Инвентаризация
-
-Прочитай все файлы скила и составь карту:
-
-| Проверка | Что смотреть |
-|----------|-------------|
-| Структура | Все ли директории и обязательные файлы на месте? |
-| SKILL.md | Все ли секции заполнены? Актуальна ли маршрутизация? |
-| Workflows | Покрыты ли все типы тикетов? Есть ли пробелы? |
-| Knowledge | Актуальны ли знания? Нет ли устаревших данных? |
-| Algorithms | Формализованы ли методы? Есть ли конкретные пороги/формулы? |
-| Templates | Покрыты ли все типы вывода? Консистентны ли форматы? |
-| README | Описывает ли структуру и процесс расширения? |
-
-### 2. Оценка качества
-
-Применить → `algorithms/skill-scoring.md`
-
-Оцени по каждому критерию и выведи итоговый балл.
-
-### 3. Проверка антипаттернов
-
-Загрузи → `knowledge/common-antipatterns.md`
-
-Проверь каждый антипаттерн. Зафиксируй найденные.
-
-### 4. Анализ связности и изоляции
-
-- Все ли ссылки из SKILL.md ведут на существующие файлы?
-- Все ли файлы в knowledge/ и algorithms/ упомянуты в SKILL.md?
-- Есть ли «осиротевшие» файлы без ссылок?
-- Консистентна ли терминология между файлами?
-- **⛔ Изоляция:** нет ли хардкода имён других скилов/ролей? Проверь: `grep -rE "имена конкретных ролей проекта" скил/` — должен быть 0 результатов. Типичные нарушения: таблицы взаимодействия с перечислением ролей, примеры с ID конкретных ролей, границы компетенции с именами скилов. См. `knowledge/common-antipatterns.md` → секция «Антипаттерны изоляции».
-
-### 5. Сравнение с эталоном
-
-Загрузи → `knowledge/skill-anatomy.md`
-
-Сравни скил с эталонной структурой. Какие компоненты отсутствуют или неполны?
-
-### 6. Формирование отчёта
-
-Используй шаблон → `templates/audit-report.md`
-
-Результат должен содержать:
-- Общий балл качества
-- Список найденных проблем с приоритетами
-- Конкретные рекомендации по каждой проблеме
-- План улучшений с приоритизацией
-
-### 7. Обновление бэклога → SKILL.md «Обязательный шаг: Бэклог коуча»

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

@@ -1,80 +0,0 @@
-# Воркфлоу: CREATE — Создание нового скила
-
-Создание полноценного модульного скила с нуля по запросу.
-
-## Алгоритм выполнения
-
-### 1. Сбор требований
-
-Из тикета извлеки:
-- **Роль** — кем является агент с этим скилом?
-- **Зона ответственности** — что делает и что НЕ делает?
-- **Типы тикетов** — какие задачи будет обрабатывать?
-- **Команда / RACI** — с кем взаимодействует (если применимо)?
-- **Домен знаний** — какая экспертиза нужна?
-
-Если информации недостаточно — сформулируй уточняющие вопросы.
-
-### 2. Исследование домена
-
-- Поищи в интернете лучшие практики и фреймворки для данной роли/домена
-- Изучи существующие скилы в `.workflow/src/skills/` для переиспользования паттернов
-- Определи, какие knowledge-модули можно переиспользовать из других скилов
-
-### 3. Проектирование структуры
-
-Используй эталон → `knowledge/skill-anatomy.md`
-
-Определи:
-
-| Компонент | Что создать |
-|-----------|-------------|
-| **SKILL.md** | Роль, RACI, маршрутизация, принципы, формат вывода |
-| **workflows/** | По одному файлу на каждый тип тикета |
-| **knowledge/** | Экспертные знания домена |
-| **algorithms/** | Формализованные методы принятия решений |
-| **templates/** | Шаблоны вывода для каждого типа результата |
-
-### 4. Создание скила
-
-Создай все файлы по шаблону → `templates/new-skill.md`
-
-**Порядок создания:**
-1. `SKILL.md` — ядро скила
-2. `workflows/` — пошаговые алгоритмы
-3. `knowledge/` — экспертные знания
-4. `algorithms/` — методы принятия решений
-5. `templates/` — шаблоны вывода
-6. `README.md` — документация
-
-### 5. Валидация
-
-Проверь скил по алгоритму → `algorithms/skill-scoring.md`
-
-Критерии:
-- [ ] SKILL.md содержит все обязательные секции
-- [ ] Каждый тип тикета имеет свой воркфлоу
-- [ ] Воркфлоу ссылаются на knowledge и algorithms
-- [ ] Шаблоны вывода покрывают все типы результатов
-- [ ] README.md описывает структуру и расширение
-- [ ] Нет дублирования с существующими скилами
-- [ ] Принципы конкретны и actionable
-- [ ] **Изоляция:** нет хардкода имён других скилов/ролей — в примерах используются generic ID (XXX-NNN, example-skill), в таблицах взаимодействия — универсальные описания. Проверка: `grep -rE "конкретные имена ролей проекта" новый-скил/` = 0
-
-### 6. Регистрация
-
-- Добавь скил в таблицу в `CLAUDE.md` и `QWEN.md`
-- Убедись что ticket_prefix уникален
-
-### 7. Создание теста → `workflows/test.md`
-
-Выполни воркфлоу `workflows/test.md` для нового скила.
-
-### 8. Сообщить пользователю verdict и список затронутых файлов. Остановиться.
-
-Сообщи пользователю:
-
-- **Список затронутых файлов:** все файлы созданного скила (`SKILL.md`, `workflows/`, `knowledge/`, `algorithms/`, `templates/`, `README.md`), а также `tests/cases/{id}.yaml`, `tests/index.yaml`
-- **Verdict** из шага 7 (результат запуска тестов).
-
-**Остановиться.**

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

@@ -1,67 +0,0 @@
-# Воркфлоу: CREATE — Создание нового скила
-
-Создание полноценного модульного скила с нуля по запросу.
-
-## Алгоритм выполнения
-
-### 1. Сбор требований
-
-Из тикета извлеки:
-- **Роль** — кем является агент с этим скилом?
-- **Зона ответственности** — что делает и что НЕ делает?
-- **Типы тикетов** — какие задачи будет обрабатывать?
-- **Команда / RACI** — с кем взаимодействует (если применимо)?
-- **Домен знаний** — какая экспертиза нужна?
-
-Если информации недостаточно — сформулируй уточняющие вопросы.
-
-### 2. Исследование домена
-
-- Поищи в интернете лучшие практики и фреймворки для данной роли/домена
-- Изучи существующие скилы в `.workflow/src/skills/` для переиспользования паттернов
-- Определи, какие knowledge-модули можно переиспользовать из других скилов
-
-### 3. Проектирование структуры
-
-Используй эталон → `knowledge/skill-anatomy.md`
-
-Определи:
-
-| Компонент | Что создать |
-|-----------|-------------|
-| **SKILL.md** | Роль, RACI, маршрутизация, принципы, формат вывода |
-| **workflows/** | По одному файлу на каждый тип тикета |
-| **knowledge/** | Экспертные знания домена |
-| **algorithms/** | Формализованные методы принятия решений |
-| **templates/** | Шаблоны вывода для каждого типа результата |
-
-### 4. Создание скила
-
-Создай все файлы по шаблону → `templates/new-skill.md`
-
-**Порядок создания:**
-1. `SKILL.md` — ядро скила
-2. `workflows/` — пошаговые алгоритмы
-3. `knowledge/` — экспертные знания
-4. `algorithms/` — методы принятия решений
-5. `templates/` — шаблоны вывода
-6. `README.md` — документация
-
-### 5. Валидация
-
-Проверь скил по алгоритму → `algorithms/skill-scoring.md`
-
-Критерии:
-- [ ] SKILL.md содержит все обязательные секции
-- [ ] Каждый тип тикета имеет свой воркфлоу
-- [ ] Воркфлоу ссылаются на knowledge и algorithms
-- [ ] Шаблоны вывода покрывают все типы результатов
-- [ ] README.md описывает структуру и расширение
-- [ ] Нет дублирования с существующими скилами
-- [ ] Принципы конкретны и actionable
-- [ ] **Изоляция:** нет хардкода имён других скилов/ролей — в примерах используются generic ID (XXX-NNN, example-skill), в таблицах взаимодействия — универсальные описания. Проверка: `grep -rE "конкретные имена ролей проекта" новый-скил/` = 0
-
-### 6. Регистрация
-
-- Добавь скил в таблицу в `CLAUDE.md` и `QWEN.md`
-- Убедись что ticket_prefix уникален

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

@@ -1,71 +0,0 @@
-# Воркфлоу: 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/`
-
-**Остановиться.** Коуч не делает ничего сверх этого — коммит на стороне пользователя.