workflow-ai 1.1.0 → 1.3.0

package/src/skills/__test-cal-001-1777553217513/SKILL.md

@@ -0,0 +1,2 @@
+# Calibration Test Skill
+version: 1.0

package/src/skills/__test-runner-1777553217483/SKILL.md

@@ -0,0 +1,5 @@
+# Test Skill
+
+SIGNATURE_PRESENT
+SomeOtherContent
+version: 1.0

package/src/skills/coach/SKILL.md

@@ -123,7 +123,7 @@ ticket_prefix: COACH
 
 ## Принципы
 
-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 дней на тот же скил и ту же корневую проблему — это сигнал, что **текстовое усиление инструкции не работает** (предыдущий текст уже содержал норму, но нарушитель её проигнорировал). В этом случае: (а) ещё одна текстовая правка того же скила — недостаточная мера; (б) обязательно создай тикет эскалации стейкхолдеру с рекомендацией ввести **машинную защиту**, не зависящую от дисциплины агента (валидация пайплайном, пост-гейт-стадия, автоматический откат, инфраструктурная проверка); (в) в тикете явно опиши, что попытки дисциплинарного усиления исчерпаны, и почему только машинная защита закрывает класс ошибки. Текстовую правку всё равно применяй — она страхует дисциплинированного агента, — но **не считай её решением проблемы**, пока машинная защита не введена. Антипаттерн: «усилю формулировку ещё жёстче, напишу ⛔ крупнее» — агент, который не прочитал прошлую норму, не прочитает и новую.
+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 дней на тот же скил и ту же корневую проблему — **сначала сравни даты выполнения тикета-нарушителя и применения предыдущего CHG, до классификации «повторный инцидент»**. Источники дат: для CHG — `git log` на файл скила (commit-дата правки) или `analyzed_tickets.analyzed_date` в `coach-backlog.yaml`; для тикета — `updated_at`/`completed_at` в frontmatter или ближайшие временные метки в логе пайплайна, где произошёл инцидент (стадии execute-task / review-result, дата записи `## Ревью`). **Если выполнение тикета предшествует дате CHG** — это **не** повторный инцидент: тикет проходил пайплайн до того, как текстовое усиление было применено, нарушение исторически объяснимо (фикса ещё не существовало). Класс — обычный новый, эскалация на машинную защиту **не нужна**, обработай как стандартный CHG. **Только если выполнение тикета строго ПОСЛЕ даты CHG** — это сигнал, что **текстовое усиление инструкции не работает** (предыдущий текст уже содержал норму, но нарушитель её проигнорировал). В этом случае: (а) ещё одна текстовая правка того же скила — недостаточная мера; (б) обязательно создай тикет эскалации стейкхолдеру с рекомендацией ввести **машинную защиту**, не зависящую от дисциплины агента (валидация пайплайном, пост-гейт-стадия, автоматический откат, инфраструктурная проверка); (в) в тикете явно опиши, что попытки дисциплинарного усиления исчерпаны, и почему только машинная защита закрывает класс ошибки. Текстовую правку всё равно применяй — она страхует дисциплинированного агента, — но **не считай её решением проблемы**, пока машинная защита не введена. Антипаттерн 1: «усилю формулировку ещё жёстче, напишу ⛔ крупнее» — агент, который не прочитал прошлую норму, не прочитает и новую. Антипаттерн 2: классифицировать «повторный инцидент» по факту повторяемости пары (скил, класс ошибки) **без сравнения дат** CHG и выполнения тикета. Эскалация без date-check — преждевременная: возможно, тикет проходил пайплайн ещё до текстового усиления, и фикс не имел шанса сработать. **Date-check — необходимое, но не достаточное условие.** Дополнительно сверь **семантический класс ошибки** предыдущего CHG и текущего инцидента: даже если выполнение тикета строго после CHG, инцидент может быть другого класса (CHG покрывал ортогональную проблему — например, semantic-mismatch vs structural-integrity, test-isolation vs review-rubric). Тогда это новый класс, а не повторный инцидент, и эскалация не требуется. Условие эскалации: **(дата выполнения > дата CHG) И (семантический класс совпадает)**.
 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 на основании того, что дефект «небольшой» или «единичный» — скил либо нарушен, либо нет.
