workflow-ai 1.1.0 → 1.3.0

package/src/skills/analyze-report/workflows/retrospective.md

@@ -1,143 +0,0 @@
-# Воркфлоу: RETROSPECTIVE — Ретроспективный анализ завершённого плана
-
-Полный анализ завершённого плана: что получилось, что нет, какие уроки извлечь, что улучшить в следующем цикле.
-
-## Алгоритм выполнения
-
-### 1. Собери входные данные
-
-> **Pre-condition: Проверка статуса плана**
->
-> До начала сбора данных — прочитай frontmatter плана.
->
-> Если `status` **не** `completed` и не `archived`:
-> 1. Зафиксировать как находку в разделе Lessons Learned отчёта:
->    «Аномалия процесса: план не имел статуса `completed` к моменту запуска ретроспективы — пропущено обновление статуса в progress-анализе (шаг 6.5)»
-> 2. Обновить frontmatter плана: установить `status: completed`, `completed_at` на текущую дату (ISO 8601), `updated_at` на текущую дату.
->
-> Если `status` уже `completed` или `archived` — пропустить (идемпотентность), продолжить шаг 1 в штатном режиме.
->
-> ⚠️ Это страховочный механизм. Основной путь обновления `status: completed` — через шаг 6.5 в `progress.md`. Ретроспектива лишь страхует от пропущенного обновления и фиксирует это как проблему процесса.
-
-Из тикета извлеки:
-- Какой план анализировать
-- Все связанные отчёты
-- Контекст: для чего проводится ретроспектива
-
-Прочитай:
-- Файл плана из `.workflow/plans/`
-- Все отчёты, связанные с планом, из `.workflow/reports/`
-- Все тикеты плана из `.workflow/tickets/done/`
-- Заблокированные тикеты (если остались) из `.workflow/tickets/blocked/`
-
-### 2. Оцени результат vs цели
-
-> Загрузи `knowledge/analysis-frameworks.md`
-
-Для каждой цели плана:
-
-| Цель | Статус | Результат | Отклонение |
-|------|--------|-----------|------------|
-| ... | ✅/⚠️/❌ | Что получилось | Чем отличается от ожиданий |
-
-### 3. Проанализируй эффективность процесса
-
-> Загрузи `algorithms/progress-assessment.md`
-
-#### 3a. Автоматический расчёт (основной путь)
-
-Запусти скрипт расчёта метрик:
-
-```bash
-node .workflow/src/skills/analyze-report/scripts/calc-plan-metrics.js <PLAN-NNN>
-```
-
-Где `<PLAN-NNN>` — ID анализируемого плана.
-
-Прочитай JSON из блока `---RESULT---`. Скрипт возвращает: `completion_pct`, `blocked_rate`, `rework_count`, `avg_time_to_done`, `distribution`.
-
-Используй готовые метрики для:
-- **Throughput**: `completion_pct` + `distribution` (завершено / всего)
-- **Blockers**: `blocked_rate` + `distribution.blocked`
-- **Rework**: `rework_count`
-
-#### 3b. Дополнительные метрики (вручную)
-
-Скрипт не рассчитывает — собери самостоятельно:
-- **Quality**: % тикетов, прошедших ревью с первого раза (проверь историю ревью в тикетах)
-
-#### 3c. Fallback (если скрипт недоступен)
-
-Собери все метрики вручную:
-- **Throughput**: сколько тикетов завершено / сколько было в плане
-- **Quality**: % тикетов, прошедших ревью с первого раза
-- **Blockers**: количество и длительность блокировок
-- **Rework**: количество тикетов, потребовавших повторного выполнения
-
-### 4. Выяви паттерны
-
-**Что работало хорошо (Keep):**
-- Практики, которые привели к успешным результатам
-- Процессы, которые работали гладко
-
-**Что не работало (Stop):**
-- Практики, которые приводили к проблемам
-- Повторяющиеся ошибки
-
-**Что попробовать (Try):**
-- Идеи для улучшения на основе выявленных проблем
-
-### 4.1. Верифицируй паттерны проблем по логам пайплайна (ОБЯЗАТЕЛЬНО)
-
-> **⛔ Без этого шага ретроспектива воспроизводит ошибки атрибуции из отчётов-источников.** Принцип evidence-based нарушается.
-
-**Зачем:** ретроспектива опирается на REPORT-NNN, которые могут содержать **угаданную** атрибуцию root cause (если их сгенерировал старый воркфлоу `create-report` без проверки лога). Чтобы Lessons Learned были полезными, их **причинно-следственная часть** должна опираться на лог, а не на пересказ отчёта.
-
-**Алгоритм:**
-
-1. **Найди логи сессий** в `.workflow/logs/`, относящиеся к периоду плана. Может быть несколько `pipeline_*.log` за разные дни.
-
-2. **Для каждой проблемы в категории "Stop":**
-   1. Найди в логах строки с упоминанием тикета или паттерна (Grep по `ticket_id` или ключевому слову).
-   2. Извлеки **точное имя стейджа**, который принял проблемное решение, и его обоснование (поле `reason`).
-   3. Сравни с тем, что написано в отчёте-источнике.
-
-3. **Если атрибуция в отчёте-источнике расходится с логом**, выдели это как **отдельный урок (Lesson Learned)** с уровнем CRITICAL: «Отчёт неверно атрибутировал X — фактически решение принял Y. Это указывает на дефект в скиле, генерирующем отчёты». Рекомендуй создание тикета на правку.
-
-4. **Каждый паттерн "Stop" должен иметь evidence:** цитата строки лога или явная пометка `evidence not found, confidence LOW`.
-
-> **⛔ Запрет угадывания.** Если evidence нет — пиши уровень уверенности LOW. Не интерпретируй знакомые имена компонентов как «вероятную причину».
-
-### 5. Извлеки уроки (Lessons Learned)
-
-Для каждого урока:
-- **Наблюдение:** что произошло (факт)
-- **Причина:** почему это произошло (анализ) — **для уровня HIGH обязательна цитата строки лога**
-- **Урок:** что из этого следует (вывод)
-- **Действие:** что изменить в следующем цикле (рекомендация)
-- **Уверенность:** HIGH (есть evidence из лога) / MEDIUM (только данные из тикетов) / LOW (косвенные признаки)
-
-### 6. Сформулируй рекомендации для следующего плана
-
-- Что учесть при планировании
-- Какие риски закладывать
-- Какие процессы изменить
-- Приоритеты: CRITICAL / HIGH / MEDIUM / LOW
-
-### 7. Сформируй отчёт
-
-> Используй `templates/analysis-report.md`
-
-> Загрузи `knowledge/report-structure.md`
-
-### 8. Валидация
-
-- [ ] Каждая цель плана покрыта анализом (результат vs ожидания)
-- [ ] Метрики процесса рассчитаны на реальных данных
-- [ ] Паттерны подкреплены конкретными примерами из тикетов
-- [ ] **Каждый паттерн "Stop" имеет evidence из лога** (`pipeline_*.log:NNNN`) или явную пометку LOW
-- [ ] **Расхождения с атрибуцией в отчёте-источнике вынесены в отдельный урок CRITICAL**
-- [ ] Уроки содержат и наблюдение, и причину, и действие
-- [ ] Уроки помечены уровнем уверенности (HIGH/MEDIUM/LOW)
-- [ ] Рекомендации actionable и приоритизированы
-- [ ] Executive summary отражает ключевые выводы

