workflow-ai 1.0.40 → 1.0.42

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

@@ -1,285 +0,0 @@
----
-name: review-result
-description: Проверить результат выполнения задачи на соответствие Definition of Done. Используется после execute-task для валидации качества работы.
----
-
-# Проверка результата (Review Result)
-
-> **ОБЯЗАТЕЛЬНО:** Последние строки твоего ответа ВСЕГДА должны быть блоком `---RESULT---`.
-> Без этого блока пайплайн не распознает статус и тикет попадёт в `blocked`.
-> Даже если ревью очевидно — всё равно заверши ответ блоком результата.
-
-Этот skill проверяет результат выполнения задачи на соответствие критериям готовности (Definition of Done) из тикета.
-
-## Когда использовать
-
-- Задача выполнена и тикет перемещён в `review/`
-- Требуется валидация качества перед перемещением в `done/`
-- Retry-логика пайплайна: определить status для goto-перехода
-
-## Шаги проверки
-
-### 0. Проверить последний статус ревью
-
-**До любых проверок** найди в тикете секцию `## Ревью`.
-
-Если секция существует и содержит записи — посмотри на **последнюю запись** (последняя строка таблицы или последний элемент списка):
-
-- Если последняя запись имеет статус `passed` — ревью уже пройдено. Немедленно верни результат:
-
-```
----RESULT---
-status: passed
-issues: []
----RESULT---
-```
-
-- Если последняя запись имеет статус `⏭ skipped` — тикет пропущен check-relevance. Ревью проводить **НЕ НАДО**. Немедленно верни результат:
-
-```
----RESULT---
-status: passed
-issues: []
----RESULT---
-```
-
-- Если последняя запись имеет статус `failed` — **необходима повторная проверка**. Переходи к шагу 1.
-
-> **ВАЖНО:** Проверяй именно ПОСЛЕДНЮЮ запись, а не любую. Если после `passed`/`skipped` появилась `failed` — задача требует повторной проверки. Только если последний статус `passed` или `skipped` — можно пропустить.
-
-### 1. Прочитать тикет
-
-ID тикета передаётся в промпте как `ticket_id` в секции Context.
-
-```
-Путь: .workflow/tickets/review/{TICKET-ID}.md
-```
-
-**Важно:** НЕ перемещай тикет — перемещение выполняется отдельным stage пайплайна по результату этого skill.
-
-Извлечь:
-- Definition of Done (DoD) — чеклист критериев готовности
-- Детали задачи — требования к реализации
-- Результат выполнения (секция Result) — что сделано
-
-### 2. Проверить каждый пункт DoD
-
-Для каждого критерия из Definition of Done:
-
-| Тип проверки | Описание |
-|--------------|----------|
-| `file_exists` | Файл существует по указанному пути |
-| `compilation` | Код компилируется / линтер проходит |
-| `tests` | Тесты проходят |
-| `text` | Текстовый критерий выполнен (содержимое, структура) |
-| `structure` | Структура соответствует шаблону |
-
-### 3. Сверить результат с требованиями
-
-Сравнить секцию «Результат выполнения» с «Деталями задачи»:
-- Все ли требования учтены
-- Соответствует ли реализация описанию
-- Нет ли расхождений
-
-### 4. Сформировать вердикт
-
-> **ВАЖНО:** Review-result НИКОГДА не пишет статус `skipped`. Допустимы только `passed` или `failed`. Статус `skipped` — прерогатива check-relevance.
-
-Возвращать структурированный результат строго в одном из двух форматов:
-
-> **КРИТИЧНО**: `status` принимает ТОЛЬКО два значения: `passed` или `failed`.
-> Любой другой вывод (`default`, `ok`, `done`, `complete`, `yes`, и т.д.) — **ОШИБКА**.
-> Пайплайн не продолжится корректно, если статус не распознан.
-
-Если **все** пункты DoD выполнены:
-
-```
----RESULT---
-status: passed
-issues: []
----RESULT---
-```
-
-Если **хотя бы один** пункт DoD не выполнен:
-
-```
----RESULT---
-status: failed
-issues:
-  - "Пункт DoD X не выполнен: ожидалось Y, получено Z"
-  - "Файл X не создан"
-  - "Тест Y не прошёл"
----RESULT---
-```
-
-> Блок `---RESULT---` должен быть в выводе **ровно один раз**, в самом конце ответа.
-
-### 5. При `failed`: детализировать замечания
-
-Для каждого невыполненного пункта:
-- Описать что ожидалось
-- Описать что получено
-- Указать файл/строку если применимо
-
-## Алгоритм проверки
-
-```
-0. Быстрый выход:
-   - Прочитать тикет
-   - Найти секцию "## Ревью"
-   - Если последняя запись "passed" или "skipped" → вернуть status: passed, остановиться
-   - Если последняя запись "failed" → перейти к шагу 1 (повторная проверка)
-
-1. Парсинг тикета:
-   - Извлечь DoD (список критериев)
-   - Извлечь Result (что сделано)
-   - Извлечь Детали задачи (требования)
-
-2. Для каждого пункта DoD:
-   - Определить тип проверки (file/compilation/tests/text)
-   - Выполнить проверку
-   - Записать результат (pass/fail + комментарий)
-
-3. Сверка Result ↔ Детали задачи:
-   - Все ли файлы созданы
-   - Соответствует ли структура
-   - Нет ли расхождений
-
-4. Формирование вердикта:
-   - Если все пункты pass → status: passed
-   - Если есть fail → status: failed + список issues
-
-5. Вывод результата в формате ---RESULT---
-
-6. Пометка тикета о результате ревью:
-   - Добавить секцию `## Ревью` в тикете (если её нет — создать с заголовком таблицы)
-   - **ВАЖНО: новую запись добавлять В КОНЕЦ таблицы** (последней строкой). Не вставлять перед существующими записями!
-   - Указать:
-     - Дата ревью
-     - Статус: passed/failed
-     - Краткий самари (если failed — что не так)
-   - Сохранить тикет в той же директории
-```
-
-## Типы проверок
-
-### file_exists
-
-Проверка существования файла:
-
-```
-Критерий: "[ ] Файл `src/logger.py` создан"
-Проверка: os.path.exists("src/logger.py")
-Результат: pass/fail
-```
-
-### compilation
-
-Проверка компиляции / линта:
-
-```
-Критерий: "[ ] Код проходит линтер"
-Проверка: npm run lint / ruff check / etc.
-Результат: pass/fail + вывод
-```
-
-### tests
-
-Проверка тестов:
-
-```
-Критерий: "[ ] Тесты проходят"
-Проверка: npm test / pytest / etc.
-Результат: pass/fail + вывод
-```
-
-### text
-
-Текстовая проверка:
-
-```
-Критерий: "[ ] Описан алгоритм проверки DoD"
-Проверка: Поиск раздела "Алгоритм" в файле
-Результат: pass/fail
-```
-
-### structure
-
-Проверка структуры:
-
-```
-Критерий: "[ ] Структура аналогична существующим skills"
-Проверка: Сравнение с шаблоном
-Результат: pass/fail + замечания
-```
-
-## Пример использования
-
-```
-Проверь результат IMPL-006 на соответствие DoD.
-```
-
-```
-review-result .workflow/tickets/in-progress/IMPL-006.md
-```
-
-## Пример вывода
-
-### Успешная проверка
-
-```markdown
----RESULT---
-status: passed
-issues: []
----RESULT---
-```
-
-### Неуспешная проверка
-
-```markdown
----RESULT---
-status: failed
-issues:
-  - "Пункт DoD 'Файл .workflow/src/skills/review-result/SKILL.md создан' не выполнен: файл не найден"
-  - "Пункт DoD 'Описан алгоритм проверки DoD' не выполнен: раздел 'Алгоритм' отсутствует"
-  - "Тесты не прошли: 2 failed, 5 passed"
----RESULT---
-```
-
-## Формат секции ревью в тикете
-
-После проверки skill добавляет в тикет секцию. **Новые записи всегда добавляются В КОНЕЦ таблицы** (хронологический порядок: старые сверху, новые снизу):
-
-```markdown
-## Ревью
-
-| Дата | Статус | Самари |
-|------|--------|--------|
-| 2026-03-03 14:30 | ❌ failed | Не пройдены тесты, отсутствует файл logger.py |
-| 2026-03-03 15:45 | ✅ passed | Все критерии DoD выполнены после исправления |
-```
-
-> **Порядок записей:** хронологический сверху вниз. Последняя строка = последнее ревью. Код `getLastReviewStatus()` определяет статус по последней строке.
-
-## Интеграция с пайплайном
-
-В retry-логике пайплайна:
-
-1. `execute-task` выполняет задачу
-2. `review-result` проверяет результат
-3. По `status` определяется goto-переход:
-   - `passed` → следующий stage
-   - `failed` → retry или blocked
-
-## Результат
-
-- Структурированный вердикт (passed/failed)
-- Список замечаний (если есть)
-- **Тикет помечен секцией `## Ревью`** с датой, статусом и кратким самари
-- Готово для использования в goto-логике
-
-## Связанные skills
-
-- `execute-task` — выполнение задачи перед проверкой
-- `move-ticket` — перемещение по результатам проверки
-- `check-conditions` — проверка условий для зависимых задач