@@ -148,7 +148,7 @@ ticket_prefix: COACH
 Если на (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**, иначе правка не дойдёт до агента-исполнителя. Когда стейкхолдер указывает на ошибку — это сигнал, что проактивная проверка не сработала: исправь не только текущую работу и целевой скил, но и усиль собственные инструкции коуча, чтобы ошибка не повторялась.
+10. **Self-Correct** — после каждой правки в скил **обязательно** перечитай принципы коуча (1-12) и проверь, не нарушает ли внесённая правка какой-либо из них. Не жди указания стейкхолдера — проверяй проактивно. **Процедура:** после каждого Edit/Write в файл скила — прежде чем отвечать пользователю — (1) перечитай `Read` записанный файл, (2) пройди по каждому принципу 1-12, (3) если нарушение найдено — исправь сразу, не дожидаясь фидбека. **(4) Проверка доставки:** если правка добавляет знание в shared или knowledge — открой SKILL.md целевого скила и убедись, что файл загружается по триггеру текущей задачи. Если триггер загрузки отсутствует или слишком слабый (последняя строка таблицы, без ⛔, без «обязательно») — **усиль триггер в том же CHG**, иначе правка не дойдёт до агента-исполнителя. **(5) Тест:** после проверки принципов 1-12 **обязательно** выполни секцию «Обязательный шаг: Тест» (→ `workflows/test.md`). Self-check без теста — незавершённый self-check: принципы проверяют корректность текста, тест проверяет корректность поведения агента при чтении этого текста. Когда стейкхолдер указывает на ошибку — это сигнал, что проактивная проверка не сработала: исправь не только текущую работу и целевой скил, но и усиль собственные инструкции коуча, чтобы ошибка не повторялась.
 11. **Context Budget** — при анализе и аудите скила обязательно оценивай его **суммарный размер** (SKILL.md + все файлы из knowledge/ + algorithms/ + workflows/). Агент загружает эти файлы в контекст перед работой. **Порог:** если суммарный размер > 800 строк — это finding уровня HIGH. Каждая правка, добавляющая текст, должна оцениваться: «Не приведёт ли это к context overflow у агента-исполнителя?» **При аудите:** измерь `wc -l` всех файлов скила, укажи суммарный размер и сравни с порогом. Если превышен — рекомендуй консолидацию: объединение дублирующих секций, вынос редко используемых блоков в отдельные файлы с ленивой загрузкой (загружать только по триггеру, а не всегда), сжатие примеров.
 12. **Consistency** — скил не должен содержать взаимоисключающих или противоречащих друг другу инструкций. При каждой правке и аудите проверяй: не конфликтует ли новая инструкция с существующими. **Процедура:** после внесения правки grep'ни файл на ключевые термины правки и прочитай все совпадения — убедись, что нигде не сказано противоположное. **Типичные противоречия:** «всегда делай X» в одном месте и «никогда не делай X» в другом; разные значения по умолчанию для одного параметра; разные приоритеты действий в SKILL.md и в workflow. При обнаружении противоречия — устрани его сразу, выбрав одну версию и обновив все места.
 

package/src/skills/execute-task/SKILL.md

@@ -197,7 +197,7 @@ description: >
 
 1. **Ни одного чекбокса `[ ]`** в секции критериев готовности / DoD. Все переведены в `[x]` или помечены причиной невыполнения (`[x] Пункт — не применимо: <причина>`).
 2. **Секция `## Result` / `## Результат выполнения` физически заполнена** — содержит реальный текст (summary, изменённые файлы, заметки), а не оставлена в виде скелета-шаблона с `### Что сделано\n- ...`.
-3. **Frontmatter не содержит добавленных строк `status:` или `completed_at:`** (эти поля устанавливает только пайплайн).
+3. **Frontmatter не модифицирован вообще** — никаких новых ключей, никаких изменённых значений (включая `notes`, `tags`, `context.*`). Frontmatter — собственность создателя тикета и пайплайна. Эта проверка шире, чем запрет на `status:` и `completed_at:` (см. ограничение #5): любая правка frontmatter — потенциально источник YAML-несовместимостей (двоеточие+пробел в неэкранированном скаляре, дубль ключа, нарушенный отступ массива). Если необходимо зафиксировать прогресс/итерации/наблюдения — пиши в **тело тикета** (секции Result/Заметки), не в frontmatter.
 
 Если хоть один пункт нарушен — **вернись к шагу 5 или 7** и выполни правки инструментом `Edit` на файл тикета. Не обходи эту проверку: вывод `---RESULT---` при пустом Result или `[ ]`-чекбоксах считается **призрачным выполнением** (см. ограничение #9) и ведёт к retry → blocked.
 

package/src/skills/manual-testing/SKILL.md

@@ -119,6 +119,8 @@ ticket_prefix: QA
 
 Перед сохранением убедись, что директория `reports/` существует. Если нет — создай её.
 
+**⚠️ Переиспользование существующего теста (discovery вариант C):** если тест уже существует и сохраняет артефакты с hardcoded prefix другого тикета — **обнови prefix на ID текущего тикета в тест-файле перед запуском**. Ручное копирование/переименование файлов после запуска — антипаттерн: создаёт гонку mtime между артефактами и `updated_at` тикета, ломает artifact-snapshot diff верификатора.
+
 ### Cleanup evidence
 
 После завершения тестирования в `reports/` должны остаться **только файлы, на которые ссылается тикет**. Удали промежуточные и отладочные файлы (пробные скриншоты, дубликаты, скриншоты с неверным содержимым). Имя файла evidence должно соответствовать TC, для которого он используется — если evidence для TC-001 фактически сохранён как `TC-002-*.png`, переименуй или пересохрани с корректным именем.

package/src/skills/review-result/SKILL.md

@@ -57,7 +57,29 @@ description: >
 
 ## Шаги проверки
 
-### 0. Быстрый выход
+### 0. Целостность frontmatter (pre-flight)
+
+Перед любой содержательной проверкой убедись, что frontmatter тикета **валидно парсится** YAML-парсером. Запусти:
+
+```
+node -e "const y=require('js-yaml'),f=require('fs');const c=f.readFileSync(process.argv[1],'utf8');const m=c.match(/^---\\n([\\s\\S]*?)\\n---/);if(!m){console.log('NO_FRONTMATTER');process.exit(1)}try{y.load(m[1]);console.log('OK')}catch(e){console.log('YAML_ERROR:'+e.message);process.exit(2)}" .workflow/tickets/in-progress/{TICKET-ID}.md
+```
+
+(или эквивалент в проекте — `js-yaml.load` секции между `---`).
+
+Если parse возвращает ошибку (`duplicated mapping key`, `bad indentation`, `:` followed by space в неэкранированном скаляре и т.п.) — **немедленный fail**:
+
+```
+---RESULT---
+status: failed
+issues:
+  - "Frontmatter тикета невалиден: <текст YAML-ошибки>. Файл нельзя смержить в done — downstream MCP-ресурсы (workflow://human-queue, alerts) падают на парсинге. Исправить frontmatter и перезапустить."
+---RESULT---
+```
+
+Не пытайся «прочесть содержимое глазами» и одобрить — структурно повреждённый frontmatter ломает скрипты пайплайна и MCP-ресурсы.
+
+### 0.1. Быстрый выход
 
 Прочитай тикет. Если секция `## Ревью` существует и последняя запись — `passed` или `⏭ skipped` → немедленно верни `status: passed`.
 

package/src/scripts/tests/timeout-cascade.test.js

@@ -1,28 +0,0 @@
-function parseTimeout(testCase, index) {
-  return testCase.execution?.timeout_s || index.execution?.default_timeout_s || 300;
-}
-
-function testTimeoutCascade() {
-  const index = { execution: { default_timeout_s: 300 } };
-  
-  const testCases = [
-    { name: 'TC-001', execution: { timeout_s: 600 } },
-    { name: 'TC-002', execution: {} },
-    { name: 'TC-003' }
-  ];
-  
-  const results = testCases.map(tc => ({
-    case: tc.name,
-    timeout: parseTimeout(tc, index)
-  }));
-  
-  console.log('Timeout cascade results:', results);
-  
-  const expected = [600, 300, 300];
-  const passed = results.every((r, i) => r.timeout === expected[i]);
-  
-  console.log(`Test ${passed ? 'PASSED' : 'FAILED'}`);
-  process.exit(passed ? 0 : 1);
-}
-
-testTimeoutCascade();

package/src/skills/analyze-report/README.md

@@ -1,44 +0,0 @@
-# Analyze Report — Agent Skill
-
-Аналитик отчётов для workflow-ai. Анализирует отчёты о выполненных задачах, оценивает прогресс по планам, проводит ретроспективы и формирует actionable рекомендации.
-
-## Структура
-
-```
-analyze-report/
-├── SKILL.md                              # Ядро: роль, маршрутизация, принципы
-├── README.md                             # Документация
-├── workflows/
-│   ├── progress.md                       # Оценка прогресса по плану
-│   └── retrospective.md                  # Ретроспектива завершённого плана
-├── knowledge/
-│   ├── analysis-frameworks.md            # Методологии анализа, метрики, паттерны
-│   └── report-structure.md               # Структура отчётов, правила извлечения данных
-├── algorithms/
-│   └── progress-assessment.md            # Алгоритм оценки прогресса (формулы, пороги)
-└── templates/
-    └── analysis-report.md                # Шаблон результата анализа
-```
-
-## Как это работает
-
-1. Любой скил проекта создаёт тикет `ANL-*` с запросом на анализ
-2. Analyze Report определяет тип (PROGRESS / RETROSPECTIVE)
-3. Загружает соответствующий workflow
-4. Собирает данные из отчётов, тикетов, планов
-5. Рассчитывает метрики, выявляет проблемы, формулирует рекомендации
-6. Формирует структурированный результат анализа
-
-## Как расширять
-
-### Новый тип анализа
-1. Создай файл в `workflows/{type}.md`
-2. Добавь запись в таблицу маршрутизации в `SKILL.md`
-
-### Новый knowledge-модуль
-1. Создай файл в `knowledge/{module}.md`
-2. Добавь запись в таблицу загрузки знаний в `SKILL.md`
-
-### Новый шаблон вывода
-1. Создай файл в `templates/{template}.md`
-2. Добавь запись в таблицу шаблонов в `SKILL.md`

package/src/skills/analyze-report/algorithms/progress-assessment.md

@@ -1,108 +0,0 @@
-# Алгоритм: Оценка прогресса по плану
-
-Формализованный метод оценки текущего прогресса выполнения плана.
-
-## Вход
-
-- Список всех тикетов плана с их статусами (done, in-progress, ready, blocked, backlog)
-- Сложность каждого тикета (simple, medium, complex)
-- Даты создания и завершения тикетов
-- Данные ревью (прошёл / не прошёл / пропущен)
-
-## Алгоритм
-
-### 1. Подсчитай распределение по статусам
-
-```
-total = count(all tickets)
-done = count(status == done)
-in_progress = count(status == in-progress)
-ready = count(status == ready)
-blocked = count(status == blocked)
-backlog = count(status == backlog)
-```
-
-### 2. Рассчитай Completion Rate
-
-**Простой (по количеству):**
-```
-completion_rate = done / total × 100%
-```
-
-**Взвешенный (по сложности):**
-
-| Сложность | Вес |
-|-----------|-----|
-| simple | 1 |
-| medium | 2 |
-| complex | 3 |
-
-```
-weighted_done = Σ(weight[t] for t in done_tickets)
-weighted_total = Σ(weight[t] for t in all_tickets)
-weighted_completion = weighted_done / weighted_total × 100%
-```
-
-### 3. Рассчитай Quality Rate
-
-```
-reviewed = count(tickets with review)
-passed_first = count(tickets passed review on first attempt)
-first_pass_rate = passed_first / reviewed × 100%
-```
-
-### 4. Рассчитай Block Rate
-
-```
-block_rate = blocked / total × 100%
-```
-
-### 5. Определи статус прогресса
-
-| Completion | Block Rate | First-Pass Rate | Статус | Рекомендация |
-|------------|-----------|-----------------|--------|-------------|
-| ≥80% | <10% | ≥70% | 🟢 ON_TRACK | Продолжить по плану |
-| 50-80% | <20% | ≥50% | 🟡 ATTENTION | Обратить внимание на отстающие задачи |
-| 30-50% | <30% | Любой | 🟠 AT_RISK | Пересмотреть приоритеты, разблокировать |
-| <30% | ≥30% | Любой | 🔴 CRITICAL | Эскалировать, пересмотреть план |
-
-### 6. Оцени тренд
-
-Если есть данные за несколько периодов:
-```
-velocity_current = done_last_period / period_length
-velocity_previous = done_prev_period / period_length
-trend = velocity_current - velocity_previous
-```
-
-| Тренд | Интерпретация |
-|-------|---------------|
-| trend > 0 | 📈 Ускорение |
-| trend ≈ 0 | ➡️ Стабильно |
-| trend < 0 | 📉 Замедление |
-
-## Выход
-
-- Completion Rate (простой и взвешенный)
-- Quality Rate (First-Pass Rate)
-- Block Rate
-- Статус прогресса (ON_TRACK / ATTENTION / AT_RISK / CRITICAL)
-- Тренд (если данных достаточно)
-- Распределение тикетов по статусам
-
-## Пример
-
-```
-Total: 12 тикетов
-Done: 7 (3 simple, 3 medium, 1 complex)
-In-progress: 2 (1 medium, 1 complex)
-Ready: 1 (simple)
-Blocked: 2 (1 medium, 1 complex)
-
-Completion Rate: 7/12 = 58%
-Weighted: (3×1 + 3×2 + 1×3) / (4×1 + 4×2 + 4×3) = 12/24 = 50%
-Block Rate: 2/12 = 17%
-First-Pass Rate: 5/7 = 71%
-
-Статус: 🟡 ATTENTION (50% weighted, 17% blocked, 71% first-pass)
-```

package/src/skills/analyze-report/knowledge/analysis-frameworks.md

@@ -1,66 +0,0 @@
-# Методологии анализа отчётов
-
-Базовые фреймворки и метрики для анализа отчётов о выполненных задачах.
-
-## Фреймворк анализа прогресса
-
-### Количественные метрики
-
-| Метрика | Формула | Интерпретация |
-|---------|---------|---------------|
-| **Completion Rate** | done / total × 100% | Общий прогресс по плану |
-| **Weighted Completion** | Σ(done × complexity) / Σ(total × complexity) × 100% | Прогресс с учётом сложности |
-| **Throughput** | done / time_elapsed | Скорость выполнения |
-| **Block Rate** | blocked / total × 100% | Доля заблокированных задач |
-| **Rework Rate** | reworked / done × 100% | Доля задач с переделками |
-| **First-Pass Rate** | passed_review_first / done × 100% | Качество выполнения с первого раза |
-
-### Качественные индикаторы
-
-| Индикатор | Сигнал | Действие |
-|-----------|--------|----------|
-| Много заблокированных задач | Проблемы с зависимостями | Пересмотреть порядок задач |
-| Низкий First-Pass Rate | Проблемы с качеством | Усилить критерии DoD |
-| Высокий Rework Rate | Нечёткие требования | Улучшить описания задач |
-| Throughput падает | Усталость / сложность растёт | Декомпозировать оставшиеся задачи |
-
-## Фреймворк ретроспективы: Keep / Stop / Try
-
-### Keep (Продолжать)
-Практики, которые доказали эффективность:
-- Что конкретно делалось?
-- Какой результат это дало?
-- Почему это сработало?
-
-### Stop (Прекратить)
-Практики, которые создавали проблемы:
-- Что конкретно происходило?
-- Какой вред это наносило?
-- Что вызвало эту практику?
-
-### Try (Попробовать)
-Новые подходы для эксперимента:
-- Что конкретно предлагается?
-- Какую проблему это решает?
-- Как измерить результат?
-
-## Паттерны типичных проблем
-
-| Паттерн | Симптомы | Корневая причина | Рекомендация |
-|---------|---------|-----------------|--------------|
-| **Scope Creep** | Количество задач растёт, прогресс стоит | Нечёткие границы плана | Зафиксировать скоуп, новые задачи — в следующий план |
-| **Dependency Hell** | Много заблокированных задач | Плохая декомпозиция зависимостей | Пересмотреть порядок, разблокировать критический путь |
-| **Quality Debt** | Высокий rework rate | Слабые критерии DoD | Усилить DoD, добавить чеклисты |
-| **Single Point of Failure** | Один тип задач блокирует всё | Отсутствие параллелизма | Декомпозировать для параллельного выполнения |
-| **Velocity Decay** | Throughput падает со временем | Растущая сложность / усталость | Декомпозировать крупные задачи, ротация фокуса |
-
-## Классификация серьёзности проблем
-
-| Уровень | Описание | Действие |
-|---------|----------|----------|
-| **CRITICAL** | Блокирует весь план, прогресс невозможен | Немедленное вмешательство |
-| **HIGH** | Значительно замедляет прогресс | Решить в текущей итерации |
-| **MEDIUM** | Влияет на качество, но не блокирует | Запланировать решение |
-| **LOW** | Мелкие недочёты, потенциальные улучшения | Учесть при следующем планировании |
-
-<!-- РАСШИРЕНИЕ: добавляй новые паттерны и фреймворки ниже -->

package/src/skills/analyze-report/knowledge/report-structure.md

@@ -1,61 +0,0 @@
-# Структура отчётов и извлечение данных
-
-Описание типовой структуры отчётов workflow-ai и правила извлечения данных из них.
-
-## Типовая структура отчёта
-
-Отчёты находятся в `.workflow/reports/` и содержат:
-
-| Секция | Что извлекать |
-|--------|--------------|
-| **Frontmatter** | ID, дата, связанный план, период |
-| **Выполненные задачи** | Список завершённых тикетов, результаты |
-| **Проблемы** | Заблокированные задачи, ошибки, отклонения |
-| **Статистика** | Количественные данные: done/total, время |
-| **Рекомендации** | Выводы предыдущего анализа (если есть) |
-
-## Извлечение данных из тикетов
-
-### Из завершённых тикетов (done/)
-
-| Поле | Где искать | Зачем |
-|------|-----------|-------|
-| `id` | Frontmatter | Идентификация |
-| `complexity` | Frontmatter | Weighted completion |
-| `created_at` / `completed_at` | Frontmatter | Время выполнения |
-| **Result** | Секция `## Result` | Что реально сделано |
-| **DoD** | Секция критериев | Все ли выполнены |
-| **Ревью** | Секция `## Ревью` | Прошёл ли с первого раза |
-
-### Из заблокированных тикетов (blocked/)
-
-| Поле | Зачем |
-|------|-------|
-| `id`, `title` | Идентификация |
-| `dependencies` | Что блокирует |
-| Причина блокировки | Для рекомендаций по разблокировке |
-
-### Из тикетов в работе (in-progress/)
-
-| Поле | Зачем |
-|------|-------|
-| `id`, `title` | Текущая работа |
-| `created_at` | Как давно в работе |
-
-## Извлечение данных из планов
-
-| Секция плана | Что извлекать |
-|-------------|--------------|
-| **Цели** | Ожидаемые результаты для сравнения |
-| **Задачи** | Полный список для подсчёта покрытия |
-| **Приоритеты** | Для оценки порядка выполнения |
-| **Риски** | Для проверки — сработали ли |
-
-## Правила работы с данными
-
-- **Считай только то, что есть** — не экстраполируй, не предполагай
-- **Указывай источник** — для каждой метрики укажи откуда взяты данные
-- **Отмечай пробелы** — если данных не хватает для вывода, явно укажи
-- **Разделяй факты и выводы** — сначала данные, потом интерпретация
-
-<!-- РАСШИРЕНИЕ: обновляй при изменении структуры отчётов -->