workflow-ai 1.0.68 → 1.2.1

package/src/skills/coach/knowledge/backlog-management.md

@@ -1,67 +0,0 @@
-# Управление бэклогом коуча
-
-Бэклог `.workflow/coach-backlog.yaml` — единственный источник правды о проанализированных тикетах и результатах аудита скилов.
-
-## Структура бэклога
-
-```yaml
-version: 1
-last_updated: "2026-03-20"
-
-analyzed_tickets:
-  - ticket_id: "XXX-001"
-    ticket_file: "tickets/done/XXX-001.md"
-    analyzed_date: "2026-03-20"
-    coach_ticket: "COACH-005"
-    findings_count: 3
-    summary: "Краткое описание findings"
-
-audited_skills:
-  - skill_name: "example-skill"
-    last_audit_date: "2026-03-20"
-    coach_ticket: "COACH-004"
-    score: 72
-    status: "NEEDS_WORK"
-```
-
-## Секции бэклога
-
-- **`analyzed_tickets[]`** — защита от повторного анализа тикетов/логов, не приведших к правке скила. Позволяет пропустить уже проанализированный материал.
-- **`audited_skills[]`** — snapshot scores скилов в момент аудита. Позволяет отслеживать динамику качества скилов.
-
-## Правила работы
-
-### Перед началом (ОБЯЗАТЕЛЬНО)
-
-1. Прочитай бэклог → пропусти тикеты из `analyzed_tickets`
-
-### После завершения (ОБЯЗАТЕЛЬНО)
-
-1. Добавь проанализированные тикеты и результаты аудита
-2. Обнови `last_updated`
-
-## История правок скилов — в git
-
-История всех изменений скилов хранится в git-репозитории. Используй стандартные git-команды для её изучения:
-
-```bash
-git log -- src/skills/coach/                    # все правки скила coach
-git log -- src/skills/coach/tests/cases/        # все созданные/изменённые тесты
-git log --follow -- src/skills/coach/SKILL.md   # история конкретного файла
-git blame src/skills/coach/SKILL.md             # кто что написал
-```
-
-## Миграционная заметка
-
-Секция `applied_changes[]` удалена из беклога целиком при миграции (задача IMPL-24).
-
-- Старые CHG доступны через `git show <commit-before-migration>:.workflow/coach-backlog.yaml`.
-- Принципы из старых CHG отражены в тест-кейсах через поле `origin.chg`.
-- Никакого `legacy_*` архива не поддерживается.
-
-## Антипаттерны
-
-- **Повторный анализ** уже проанализированного тикета
-- **Забыть записать** — провести анализ/аудит без записи в бэклог
-
-<!-- РАСШИРЕНИЕ: добавляй правила ведения бэклога ниже -->

package/src/skills/coach/knowledge/backlog-management.md.legacy