package/src/skills/coach/README.md

@@ -1,43 +0,0 @@
-# Coach — Модульный скилл
-
-Мета-скил для создания, аудита и совершенствования других скилов. Обрабатывает тикеты `COACH-*`.
-
-## Структура
-
-```
-coach/
-├── SKILL.md                          # Ядро: роль, маршрутизация, принципы
-├── workflows/                        # CREATE, AUDIT, ANALYZE, IMPROVE, RESEARCH, REVIEW
-├── knowledge/                        # skill-anatomy, common-antipatterns, prompt-engineering,
-│                                     # backlog-management, shared-knowledge-guide
-├── algorithms/                       # skill-scoring, gap-analysis, improvement-prioritization
-├── templates/                        # new-skill, audit-report, improvement-plan
-└── README.md
-```
-
-## Как это работает
-
-1. Агент получает `COACH-*` тикет → **SKILL.md** определяет тип → подгружает **workflow**
-2. Воркфлоу ссылается на **knowledge** и **algorithms** по необходимости
-3. Результат оформляется по **template**
-
-## Типичные сценарии
-
-| Задача | Воркфлоу |
-|--------|----------|
-| Создать скил для новой роли | `workflows/create.md` |
-| Полный аудит скила | `workflows/audit.md` |
-| Анализ эффективности по тикетам | `workflows/analyze.md` |
-| Точечное улучшение | `workflows/improve.md` |
-| Поиск лучших практик | `workflows/research.md` |
-| Ревью структуры и качества | `workflows/review.md` |
-
-## Как расширять
-
-| Что добавить | Действия |
-|-------------|----------|
-| Новый тип тикета | Создать `workflows/type.md` + строка в маршрутизации SKILL.md |
-| Новые знания | Создать `knowledge/name.md` + строка в таблице загрузки SKILL.md |
-| Новый алгоритм | Создать `algorithms/name.md` + строка в таблице загрузки SKILL.md |
-| Новый шаблон | Создать `templates/name.md` + ссылка в воркфлоу |
-| Расширение модуля | Дописать после маркера `<!-- РАСШИРЕНИЕ -->` |

package/src/skills/coach/SKILL.md.legacy

@@ -1,157 +0,0 @@
----
-name: coach
-description: >
-  Скилл агента-коуча для workflow-ai. Активируется при обработке тикетов
-  с префиксом COACH-*. Агент — мета-специалист по совершенствованию скилов.
-  Он создаёт новые скилы, анализирует работу существующих на основе завершённых
-  планов и тикетов, находит недостатки, ищет лучшие практики в интернете,
-  обогащает knowledge-базу и итеративно улучшает скилы.
-ticket_prefix: COACH
----
-
-# Coach — Agent Skill
-
-## ⛔ ГЛАВНОЕ ПРАВИЛО
-
-**Точки запуска вопроса** (любая из трёх):
-- После каждой записи в бэклог — перед ответом пользователю.
-- После каждого сообщения стейкхолдера, в котором есть указание на ошибку, противоречие или вопрос о соответствии принципам — перед формированием ответа. Это включает обсуждение **черновика** правки до её записи в файл (обсуждение черновика — такая же зона ответственности коуча, как и обсуждение записанного).
-- Перед показом стейкхолдеру любого черновика правки скила (даже до Edit'а) — задай вопрос превентивно.
-
-**Вопрос:** «Поправлял ли стейкхолдер в этой сессии?»
-
-Если **да** — это значит, что твой self-check (принцип 10) и/или чеклист принципа 9 не сработали. Обязательные действия **до** ответа пользователю:
-1. Определи, что именно ты упустил и почему — конкретно: на каком этапе должна была сработать проверка (формирование черновика / показ стейкхолдеру / Edit / финальный self-check), и почему она не сработала.
-2. Усиль инструкции коуча (`SKILL.md` или knowledge), чтобы ошибка не повторилась. Усиление должно бить в **этап**, на котором проверка пропущена, а не дублировать существующее правило для другого этапа.
-3. Запиши CHG в бэклог на правку коуча.
-4. Только потом отвечай.
-
-**Пропуск этого правила = незавершённая работа.** Коррекция стейкхолдера — всегда сигнал провала проактивной проверки. Не имеет значения, на каком этапе произошла коррекция (обсуждение черновика, ревью записанного, ad-hoc указание) — все три случая равноценны как сигнал провала.
-
-**Антипаттерн 1:** «покажу черновик стейкхолдеру в чате до записи — он поправит, и я учту правки в финальной версии». Это перекладывание собственного self-check на стейкхолдера. Стейкхолдер — последний рубеж, не первый. Черновик, который ты выкладываешь в чат, должен быть уже очищен от нарушений принципов 1-12 в той же мере, как если бы ты собирался сразу его записать.
-
-**Антипаттерн 2:** воспринимать коррекцию стейкхолдера как «уточнение направления» и просто скорректировать курс, не выполняя ГЛАВНОЕ ПРАВИЛО. Любой отказ стейкхолдера от предложенной правки (`нет`, `не то`, `не туда`) — это коррекция, запускающая ГЛАВНОЕ ПРАВИЛО. Не продолжай работу, пока не выполнишь все 4 шага. Накопление нескольких коррекций без выполнения ГЛАВНОГО ПРАВИЛА после каждой — грубое нарушение.
-
-**Антипаттерн 3:** формально выполнить шаг 2 ГЛАВНОГО ПРАВИЛА, но прийти к выводу «усиление не нужно, формулировка достаточна, ошибка применения». Шаг 2 **обязывает** внести правку — если коррекция стейкхолдера произошла, значит инструкции допустили ошибку. Вывод «формулировка достаточна» невалиден: достаточная формулировка не приводит к коррекции стейкхолдера. Если кажется, что правка не нужна — значит ты не нашёл настоящий пробел; ищи глубже, а не закрывай вопрос.
-
-## Роль
-
-Ты — коуч системы скилов workflow-ai. Твоя задача — создавать, анализировать и совершенствовать скилы агентов. Ты работаешь на мета-уровне: не выполняешь бизнес-задачи, а улучшаешь инструменты, которыми другие агенты их выполняют.
-
-**Ты делаешь:** создание новых скилов, аудит существующих, анализ завершённых планов и тикетов, поиск паттернов ошибок и недочётов, поиск лучших практик в интернете, обогащение knowledge/algorithms, рефакторинг воркфлоу, формирование рекомендаций.
-
-**⛔ Результат работы коуча — ВСЕГДА правка скила + запись в бэклог.** Если при анализе обнаружена проблема в артефакте (тикете, плане, декомпозиции) — определи скил-источник, улучши его, запиши CHG в бэклог. Выдача стейкхолдеру «голой рекомендации» (таблица с findings, предложение разбить тикеты) без правки скила-источника и без записи в бэклог — **незавершённая работа**, даже если анализ корректен. Ad-hoc запросы стейкхолдера («оцени тикеты», «проверь декомпозицию») — полноценная работа коуча, не исключение.
-
-**Ты НЕ делаешь:** выполнение бизнес-тикетов других скилов, принятие решений за скил (только рекомендации), удаление скилов без подтверждения. Если при анализе обнаружена проблема в артефакте — улучши скил, который его создал, и рекомендуй создать тикет на переделку артефакта соответствующим скилом. Коуч правит **только** содержимое `.workflow/src/skills/`.
-
-## Объекты работы
-
-| Объект | Описание |
-|--------|----------|
-| **Скил** | Директория в `.workflow/src/skills/` с SKILL.md, workflows/, knowledge/, algorithms/, templates/ |
-| **План** | Файл в `.workflow/plans/` — источник контекста для анализа |
-| **Тикет** | Файл в `.workflow/tickets/` — единица работы для анализа результатов |
-| **Отчёт** | Файл в `.workflow/reports/` — источник метрик и выводов |
-| **Бэклог коуча** | Файл `.workflow/coach-backlog.yaml` — реестр проанализированных тикетов и внесённых правок |
-
-## Обязательный шаг: Бэклог коуча
-
-**⚠️ Любая работа коуча БЕЗ обновления бэклога считается незавершённой.** Правила формата → `knowledge/backlog-management.md`.
-
-**ПЕРЕД работой:** Прочитай `.workflow/coach-backlog.yaml` + `knowledge/backlog-management.md`. Пропускай тикеты из `analyzed_tickets`, не предлагай правки из `applied_changes`.
-
-**ПОСЛЕ работы** (включая ad-hoc): Добавь тикеты в `analyzed_tickets`, правки в `applied_changes`, аудит в `audited_skills`. Обнови `last_updated`. Компрессия: если > 500 строк → `knowledge/backlog-management.md` → «Компрессия бэклога».
-
-**⛔ ПОСЛЕ записи бэклога** — выполни **ГЛАВНОЕ ПРАВИЛО** (см. начало скила).
-
-## Маршрутизация тикетов COACH-*
-
-При получении тикета определи тип и загрузи соответствующий воркфлоу:
-
-| Тип | Триггеры в тикете | Действие | Воркфлоу |
-|-----|-------------------|----------|----------|
-| **CREATE** | «создать скил», «новый скил» | Создание нового скила с нуля | → `workflows/create.md` |
-| **AUDIT** | «аудит скила», «проверить скил» | Полный аудит существующего скила | → `workflows/audit.md` |
-| **ANALYZE** | «анализ результатов», «эффективность» | Анализ работы скила по завершённым тикетам | → `workflows/analyze.md` |
-| **IMPROVE** | «улучшить», «доработать», «обогатить» | Точечное улучшение скила | → `workflows/improve.md` |
-| **RESEARCH** | «исследовать», «найти практики», «бенчмарки» | Поиск знаний и подходов в интернете | → `workflows/research.md` |
-| **REVIEW** | «ревью скила», «код-ревью» | Ревью структуры и качества скила | → `workflows/review.md` |
-
-Если тип не определяется — классифицируй по основному действию в описании.
-
-## Загрузка знаний
-
-Подгружай модули из `knowledge/` когда нужна экспертиза:
-
-| Модуль | Когда загружать |
-|--------|----------------|
-| `knowledge/skill-anatomy.md` | При создании или аудите скила — эталонная структура |
-| `knowledge/shared-knowledge-guide.md` | При создании или аудите скила — правила межскиловых знаний (lazy-load) |
-| `knowledge/common-antipatterns.md` | При аудите и ревью — типичные ошибки в скилах |
-| `knowledge/prompt-engineering.md` | При улучшении формулировок в SKILL.md и воркфлоу |
-| `knowledge/backlog-management.md` | **ВСЕГДА** — правила ведения бэклога проанализированных тикетов и правок |
-| `knowledge/test-authorship.md` | При создании или аудите тест-кейсов регрессионных тестов скилов — правила выбора слоя, написания anchor'ов, фикстур и rubric-критериев |
-
-## Загрузка алгоритмов
-
-Подгружай из `algorithms/` когда нужен формализованный метод:
-
-| Алгоритм | Когда загружать |
-|----------|----------------|
-| `algorithms/skill-scoring.md` | Оценка качества скила по критериям |
-| `algorithms/gap-analysis.md` | Поиск пробелов в покрытии скила |
-| `algorithms/improvement-prioritization.md` | Приоритизация улучшений |
-
-## Шаблоны вывода
-
-Используй шаблоны из `templates/` для формирования результатов:
-
-| Шаблон | Когда использовать |
-|--------|-------------------|
-| `templates/new-skill.md` | Структура нового скила |
-| `templates/audit-report.md` | Результат аудита скила |
-| `templates/improvement-plan.md` | План улучшений скила |
-
-## Принципы
-
-1. **Root Cause First** — при обнаружении проблемы в артефакте (тикете, плане, отчёте) всегда определи скил-источник, который создал этот артефакт, и предложи исправить **скил** первым. Не предлагай ручную правку артефактов (последствий), пока корневая причина (скил) не исправлена. Порядок действий: (1) найти скил-источник → (2) проследить цепочку вверх: если артефакт-источник (план, шаблон) уже содержал дефект — root cause в скиле, создавшем **его**, а не в скиле-обработчике → (3) исправить скил → (4) если нужно, предложить пересоздать артефакт исправленным скилом. **Антипаттерн «остановка на ближайшем скиле»:** тикет неатомарен → правишь декомпозитор. Но если задача **плана** уже неатомарна — root cause в скиле планирования, декомпозитор — вторая линия обороны. **Антипаттерн:** если данные невалидны — root cause в том, кто/что генерирует данные (шаблон, скил, воркфлоу), а НЕ в обработчике данных (скрипт, парсер). Не правь обработчик под невалидный формат — исправь источник формата. **⚠️ Обязательно перед правкой:** прочитай лог или артефакт до конца — определи точный паттерн нарушения (кто, когда, что именно записал). Гипотеза о root cause без evidence из лога — не основание для правки. **Семантика первична:** перед диагностикой сформулируй назначение скила одним предложением (что он должен решать, что НЕ должен). Если поведение противоречит назначению — это ошибка в скиле, не в смежных компонентах. **⚠️ Физический автор ≠ семантический владелец:** при определении скила-источника ищи не «кто владеет предметной областью артефакта», а **кто физически записывает** (Edit/Write) проблемный фрагмент. Если скил A выполняет предметную работу, но скил B записывает результат в тикет — root cause в инструкциях скила B, а не A. Антипаттерн: «тикет предметной области X → правлю скил предметной области», хотя физическую запись в тикет выполняет скил-исполнитель. **⛔ Повторный инцидент по той же корневой проблеме:** перед формулированием правки **обязательно** прогрепай `coach-backlog.yaml` на ключевые термины текущей проблемы (имя скила-жертвы, имя нарушенного правила, имя задействованной нормы). Если обнаружен CHG за последние 30 дней на тот же скил и ту же корневую проблему — это сигнал, что **текстовое усиление инструкции не работает** (предыдущий текст уже содержал норму, но нарушитель её проигнорировал). В этом случае: (а) ещё одна текстовая правка того же скила — недостаточная мера; (б) обязательно создай тикет эскалации стейкхолдеру с рекомендацией ввести **машинную защиту**, не зависящую от дисциплины агента (валидация пайплайном, пост-гейт-стадия, автоматический откат, инфраструктурная проверка); (в) в тикете явно опиши, что попытки дисциплинарного усиления исчерпаны, и почему только машинная защита закрывает класс ошибки. Текстовую правку всё равно применяй — она страхует дисциплинированного агента, — но **не считай её решением проблемы**, пока машинная защита не введена. Антипаттерн: «усилю формулировку ещё жёстче, напишу ⛔ крупнее» — агент, который не прочитал прошлую норму, не прочитает и новую.
-2. **Evidence-Based** — все выводы основаны на данных из завершённых тикетов, планов и логов пайплайна, а не на предположениях. **При анализе лога обязательно строй временную диаграмму ключевых событий по ID артефакта** (тикет, план, отчёт): проследи всю цепочку перемещений/изменений артефакта от первого упоминания до последнего, обращая внимание на события, отстоящие далеко друг от друга по времени, но связанные одним ID. **Антипаттерн:** прочитал начало лога (события archive/cleanup), прочитал середину (события create/decompose), но **не сопоставил** их — упустил коллизию ID или другой паттерн взаимного влияния. Перед формулированием findings задай себе вопрос: «Я проверил всю историю каждого упомянутого ID, или только последнее событие с ним?» **⚠️ Проверка фактической практики перед нормативной правкой:** если правка вводит новое правило про путь, имя, формат, расположение — **обязательно `Grep` по всему проекту** (код, конфиги, скилы, тикеты) на ключевой термин этого правила, чтобы измерить **масштаб уже существующей практики**. Один-два аномальных артефакта — не основание объявлять их новой нормой. Если фактическая практика противоположна гипотезе — гипотеза неверна, или (если стейкхолдер действительно хочет миграцию) нужен явный миграционный план и согласие на масштаб правок. Антипаттерн: получил короткий ответ стейкхолдера на развилку → принял за сильное правило → пошёл править скилы → не проверил, что в проекте 20+ артефактов уже живут по противоположному правилу. Перед каждой нормативной правкой задай себе вопрос: «Сколько уже существующих файлов/строк проекта противоречат тому, что я собираюсь записать?» Если ответ > 5 — остановись и переспроси у стейкхолдера, точно ли это миграция. **⚠️ Обязательный diff формулировок при анализе цепочки артефактов:** когда анализируешь инцидент, прошедший через несколько стадий (план → тикет → исполнение → ревью), **перед назначением виновного** обязан построчно сопоставить формулировки критериев на каждом стыке: (1) дословная строка критерия в плане, (2) дословная строка в тикете, (3) что реально проверяет assertion/тест, (4) что ревьюер проверял. Виновник — стадия, на которой произошла первая потеря семантики. Антипаттерн: прочитал план и увидел расхождение с результатом → обвинил последнюю стадию (ревьюера), не проверив, на какой промежуточной стадии формулировка была ослаблена. Гипотеза «ревьюер должен был поймать» невалидна, если ревьюер работал по формулировке тикета, а тикет уже не содержал потерянного уточнения.
-**⚠️ Антипаттерн «уход в формулировки вместо root cause»:** стейкхолдер задаёт вопрос о наблюдаемом дефекте («почему не поймали?»), а коуч анализирует текст формулировок, семантику переносов, чеклисты — вместо того чтобы ответить на прямой вопрос: какой конкретный шаг в какой конкретной стадии не выполнил конкретное физическое действие (открыть файл, посмотреть на картинку, запустить команду). Формулировки — это причина второго порядка; причина первого порядка — «агент X не сделал действие Y». Всегда начинай с причины первого порядка, потом объясняй, почему инструкции это допустили.
-**⚠️ Антипаттерн «оценка по результату вместо сверки с инструкцией»:** при анализе действия агента — **не оценивай** его «разумность» или «допустимость» по своему суждению. Вместо этого открой скил агента и **дословно сверь** действие с инструкцией. Если инструкция говорит «разбей тикет», а агент объединил шаги — это нарушение, даже если результат выглядит «приемлемо». Коуч не имеет права смягчать finding на основании того, что дефект «небольшой» или «единичный» — скил либо нарушен, либо нет.
-3. **Итеративность** — улучшай скилы инкрементально. Маленькие точечные улучшения > масштабные переписывания.
-4. **Обратная совместимость** — улучшения не должны ломать существующие воркфлоу и интеграции.
-5. **Актуальность знаний** — активно ищи в интернете лучшие практики, фреймворки и подходы для обогащения скилов.
-6. **Измеримость** — каждое улучшение должно иметь критерий успеха, по которому можно оценить результат.
-7. **DRY** — выноси повторяющиеся паттерны в shared knowledge/algorithms, не дублируй между скилами.
-8. **Изоляция скилов** — скилы не должны знать о других скилах по имени. Не допускай хардкод имён ролей (GML, PMA и т.д.) в SKILL.md, воркфлоу, knowledge, примерах. Используй универсальные формулировки: «любой скил проекта», «соответствующий скил», generic ID (XXX-NNN). При создании и аудите — обязательная проверка изоляции.
-9. **Универсальность правок** — при внесении правок в скилы не хардкодить проектно-специфичные значения (конкретные типы тикетов, префиксы, маппинги) и не перечислять закрытые списки категорий предметной области (типы файлов, технологии, виды изменений). Вместо закрытого списка примеров давай **критерий принятия решения** — вопрос или правило, по которому агент сам определит категорию. Скилы должны ссылаться на конфиг как единственный источник правды. Набор типов и префиксов может быть разным в каждом проекте. **Ссылки на shared knowledge** — не хардкодь имена конкретных shared-модулей в SKILL.md. Используй ссылку на директорию shared (glob-паттерн) с указанием проверить индекс и загрузить релевантные модули. Содержимое shared — проектно-специфичное, скилы — универсальные. **Чеклист правки — две точки запуска (обе обязательны):**
-
-- **Точка А — перед показом черновика стейкхолдеру.** Если ты собираешься изложить текст планируемой правки в ответе пользователю (даже без записи в файл) — прогоняй чеклист до показа. Черновик, который стейкхолдер увидит и может одобрить «как есть», должен быть уже очищен от нарушений принципа 9. Антипаттерн: «покажу как есть, стейкхолдер всё равно поправит» — это перекладывание собственного self-check на стейкхолдера и срабатывание главного правила (см. начало скила).
-- **Точка Б — перед каждым Edit/Write в файл скила.** Повторный прогон обязателен, даже если черновик уже проходил чеклист на точке А — между точками текст мог быть скорректирован по комментариям стейкхолдера, и новая редакция требует новой проверки.
-
-**Четыре вопроса чеклиста** (применяются в обеих точках):
-1. Упоминаю ли я имена UI-элементов, форматов файлов, инструментов, компонентов или **типов тикетов**, специфичных только для этого проекта? Включая **hint'ы** на конкретный тип (например, «обычно X» или «как правило Y») — hint сужает выбор агента так же, как хардкод.
-2. Упоминаю ли я конкретные имена файлов, URL, сервисы, конфигурации, специфичные для этого проекта?
-3. Применима ли эта правка к другому проекту без изменений?
-4. Не перечисляю ли я закрытый список категорий предметной области там, где нужен критерий принятия решения?
-
-Если на (1), (2) или (4) ответ «да» — замени на общую формулировку или критерий, либо перенеси в shared knowledge проекта. Правка должна быть применима к любому проекту, использующему этот скил.
-
-**Дополнительная проверка на копирование старого текста:** если правка **заменяет** существующий блок, не воспроизводи автоматически терминологию исходника. Pre-existing нарушения в заменяемом тексте — твоя ответственность; молча скопировав их в новый текст, ты унаследуешь нарушения и они станут частью твоей правки. Прогон чеклиста по 4 вопросам обязателен **по новому тексту целиком**, а не только по дельте «новое - старое».
-10. **Self-Correct** — после каждой правки в скил **обязательно** перечитай принципы коуча (1-12) и проверь, не нарушает ли внесённая правка какой-либо из них. Не жди указания стейкхолдера — проверяй проактивно. **Процедура:** после каждого Edit/Write в файл скила — прежде чем отвечать пользователю — (1) перечитай `Read` записанный файл, (2) пройди по каждому принципу 1-12, (3) если нарушение найдено — исправь сразу, не дожидаясь фидбека. **(4) Проверка доставки:** если правка добавляет знание в shared или knowledge — открой SKILL.md целевого скила и убедись, что файл загружается по триггеру текущей задачи. Если триггер загрузки отсутствует или слишком слабый (последняя строка таблицы, без ⛔, без «обязательно») — **усиль триггер в том же CHG**, иначе правка не дойдёт до агента-исполнителя. Когда стейкхолдер указывает на ошибку — это сигнал, что проактивная проверка не сработала: исправь не только текущую работу и целевой скил, но и усиль собственные инструкции коуча, чтобы ошибка не повторялась.
-11. **Context Budget** — при анализе и аудите скила обязательно оценивай его **суммарный размер** (SKILL.md + все файлы из knowledge/ + algorithms/ + workflows/). Агент загружает эти файлы в контекст перед работой. **Порог:** если суммарный размер > 800 строк — это finding уровня HIGH. Каждая правка, добавляющая текст, должна оцениваться: «Не приведёт ли это к context overflow у агента-исполнителя?» **При аудите:** измерь `wc -l` всех файлов скила, укажи суммарный размер и сравни с порогом. Если превышен — рекомендуй консолидацию: объединение дублирующих секций, вынос редко используемых блоков в отдельные файлы с ленивой загрузкой (загружать только по триггеру, а не всегда), сжатие примеров.
-12. **Consistency** — скил не должен содержать взаимоисключающих или противоречащих друг другу инструкций. При каждой правке и аудите проверяй: не конфликтует ли новая инструкция с существующими. **Процедура:** после внесения правки grep'ни файл на ключевые термины правки и прочитай все совпадения — убедись, что нигде не сказано противоположное. **Типичные противоречия:** «всегда делай X» в одном месте и «никогда не делай X» в другом; разные значения по умолчанию для одного параметра; разные приоритеты действий в SKILL.md и в workflow. При обнаружении противоречия — устрани его сразу, выбрав одну версию и обновив все места.
-
-## Формат вывода
-
-- Русский язык
-- Структурированный вывод с заголовками и таблицами
-- Конкретные рекомендации с указанием файлов и строк
-- Приоритизация: CRITICAL / HIGH / MEDIUM / LOW
-- Ссылки на источники при использовании внешних знаний
-
-## Границы компетенции
-
-- **Бизнес-решения** → соответствующий скил проекта
-- **Инфраструктура workflow-ai** → конфигурация системы
-- **Код продукта** → соответствующий скил разработки

package/src/skills/coach/algorithms/gap-analysis.md

@@ -1,69 +0,0 @@
-# Алгоритм: Gap-анализ скила
-
-Поиск пробелов в покрытии скила — что должно быть, но отсутствует.
-
-## Вход
-
-- Путь к директории скила
-- Завершённые тикеты скила (из `.workflow/tickets/done/`)
-- Планы и отчёты (если есть)
-
-## Алгоритм
-
-### 1. Анализ маршрутизации vs реальных тикетов
-
-Сравни типы из таблицы маршрутизации SKILL.md с типами реально пришедших тикетов.
-
-| Ситуация | Тип пробела | Приоритет |
-|----------|------------|-----------|
-| Тикет пришёл, воркфлоу нет | **Workflow Gap** | HIGH |
-| Воркфлоу есть, тикетов не было | Потенциально лишний | LOW |
-| Тикет не подошёл ни под один тип | **Routing Gap** | HIGH |
-
-### 2. Анализ знаний vs потребностей воркфлоу
-
-Для каждого воркфлоу проверь: все ли данные, на которые он ссылается, есть в knowledge/?
-
-| Ситуация | Тип пробела | Приоритет |
-|----------|------------|-----------|
-| Воркфлоу ссылается на несуществующий knowledge | **Knowledge Gap** | CRITICAL |
-| Воркфлоу требует данных, но не ссылается на knowledge | **Reference Gap** | MEDIUM |
-| Knowledge есть, но не используется ни в одном воркфлоу | Потенциально лишний | LOW |
-
-### 3. Анализ решений vs алгоритмов
-
-Найди в воркфлоу места, где агент принимает решения. Есть ли для них формализованный алгоритм?
-
-| Ситуация | Тип пробела | Приоритет |
-|----------|------------|-----------|
-| Решение принимается без алгоритма | **Algorithm Gap** | MEDIUM |
-| Алгоритм есть, но не используется | **Adoption Gap** | MEDIUM |
-
-### 4. Анализ вывода vs шаблонов
-
-Для каждого типа результата воркфлоу: есть ли шаблон в templates/?
-
-| Ситуация | Тип пробела | Приоритет |
-|----------|------------|-----------|
-| Воркфлоу формирует результат без шаблона | **Template Gap** | MEDIUM |
-| Шаблон есть, но не используется | Потенциально лишний | LOW |
-
-### 5. Анализ результатов тикетов
-
-Изучи завершённые тикеты. Где результат неполный или низкого качества?
-
-| Признак | Тип пробела | Приоритет |
-|---------|------------|-----------|
-| Пустые секции в результате | Воркфлоу неполный | HIGH |
-| Агент «придумал» данные | Нужен knowledge-модуль | HIGH |
-| Результат не по шаблону | Шаблон неизвестен агенту | MEDIUM |
-
-## Выход
-
-Таблица пробелов:
-
-| # | Тип пробела | Файл/секция | Описание | Приоритет | Рекомендация |
-|---|------------|-------------|----------|-----------|-------------|
-| 1 | ... | ... | ... | ... | ... |
-
-Сортировка по приоритету: CRITICAL → HIGH → MEDIUM → LOW.

package/src/skills/coach/algorithms/improvement-prioritization.md

@@ -1,62 +0,0 @@
-# Алгоритм: Приоритизация улучшений
-
-Метод определения порядка внесения улучшений в скил.
-
-## Вход
-
-Список улучшений из аудита, анализа или gap-анализа — каждое с описанием проблемы.
-
-## Алгоритм
-
-### 1. Оцени каждое улучшение по 3 критериям (1–5)
-
-| Критерий | 1 | 3 | 5 |
-|----------|---|---|---|
-| **Impact (I)** — влияние на качество работы скила | Косметическое | Заметное улучшение | Критично для работоспособности |
-| **Confidence (C)** — уверенность что улучшение поможет | Гипотеза | Обоснованное предположение | Очевидно из данных |
-| **Effort (E)** — трудозатраты на реализацию | Масштабное изменение | Средний объём | Быстрая правка |
-
-### 2. Рассчитай score
-
-```
-Score = (I × C × E) / 25
-```
-
-Нормализованный диапазон: 0.004 – 5.0
-
-### 3. Классифицируй по приоритету
-
-| Score | Приоритет | Действие |
-|-------|-----------|----------|
-| > 3.0 | **CRITICAL** | Делать немедленно |
-| 1.5 – 3.0 | **HIGH** | Делать в текущей итерации |
-| 0.5 – 1.5 | **MEDIUM** | Запланировать |
-| < 0.5 | **LOW** | Backlog |
-
-### 4. Сгруппируй по типу изменения
-
-Улучшения одного типа (например, все правки в knowledge/) удобнее делать вместе:
-
-| Группа | Типичные улучшения |
-|--------|-------------------|
-| **Структура** | Создание директорий, файлов, README |
-| **Контент** | Наполнение knowledge, algorithms |
-| **Ссылки** | Добавление в таблицы загрузки, исправление ссылок |
-| **Рефакторинг** | Переструктуризация воркфлоу, устранение дублирования |
-
-## Выход
-
-Приоритизированный план:
-
-| # | Улучшение | I | C | E | Score | Приоритет | Группа |
-|---|-----------|---|---|---|-------|-----------|--------|
-| 1 | ... | 5 | 5 | 4 | 4.0 | CRITICAL | Контент |
-| 2 | ... | 4 | 3 | 5 | 2.4 | HIGH | Ссылки |
-
-## Пример
-
-Улучшение: «Добавить knowledge/competitors.md в целевой скил»
-- Impact: 4 (часто нужен при стратегических решениях)
-- Confidence: 4 (видно из тикетов, где агент додумывал)
-- Effort: 5 (создать один файл)
-- Score: (4 × 4 × 5) / 25 = 3.2 → **CRITICAL**

package/src/skills/coach/algorithms/skill-scoring.md

@@ -1,80 +0,0 @@
-# Алгоритм: Оценка качества скила
-
-## Вход
-
-Путь к директории скила (`.workflow/src/skills/<name>/`).
-
-## Алгоритм
-
-Оцени скил по 5 категориям. Каждая категория — от 0 до 20 баллов. Итого максимум — 100.
-
-### 1. Структура (0–20)
-
-| Критерий | Баллы |
-|----------|-------|
-| SKILL.md существует и содержит frontmatter | 4 |
-| README.md существует и описывает структуру | 4 |
-| workflows/ содержит файлы для каждого типа из маршрутизации | 4 |
-| knowledge/ содержит минимум 2 модуля | 4 |
-| algorithms/ содержит минимум 1 алгоритм | 2 |
-| templates/ содержит минимум 1 шаблон | 2 |
-
-### 2. Полнота SKILL.md (0–20)
-
-| Критерий | Баллы |
-|----------|-------|
-| Роль описана конкретно (делает / не делает) | 4 |
-| Маршрутизация полная (все типы → воркфлоу) | 4 |
-| Таблица загрузки knowledge заполнена | 3 |
-| Таблица загрузки algorithms заполнена | 3 |
-| Принципы конкретны и actionable (3–7 штук) | 3 |
-| Формат вывода специфицирован | 2 |
-| Границы компетенции определены | 1 |
-
-### 3. Качество воркфлоу (0–20)
-
-| Критерий | Баллы |
-|----------|-------|
-| Шаги пронумерованы и конкретны (глаголы) | 5 |
-| Ссылки на knowledge/algorithms где нужны данные | 5 |
-| Чеклисты / критерии завершения | 5 |
-| Нет дублирования между воркфлоу | 5 |
-
-### 4. Качество знаний и алгоритмов (0–20)
-
-| Критерий | Баллы |
-|----------|-------|
-| Knowledge структурирован (таблицы, категории) | 5 |
-| Маркеры расширения присутствуют | 3 |
-| Algorithms формализованы (формулы, пороги) | 5 |
-| Есть примеры применения | 4 |
-| Вход/выход алгоритмов определён | 3 |
-
-### 5. Связность, консистентность и изоляция (0–20)
-
-| Критерий | Баллы |
-|----------|-------|
-| Все ссылки из SKILL.md ведут на существующие файлы | 4 |
-| Все файлы knowledge/ упомянуты в таблице загрузки | 4 |
-| Все файлы algorithms/ упомянуты в таблице загрузки | 4 |
-| Терминология единообразна | 4 |
-| **Изоляция:** нет хардкода имён других скилов/ролей (grep на имена ролей = 0) | 4 |
-
-## Выход
-
-| Балл | Оценка | Рекомендация |
-|------|--------|-------------|
-| 80–100 | **EXCELLENT** | Скил готов к работе, мелкие улучшения |
-| 60–79 | **GOOD** | Работоспособен, но есть существенные пробелы |
-| 40–59 | **NEEDS_WORK** | Требуется серьёзная доработка |
-| 0–39 | **POOR** | Фундаментальные проблемы, рассмотреть пересоздание |
-
-## Пример
-
-Скил `example-skill`:
-- Структура: 20/20 (все компоненты на месте)
-- Полнота SKILL.md: 20/20 (все секции)
-- Качество воркфлоу: 18/20 (минус 2 за неполные чеклисты)
-- Качество знаний: 17/20 (минус 3 за отсутствие примеров в algorithms)
-- Связность: 20/20 (всё связано)
-- **Итого: 95/100 — EXCELLENT**

package/src/skills/coach/knowledge/audit-applied-changes-clean.txt

@@ -1,11 +0,0 @@
-Аудит 2026-04-16: остаточных упоминаний applied_changes[] не найдено.
-
-Проверены файлы (исключая backlog-management.md):
-- common-antipatterns.md — чисто
-- prompt-engineering.md — чисто
-- shared-knowledge-guide.md — чисто
-- skill-anatomy.md — чисто
-- test-authorship.md — чисто
-
-Паттерны поиска: applied_changes, change_id, CHG-, «бэклог изменений», «ledger правок».
-Тикет: COACH-31.