@@ -1,90 +0,0 @@
-# Управление бэклогом коуча
-
-Бэклог `.workflow/coach-backlog.yaml` — единственный источник правды о проанализированных тикетах и внесённых правках.
-
-## Структура бэклога
-
-```yaml
-version: 1
-last_updated: "2026-03-20"
-
-analyzed_tickets:
-  - ticket_id: "XXX-001"
-    ticket_file: "tickets/done/XXX-001.md"
-    analyzed_date: "2026-03-20"
-    coach_ticket: "COACH-005"
-    findings_count: 3
-    summary: "Краткое описание findings"
-
-applied_changes:
-  - change_id: "CHG-001"
-    date: "2026-03-20"
-    coach_ticket: "COACH-005"
-    target_skill: "example-skill"
-    changed_files: ["skills/example-skill/knowledge/module.md"]
-    change_type: "improve"  # improve | fix | add | refactor
-    description: "Что и зачем изменено"
-    based_on_tickets: ["XXX-001"]
-
-audited_skills:
-  - skill_name: "example-skill"
-    last_audit_date: "2026-03-20"
-    coach_ticket: "COACH-004"
-    score: 72
-    status: "NEEDS_WORK"
-```
-
-## Правила работы
-
-### Перед началом (ОБЯЗАТЕЛЬНО)
-
-1. Прочитай бэклог → пропусти тикеты из `analyzed_tickets` → учитывай `applied_changes`
-
-### После завершения (ОБЯЗАТЕЛЬНО)
-
-1. Добавь проанализированные тикеты, внесённые правки, результаты аудита
-2. Обнови `last_updated`
-3. `change_id`: `CHG-{порядковый номер, 3 цифры}` — следующий после максимального
-
-## Компрессия бэклога
-
-**Когда:** после записи, если размер > 500 строк. **Цель:** < 300 строк.
-
-### Что сжимать
-
-**1. `analyzed_tickets`** — группировка по скилу: тикеты с похожими findings → одна запись с `consolidated_from` и summary ключевых findings + ссылки на CHG.
-
-**2. `applied_changes`** — группировка связанных: CHG одной проблемы (цепочка итераций) → одна запись с `consolidated_from`, объединёнными `changed_files` и summary.
-
-**3. Не сжимать:** последние 10 записей каждой секции, уникальные findings, `audited_skills`.
-
-### Формат консолидированной записи
-
-Добавляй `consolidated_from: [...]` для трассировки. Summary — ключевые findings + ссылки на CHG.
-
-## Ad-hoc анализы (без тикета)
-
-Если стейкхолдер запрашивает анализ артефакта напрямую (лог, декомпозиция, план) — без формального тикета COACH-* — результат записывается в `analyzed_tickets` с полем `source: ad_hoc`:
-
-```yaml
-analyzed_tickets:
-  - source: ad_hoc
-    artifact: "pipeline_2026-04-06_16-36-02.log"  # путь/имя артефакта
-    analyzed_date: "2026-04-18"
-    findings_count: 4
-    summary: "Краткое описание findings"
-```
-
-**Поля `ticket_id` и `ticket_file` — опциональны** для записей с `source: ad_hoc`, так как тикета не существует.
-
-**⛔ Не используй нестандартные поля** (например, `last_action`) для хранения записей об анализе — они не являются частью схемы, не проходят дедупликацию и молча перезаписываются при следующей записи в тот же ключ (дублирующие ключи в YAML невалидны).
-
-## Антипаттерны
-
-- **Повторный анализ** уже проанализированного тикета или артефакта
-- **Дублирование правок** — предлагать то, что уже в `applied_changes`
-- **Забыть записать** — внести правку без записи в бэклог
-- **Бесконечный рост** — не сжимать при > 500 строк
-- **Non-schema поля** — записывать ad-hoc анализы в `last_action` или любой другой ключ вне официальной схемы вместо `analyzed_tickets` с `source: ad_hoc`
-
-<!-- РАСШИРЕНИЕ: добавляй правила ведения бэклога ниже -->

package/src/skills/coach/knowledge/common-antipatterns.md

@@ -1,76 +0,0 @@
-# Типичные антипаттерны в скилах
-
-Чеклист проблем при аудите и ревью скилов.
-
-## Структурные (S)
-
-| # | Антипаттерн | Как исправить |
-|---|------------|---------------|
-| S1 | Осиротевшие файлы (не в SKILL.md) | Добавить в таблицу загрузки или удалить |
-| S2 | Битые ссылки | Создать файл или исправить ссылку |
-| S3 | Пустые директории | Заполнить или убрать |
-| S4 | Монолитный SKILL.md | Декомпозировать в воркфлоу |
-| S5 | Нет README | Создать по эталону |
-
-## Содержание (C)
-
-| # | Антипаттерн | Как исправить |
-|---|------------|---------------|
-| C1 | Абстрактная роль | Описать роль, границы, зону ответственности |
-| C2 | Размытые принципы | Что делать, когда, как измерить |
-| C3 | Воркфлоу-декларация без шагов | Конкретные шаги, чеклисты, пороги |
-| C4 | Knowledge без структуры | Таблицы, заголовки, маркеры расширения |
-| C5 | Algorithm без формул | Числовые критерии, формулы, пороги |
-| C6 | Template без подсказок | Примеры и placeholder в каждое поле |
-
-## Поведение (B)
-
-| # | Антипаттерн | Как исправить |
-|---|------------|---------------|
-| B1 | Выход за границы | Уточнить «Ты НЕ делаешь» |
-| B2 | Дублирование знаний | Вынести в один модуль, ссылаться |
-| B3 | Нет маршрута для типа | Добавить воркфлоу/маршрутизацию |
-| B4 | Игнорирование knowledge | Добавить ссылки в шагах воркфлоу |
-| B5 | Нет fallback | Правило «Если тип не определяется — ...» |
-
-## Изоляция (I)
-
-| # | Антипаттерн | Как исправить |
-|---|------------|---------------|
-| I1 | Хардкод имён ролей/скилов | → «любой скил проекта», generic ID (XXX-NNN) |
-| I2 | Примеры с конкретными ID ролей | → XXX-001, example-skill |
-| I3 | Таблица ролей во Взаимодействии | → «Любой скил может создать тикет {PREFIX}-*» |
-| I4 | Ссылки на инструменты других скилов | → «описаны в SKILL.md исполнителя» |
-| I5 | Границы компетенции с именами | → «соответствующий скил проекта» |
-
-**Проверка:** `grep -rE "GML|PMA|CSM|CRO|PMK" src/skills/` → 0 результатов.
-
-## Изоляция от конфигурации (IC)
-
-| # | Антипаттерн | Как исправить |
-|---|------------|---------------|
-| IC1 | Хардкод project-wide типов задач | Скил определяет подход по содержимому тикета |
-| IC2 | Knowledge-дубликат конфига | Удалить, источник правды — конфиг |
-| IC3 | Воркфлоу под каждый project-wide тип | Организовать по этапам работы или собственным типам |
-
-## Scope management (SC)
-
-| # | Антипаттерн | Как исправить |
-|---|------------|---------------|
-| SC1 | Scope creep через DoD | Запретить скилу исполнения создавать тикеты |
-| SC2 | Декомпозиция без scope-guard | Проверка «Включено/Исключено из scope» |
-| SC3 | Тикеты-сироты без parent_plan | Обязательно заполнять parent_plan |
-| SC4 | Каскадная декомпозиция | Только скилы декомпозиции создают тикеты |
-| SC5 | Горизонт за пределами плана | Future-задачи → рекомендации, не тикеты |
-| SC6 | Каскад исполнение→план→декомпозиция | 3 уровня защиты в скиле исполнения |
-| SC7 | Автодекомпозиция без human-approval | Только планы со `status: approved` |
-
-## Масштабирование (M)
-
-| # | Антипаттерн | Как исправить |
-|---|------------|---------------|
-| M1 | Нет маркеров расширения | `<!-- РАСШИРЕНИЕ: ... -->` в конец |
-| M2 | Жёсткая привязка | Параметризовать или вынести в конфиг |
-| M3 | Нет инструкций по расширению | Секция «Как расширять» в README |
-
-<!-- РАСШИРЕНИЕ: добавляй новые антипаттерны ниже -->

package/src/skills/coach/knowledge/prompt-engineering.md

@@ -1,45 +0,0 @@
-# Prompt Engineering для скилов
-
-Принципы написания эффективных инструкций в SKILL.md и воркфлоу.
-
-## Роль
-
-| Принцип | Плохо | Хорошо |
-|---------|-------|--------|
-| Конкретность | «Ты — полезный помощник» | «Ты — Growth Marketing Lead в команде из 5 человек» |
-| Границы | Только «Ты делаешь» | «Ты делаешь» + «Ты НЕ делаешь» |
-| Контекст | Без контекста команды | С RACI-матрицей и связками ролей |
-
-## Воркфлоу
-
-1. **Глагол в начале** — «Определи», «Собери», «Проверь», не «Нужно определить»
-2. **Ссылки на знания** — каждый шаг с данными ссылается на источник (`→ knowledge/module.md`)
-3. **Чеклисты** — завершай воркфлоу проверочным списком
-4. **Условия** — развилки описывай оба пути явно
-5. **Нет «подумай»** — заменяй на конкретный метод/алгоритм
-
-## Knowledge
-
-1. **Факты, не мнения** — «CAC < LTV/3» вместо «CAC должен быть маленьким»
-2. **Источники** — откуда данные
-3. **Пороги числами** — «> 3x» вместо «значительно выше»
-4. **Структура** — таблицы, категории, маркер `<!-- РАСШИРЕНИЕ -->`
-
-## Algorithms
-
-1. **Детерминированность** — одинаковый вход → одинаковый выход
-2. **Числовые пороги** — «если score > 7» вместо «если оценка высокая»
-3. **Граничные случаи** — что делать если данных нет
-4. **Структура:** Вход → Алгоритм → Выход → Пример
-
-## Антипаттерны
-
-| Антипаттерн | Решение |
-|-------------|---------|
-| «Будь креативным» | Укажи конкретный метод |
-| «Учти все факторы» | Перечисли факторы и веса |
-| «При необходимости» | Укажи конкретное условие |
-| Длинные абзацы | Таблицы, списки, чеклисты |
-| Дублирование | Один источник правды + ссылки |
-
-<!-- РАСШИРЕНИЕ: добавляй новые принципы prompt engineering ниже -->

package/src/skills/coach/knowledge/shared-knowledge-guide.md

@@ -1,44 +0,0 @@
-# Shared Knowledge — межскиловые знания
-
-Когда knowledge-модуль нужен 2+ скилам — он выносится в `skills/shared/`.
-
-## Структура
-
-```
-skills/
-├── shared/               # Проектно-специфичные знания, общие для нескольких скилов
-│   ├── README.md         # Индекс: таблица модулей с описанием и списком потребителей
-│   └── module.md
-├── skill-a/
-└── skill-b/
-```
-
-## README.md — обязательный индекс
-
-```markdown
-# Shared Knowledge Modules
-
-| Модуль | Описание | Используется в |
-|--------|----------|----------------|
-| `module-name.md` | Что содержит | skill-a, skill-b |
-```
-
-## Правила
-
-| Правило | Описание |
-|---------|----------|
-| **Критерий выноса** | Контент используется 2+ скилами с пересечением 70%+ |
-| **Скилы — универсальные, shared — проектный** | Скилы переносятся между проектами as-is. Shared содержит проектно-специфичные знания |
-| **Ссылка из скила — через glob** | В таблице загрузки: `../shared/*` → «проверь индекс, загрузи релевантные». Не хардкодить имена модулей |
-| **Domain-контекст — в скиле** | Специфичная интерпретация shared-знаний остаётся в knowledge/workflows скила |
-
-## Антипаттерны
-
-| Антипаттерн | Как правильно |
-|-------------|---------------|
-| Дублировать данные в knowledge/ нескольких скилов | Вынести в shared/ |
-| Хардкодить `../shared/module.md` в SKILL.md | `../shared/*` → проверить README |
-| Класть в shared/ knowledge одного скила | Оставить в knowledge/ скила |
-| Вкладывать shared/ в конкретный скил | shared/ — на одном уровне со скилами |
-
-<!-- РАСШИРЕНИЕ: добавляй правила shared knowledge ниже -->

package/src/skills/coach/knowledge/skill-anatomy.md

@@ -1,49 +0,0 @@
-# Эталонная анатомия скила
-
-Справочник по структуре и содержанию идеального скила workflow-ai.
-
-## Обязательная структура директорий
-
-```
-skill-name/
-├── SKILL.md              # Ядро: роль, маршрутизация, принципы
-├── README.md             # Документация для людей
-├── workflows/            # Пошаговые алгоритмы по типам тикетов
-├── knowledge/            # Экспертные знания домена
-├── algorithms/           # Формализованные методы принятия решений
-└── templates/            # Шаблоны вывода
-```
-
-## SKILL.md — обязательные секции
-
-| Секция | Критерий качества |
-|--------|-------------------|
-| **Frontmatter** (name, description, ticket_prefix) | description 2-3 предложения, prefix уникален |
-| **Роль** (делает / не делает) | Конкретно, без абстракций |
-| **Маршрутизация** (тип → триггеры → воркфлоу) | Каждый тип → свой файл. **Только собственные типы** |
-| **Загрузка знаний/алгоритмов/шаблонов** | Все файлы перечислены с условиями загрузки |
-| **Принципы** (3-7) | Actionable, не декларативные |
-| **Формат вывода** | Специфичен для домена |
-| **Границы компетенции** | Перечислены смежные зоны с указанием куда направить |
-
-## ⛔ Принцип изоляции скилов
-
-Скилы НЕ знают о других скилах по имени. Используй: «любой скил проекта», generic ID (XXX-NNN).
-
-**Изоляция от project-wide типов:** не хардкодить типы из `config.yaml:task_types`. Маршрутизация — по собственным типам скила, не по project-wide.
-
-## Требования к качеству компонентов
-
-| Компонент | Ключевые требования |
-|-----------|--------------------|
-| **Workflows** | Пронумерованные шаги, ссылки на knowledge/algorithms, чеклисты завершения |
-| **Knowledge** | Таблицы/списки, маркер `<!-- РАСШИРЕНИЕ -->`, формулы явно, источники |
-| **Algorithms** | Вход → алгоритм → выход, пороги числами, пример применения |
-| **Templates** | Обязательные/опциональные поля, placeholder-подсказки, markdown |
-| **README.md** | Название, структура, flow, как расширять |
-
-## Shared Knowledge
-
-При создании/аудите скила → загрузи `knowledge/shared-knowledge-guide.md` для правил межскиловых знаний.
-
-<!-- РАСШИРЕНИЕ: добавляй новые требования к анатомии скила ниже -->

package/src/skills/coach/knowledge/test-authorship.md

@@ -1,141 +0,0 @@
-# Авторство тест-кейсов регрессионных тестов скилов
-
-Руководство для коуча по написанию тест-кейсов при работе с регрессионными тестами скилов.
-
----
-
-## 1. Дерево выбора слоя (L0 / L1 / L2)
-
-Выбери слой по первому подходящему условию:
-
-| Слой | Название | Когда использовать |
-|------|----------|-------------------|
-| **L0** | static | **Всегда** — если нужно проверить, что агент записал конкретный инвариант в файл (наличие раздела, запрета, поля). Не зависит от модели. |
-| **L1** | deterministic | Когда у output есть наблюдаемая сигнатура: структура YAML/JSON, наличие обязательных ключей, формат ID. Подходит, если ответ детерминирован при заданном входе. |
-| **L2** | rubric | Когда нужно проверить **принцип рассуждения** агента: правильно ли выбрана root cause, корректно ли применён принцип. Оценивается поведение, а не текст. |
-
-Правило: если сомневаешься между L0 и L1 — выбирай L0. L2 только тогда, когда L0/L1 физически не применимы.
-
----
-
-## 2. Правила написания static-anchor
-
-**Семантический инвариант, не дословный текст:**
-
-- Anchor должен выражать *правило*, нарушение которого тест должен поймать.
-- Anchor **отвергает** любое поведение, нарушающее правило, а не просто проверяет «строка существует в файле».
-- Один anchor — одно правило. Несколько правил → несколько anchor'ов.
-
-**Пример плохого anchor:** `"git commit"` — существует в любом упоминании темы.
-
-**Пример хорошего anchor:** `"коуч не выполняет git commit ни при каких условиях"` — семантически проверяет запрет, а не присутствие слова.
-
----
-
-## 3. Минимизация фикстуры
-
-- Фикстура — реальный артефакт ±20 строк вокруг инцидента.
-- **Не включай** в фикстуру весь лог или полный тикет.
-- Критерий минимума: убери строку → тест перестаёт проверять нужное поведение? Если нет — строка лишняя.
-- Для log-фикстур: вырезай только те шаги, где произошёл инцидент + 5 строк контекста до и после.
-
----
-
-## 4. Формулировка rubric-критерия
-
-Rubric проверяет **процесс рассуждения**, а не конкретный текст ответа:
-
-- Формулируй как: «Агент должен [определить / выбрать / проверить] [что именно] [по какому признаку]».
-- Не указывай конкретные слова, которые агент должен произнести — указывай логический шаг.
-- Rubric должен оставаться валидным при переформулировке инструкций скила.
-
-**Пример плохого rubric:** «Ответ содержит слово "root cause"».
-
-**Пример хорошего rubric:** «Агент идентифицировал физический скил-источник артефакта, а не предметный владелец».
-
----
-
-## 5. Выбор `target_agents[]` на уровне скила
-
-Заполняется автором-коучем вручную при первой настройке, сверяясь с `pipeline.yaml` проекта.
-
-Перечислить как минимум все модели, на которых скил реально гоняется в пайплайне:
-- основная модель скила,
-- fallback-модель (если задана),
-- модели из секций `agent_by_type` и `agent_by_attempt`.
-
-**Дополнительные модели для сравнения разрешены.** `target_agents[]` может включать модели сверх pipeline-набора — они выступают как «контрольная группа» для выявления регрессий формулировок скила на более широкой выборке. Такие модели помечаются комментарием (см. пример в `coach/tests/index.yaml`). Наличие «лишних» моделей — не ошибка и не повод сокращать список.
-
-Заполняется один раз в `tests/index.yaml` и наследуется всеми тест-кейсами скила. Не дублировать в каждом кейсе отдельно.
-
-**⛔ Сокращать `target_agents[]` (на уровне `index.yaml` или через per-case override) коуч не имеет права без явного согласия стейкхолдера.** Это относится к любому удалению модели из списка, включая случай «модель не используется в pipeline.yaml». Обоснование: `target_agents[]` — это заявленная сфера регрессии скила, а не техническая конфигурация; сокращение сужает покрытие тестов. См. подробный запрет ниже в секции «Override на уровне кейса».
-
-**Сверка с pipeline.yaml:**
-
-Runner автоматически проверяет каждый agent-id из `target_agents[]` против списка `agents` в `pipeline.yaml`. Если агент не найден — fail-fast с сообщением:
-
-```
-Agent 'invalid-agent-id' from target_agents[] not found in pipeline.yaml → agents[]
-```
-
-Порядок резолва `pipeline.yaml`:
-1. Приоритет: `<project_root>/.workflow/config/pipeline.yaml` (через `find-root.mjs`)
-2. Fallback: `<package_root>/configs/pipeline.yaml`
-
-Путь к используемому файлу логируется при старте runner'а.
-
-**Override на уровне кейса:**
-
-Точечный override допустим — если конкретный тест-кейс требует другую модель, укажи `execution.target_agents[]` в файле кейса. Это переопределит значение из `index.yaml` для данного кейса.
-
-**⛔ Override target_agents — это решение стейкхолдера, не коуча.** Убирать модель из списка или сужать его — **изменение сферы тестирования**, не техническая правка. Коуч **не имеет права** проактивно применять per-case override target_agents при провале модели на тесте, даже если:
-- модель выдаёт нестабильные/обрезанные ответы;
-- есть прецедент в бэклоге, где похожий override уже применялся;
-- формально «модель физически не может пройти тест».
-
-Все эти случаи — повод **явно согласовать** с стейкхолдером в отдельном сообщении, показав: (а) диагностику, что именно модель не может сделать, (б) три варианта действий (оставить как есть с honest baseline / исследовать глубже / исключить), (в) дождаться выбора. Применение override без явного согласия — перекладывание решения стейкхолдера на коуча и нарушение **границ компетенции** (см. SKILL.md, раздел «Границы компетенции»).
-
-**Антипаттерн:** «в прецеденте X модель была исключена, применяю тот же паттерн молча». Прецедент — это не карт-бланш. Проверь: стейкхолдер явно запросил исключение в прецеденте или коуч предложил и получил согласие? Если второе — всегда повторяй согласование для нового случая, даже если кажется аналогичным.
-
-**CLI-флаги для запуска:**
-
-- `--agent <id>` — прогон только на конкретной модели из `target_agents[]`
-- `--primary-only` — только первая модель из `target_agents[]` (без fallback)
-
----
-
-## 6. Сравнение прогонов через git
-
-Для отслеживания регрессий между прогонами используй стандартные git-инструменты:
-
-| Задача | Команда |
-|--------|---------|
-| Посмотреть изменения в мета-файле | `git diff current/meta.json` |
-| История прогонов | `git log current/meta.json` |
-| Кто изменил конкретную строку | `git blame current/meta.json` |
-
-Никакой специальной инфраструктуры не требуется — `current/meta.json` версионируется как обычный файл.
-
----
-
-## 7. Кто делает commit
-
-**⛔ Коуч не выполняет `git add`, `git commit`, `git push`, `git checkout`, `git reset` ни при каких условиях.**
-
-Коммит `current/` делает **исключительно пользователь**.
-
-Роль коуча после прогона тестов:
-1. Сообщить verdict runner'а (pass / fail / error).
-2. Перечислить затронутые файлы.
-3. Остановиться — дальнейшие git-операции выполняет пользователь.
-
----
-
-## 8. Антипаттерны авторства
-
-| Антипаттерн | Почему плохо | Как правильно |
-|-------------|-------------|---------------|
-| Тестировать дословную формулировку инструкции | Хрупко: переформулировка инструкции ломает тест, не меняя поведение | Тестировать семантический инвариант правила |
-| Over-specifying expected output | Привязка к конкретным словам делает тест зависимым от стиля модели | Проверять принцип, а не точный текст |
-| Фикстура = полный лог/тикет | Тест медленный, нечитаемый, хрупкий к несвязанным изменениям | Минимальная фикстура ±20 строк вокруг инцидента |
-| L2 вместо L0 для проверки файла | L2 дороже и недетерминирован; если можно проверить файл — используй L0 | Выбирай наименьший подходящий слой |

package/src/skills/coach/templates/audit-report.md

@@ -1,39 +0,0 @@
-# Шаблон: Отчёт аудита скила
-
-```markdown
-# Аудит скила: {skill-name}
-
-**Дата:** {YYYY-MM-DD}
-**Тикет:** {COACH-NNN}
-
-## Общая оценка
-
-| Категория | Балл | Макс |
-|-----------|------|------|
-| Структура | {N} | 20 |
-| Полнота SKILL.md | {N} | 20 |
-| Качество воркфлоу | {N} | 20 |
-| Качество знаний и алгоритмов | {N} | 20 |
-| Связность и консистентность | {N} | 20 |
-| **Итого** | **{N}** | **100** |
-
-**Оценка:** {EXCELLENT / GOOD / NEEDS_WORK / POOR}
-
-## Найденные проблемы
-
-| # | Приоритет | Файл | Проблема | Рекомендация |
-|---|-----------|------|----------|-------------|
-| 1 | {CRITICAL/HIGH/MEDIUM/LOW} | {path} | {описание} | {что сделать} |
-
-## Антипаттерны / Gap-анализ
-
-| # | Тип | Описание | Где / Приоритет |
-|---|-----|----------|----------------|
-| 1 | {Антипаттерн/Gap} | {описание} | {файл:секция / приоритет} |
-
-## Сильные стороны (топ-3) / План улучшений
-
-| # | Сильная сторона | Улучшение | Приоритет | Трудозатраты |
-|---|----------------|-----------|-----------|-------------|
-| 1 | {что хорошо} | {что сделать} | {приоритет} | {быстро/средне/долго} |
-```

package/src/skills/coach/templates/coach-backlog-init.yaml

@@ -1,14 +0,0 @@
-version: 2
-last_updated: ""
-
-# Защита от повторного анализа тикетов/логов, не приведших к правке скила.
-# (Те, что привели к правке, имеют тест-кейс в src/skills/*/tests/cases/ — туда и смотрим.)
-analyzed_tickets: []
-
-# Snapshot scores скилов на момент аудита (trajectory во времени).
-audited_skills: []
-
-# История правок скилов — в git, не в этом файле:
-# git log -- src/skills/<name>/                    # все правки скила
-# git log -- src/skills/<name>/tests/cases/        # тест-кейсы
-# git log --follow -- src/skills/<name>/SKILL.md   # история файла

package/src/skills/coach/templates/coach-backlog-init.yaml.legacy

@@ -1,10 +0,0 @@
-# Шаблон инициализации бэклога коуча
-# Скопировать в .workflow/coach-backlog.yaml при первом запуске
-version: 1
-last_updated: ""
-
-analyzed_tickets: []
-
-applied_changes: []
-
-audited_skills: []

package/src/skills/coach/templates/improvement-plan.md

@@ -1,42 +0,0 @@
-# Шаблон: План улучшений скила
-
-```markdown
-# План улучшений: {skill-name}
-
-**Дата:** {YYYY-MM-DD}
-**Тикет:** {COACH-NNN}
-**Основание:** {ссылка на аудит / анализ / запрос}
-
-## Цель
-
-{Что хотим улучшить и почему — 1-2 предложения.}
-
-## Изменения
-
-| # | Название | Приоритет | Файлы | Проблема → Решение | Ожидаемый эффект |
-|---|----------|-----------|-------|--------------------|-----------------|
-| 1 | {название} | {CRITICAL/HIGH/MEDIUM/LOW} | {файлы} | {проблема → решение} | {эффект} |
-
-## Порядок выполнения
-
-{Последовательность: что делать первым, какие зависимости.}
-
-1. {Шаг 1} — зависит от: нет
-2. {Шаг 2} — зависит от: шаг 1
-...
-
-## Критерии успеха
-
-- [ ] {Критерий 1 — как проверить что улучшение работает}
-- [ ] {Критерий 2}
-- [ ] Все ссылки в SKILL.md валидны
-- [ ] Scoring скила вырос на {N} баллов
-
-## Источники
-
-{Если использовались внешние знания — ссылки с описанием.}
-
-| Источник | Что взято | Дата |
-|----------|----------|------|
-| {URL/название} | {что именно} | {YYYY-MM-DD} |
-```