workflow-ai 1.0.41 → 1.0.42

package/src/skills/deep-research/workflows/technology.md

@@ -1,52 +0,0 @@
-# Воркфлоу: TECHNOLOGY — Обзор технологий
-
-Исследование технологий, инструментов, платформ для принятия технических решений.
-
-## Алгоритм выполнения
-
-### 1. Определи скоуп
-
-- Какую задачу решает технология
-- Критерии выбора (цена, масштаб, интеграции, etc.)
-- Контекст использования (стек, команда, бюджет)
-
-### 2. Составь longlist
-
-1. Поиск по категории (G2, Capterra, Product Hunt)
-2. GitHub/npm/PyPI — open source альтернативы
-3. Обзорные статьи "Best {category} tools 2024/2025"
-4. Reddit/HackerNews — что рекомендует сообщество
-
-### 3. Отфильтруй до shortlist
-
-Критерии фильтрации:
-- Активно поддерживается (последнее обновление < 6 мес)
-- Подходит по масштабу и бюджету
-- Совместим с текущим стеком
-
-### 4. Глубокий анализ shortlist
-
-| Параметр | Инструмент A | Инструмент B | Инструмент C |
-|----------|-------------|-------------|-------------|
-| Цена | ... | ... | ... |
-| Features | ... | ... | ... |
-| Интеграции | ... | ... | ... |
-| Документация | ... | ... | ... |
-| Community/Support | ... | ... | ... |
-| Ограничения | ... | ... | ... |
-
-### 5. Синтезируй выводы
-
-→ Загрузи `algorithms/synthesis.md`
-
-### 6. Сформируй отчёт
-
-→ Используй `templates/research-report.md`
-
-### 7. Валидация
-
-- [ ] Longlist ≥ 10 опций
-- [ ] Shortlist 3-5 опций с обоснованием фильтрации
-- [ ] Comparison matrix заполнена
-- [ ] Цены актуальны и проверены
-- [ ] Указаны ограничения каждого варианта

package/src/skills/deep-research/workflows/trend.md

@@ -1,51 +0,0 @@
-# Воркфлоу: TREND — Исследование трендов
-
-Выявление и анализ трендов в индустрии: что меняется, куда движется рынок.
-
-## Алгоритм выполнения
-
-### 1. Определи скоуп
-
-- Какая индустрия/ниша
-- Временной горизонт (текущие тренды, прогнозы)
-- Контекст заказчика (зачем нужны тренды)
-
-### 2. Собери данные о трендах
-
-Источники:
-1. Google Trends — динамика поисковых запросов
-2. Отраслевые отчёты — прогнозы аналитиков
-3. Конференции/вебинары — темы докладов
-4. Инвестиции/стартапы — куда идут деньги (Crunchbase, PitchBook)
-5. Технологические блоги — emerging tech
-6. Регуляторные изменения — новые законы, стандарты
-
-### 3. Классифицируй тренды
-
-| Категория | Описание |
-|-----------|----------|
-| **Mega-trend** | Фундаментальный сдвиг (5+ лет) |
-| **Macro-trend** | Устойчивое направление (2-5 лет) |
-| **Micro-trend** | Текущая волна (6-24 мес) |
-| **Fad** | Краткосрочный хайп (< 6 мес) |
-
-### 4. Оцени каждый тренд
-
-- Стадия: emerging → growing → mature → declining
-- Импакт на бизнес заказчика: HIGH/MEDIUM/LOW
-- Timeframe: когда станет критичным
-
-### 5. Синтезируй выводы
-
-→ Загрузи `algorithms/synthesis.md`
-
-### 6. Сформируй отчёт
-
-→ Используй `templates/research-report.md`
-
-### 7. Валидация
-
-- [ ] Тренды классифицированы по категориям
-- [ ] Для каждого тренда указан импакт и timeframe
-- [ ] Есть данные/источники подтверждающие каждый тренд
-- [ ] Отделены факты от прогнозов

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

@@ -1,207 +0,0 @@
----
-name: execute-task
-description: Выполнить задачу из тикета. Используй когда нужно выполнить конкретный тикет из in-progress. Читает описание задачи, выполняет работу, записывает результат. Перемещение в done/blocked выполняется отдельным stage.
----
-
-# Выполнение задачи
-
-Этот skill выполняет задачу из тикета и записывает результат.
-
-## ⛔ КРИТИЧЕСКИЕ ОГРАНИЧЕНИЯ (прочитай ПЕРЕД выполнением)
-
-**Execute-task — скил ИСПОЛНЕНИЯ. Он НЕ создаёт артефакты workflow.**
-
-При выполнении задачи **КАТЕГОРИЧЕСКИ ЗАПРЕЩЕНО:**
-
-1. **Создавать файлы тикетов** в `.workflow/tickets/` (любая папка: backlog, ready, in-progress)
-2. **Создавать файлы планов** в `.workflow/plans/`
-3. **Вызывать скилы** `decompose-plan`, `decompose-gaps`, `create-plan`
-4. **Интерпретировать DoD буквально**, если DoD содержит «создать тикеты» или «декомпозировать в тикеты» — это рекомендация для следующего плана, а НЕ инструкция к действию
-
-**Если задача требует создания тикетов/планов как deliverable:**
-→ Зафиксируй рекомендации в секции `### Рекомендации для следующего плана` результата тикета
-→ Человек решит, создавать ли следующий план
-
-**Почему:** Без этого ограничения возникает каскад: execute-task создаёт план → decompose-plan создаёт тикеты → backlog разрастается без контроля человека. Это уже происходило дважды.
-
----
-
-## Когда использовать
-
-- Есть тикет в `in-progress/`
-- Нужно выполнить конкретную задачу
-- Перемещение в done/blocked будет выполнено отдельным stage пайплайна
-
-## Шаги выполнения
-
-### 1. Прочитать тикет
-
-**ОБЯЗАТЕЛЬНО:** Используй ТОЛЬКО `ticket_id` из секции Context промпта. Запрещено выбирать другой тикет.
-
-```
-Путь: .workflow/tickets/in-progress/{TICKET-ID}.md
-```
-
-Если тикет не найден в `in-progress/`, проверь `review/` (при повторном выполнении тикет может быть там).
-
-**Важно:** НЕ перемещай тикет. Перемещение выполняется отдельным stage пайплайна.
-
-Извлечь:
-- Описание задачи
-- Критерии готовности (Definition of Done)
-- Контекст (файлы, ссылки, заметки)
-
-### 2. Понять задачу
-
-Убедиться что понятно:
-- Что нужно сделать
-- Какой результат ожидается
-- Какие есть ограничения
-
-Если не хватает информации:
-- Создать подзадачу на уточнение
-- Или вывести `status: blocked` в блоке результата (перемещение выполнит pipeline)
-
-### 3. Выполнить работу
-
-В зависимости от типа задачи:
-
-| Тип | Действия |
-|-----|----------|
-| IMPL | Написать код |
-| FIX | Исправить баг |
-| DOCS | Написать документацию |
-| REVIEW | Проверить код/документы |
-| PLAN | Создать план |
-| ADMIN | Выполнить настройку (см. 3.1) |
-| rsh | Провести исследование (см. 3.2) |
-
-#### 3.1. Специальные правила для `type: admin`
-
-Admin-задачи требуют **реального изменения файлов**. Цикл выполнения:
-
-1. **Read** — прочитать все файлы из `context.files` инструментом Read
-2. **Edit/Write** — внести требуемые изменения инструментом Edit или Write
-3. **Verify** — перечитать изменённые файлы для верификации результата
-
-**Запрещено для admin-задач:**
-- Завершать задачу без реального изменения файлов
-- Оставлять секцию «Результат выполнения» пустой или с заглушкой
-- Описывать изменения только в Summary без внесения их в целевые файлы
-
-**Чеклист самопроверки перед завершением admin-задачи:**
-- [ ] Все файлы из `context.files` прочитаны?
-- [ ] Изменения внесены инструментом Edit/Write (не просто описаны)?
-- [ ] Изменённые файлы перечитаны и верифицированы?
-- [ ] Секция «Результат выполнения» содержит конкретный результат (не заглушку)?
-
-#### 3.2. Специальные правила для `type: rsh` (RSH-тикеты)
-
-Research-задачи выполняются с помощью скрипта `perplexity-research.js`, который вызывает Perplexity API для сбора данных из интернета.
-
-**Цикл выполнения:**
-
-1. **Read** — прочитать тикет, понять тему и скоуп исследования
-2. **Read SKILL** — прочитать `.workflow/src/skills/deep-research/SKILL.md` для понимания методологии
-3. **Research** — вызвать скрипт через bash, результат приходит в stdout:
-   ```bash
-   node .workflow/src/skills/deep-research/scripts/perplexity-research.js "исследовательский запрос"
-   ```
-   Для сложных тем — несколько запросов с разными фокусами:
-   ```bash
-   node .workflow/src/skills/deep-research/scripts/perplexity-research.js "запрос 1"
-   node .workflow/src/skills/deep-research/scripts/perplexity-research.js --model perplexity/sonar-pro "запрос 2"
-   ```
-4. **Synthesize** — проанализировать stdout, верифицировать, оформить финальный отчёт
-5. **Write** — записать отчёт в путь из тикета (обычно `reports/RSH-XXX-*.md`)
-
-**Доступные модели:**
-- `perplexity/sonar-deep-research` — по умолчанию, глубокий ресерч (5-10 мин)
-- `perplexity/sonar-pro` — быстрый с источниками (10-30 сек)
-- `perplexity/sonar` — простые справки (5-15 сек)
-
-**Запрещено для research-задач:**
-- Выдумывать данные без источников
-- Использовать только свои знания без вызова perplexity-research.js
-- Пропускать верификацию результатов
-
-### 4. Проверить критерии готовности
-
-Для каждого критерия из Definition of Done:
-- Выполнен ли он?
-- Если нет — что нужно доделать?
-
-### 5. Записать результат
-
-Добавить в тикет секцию Result:
-
-```markdown
-## Result
-
-### Что сделано
-- ...
-
-### Изменённые файлы
-- ...
-
-### Заметки
-- ...
-```
-
-### 6. Перемещение выполняется отдельным stage
-
-**Важно:** Этот skill НЕ перемещает тикет. НЕ выполняй никаких операций с файлами тикетов кроме записи результата.
-
-Запрещено:
-- Перемещать файл тикета в другую папку
-- Обновлять `status` в frontmatter
-- Добавлять `completed_at`
-- Вызывать `move-ticket.js` вручную
-
-Всё это выполняется автоматически скриптом перемещения на следующем stage пайплайна.
-
-### 7. Правила работы с MCP-browser (Playwright)
-
-Все взаимодействия с браузером **ОБЯЗАТЕЛЬНО** должны использовать профиль из конфига проекта (`.mcp.json`). Конфиг уже настроен с `--browser chrome --user-data-dir` — в профиле сохранены авторизации (Google, CWS и др.).
-
-**ЗАПРЕЩЕНО:**
-- Запускать браузер без профиля (headless без `--user-data-dir`)
-- Использовать конфиг `.workflow/config/mcp-browser.json` (headless без профиля) для задач, требующих авторизацию
-- Пытаться авторизоваться вручную — сессии уже есть в профиле
-
-**Справка по конфигам:**
-
-| Конфиг | Профиль | Когда использовать |
-|--------|---------|-------------------|
-| `.mcp.json` (дефолт) | ✅ Chrome + user-data-dir | **Всегда по умолчанию** |
-| `.workflow/config/mcp-browser-auth.json` | ✅ headless + user-data-dir | Headless с авторизацией |
-| `.workflow/config/mcp-browser.json` | ❌ headless без профиля | Только для задач без авторизации |
-
-После завершения работы с браузером — **обязательно** вызови `browser_close` перед выводом результата. Незакрытый браузер блокирует профиль и мешает следующему запуску.
-
-### 8. Вывести структурированный результат
-
-После выполнения **обязательно** выведи блок результата:
-
-```
----RESULT---
-status: default
----RESULT---
-```
-
-## Пример использования
-
-```
-Выполни задачу .workflow/tickets/in-progress/IMPL-001.md
-```
-
-## Результат
-
-- Выполненная работа (код, документация и т.д.)
-- Обновлённый тикет с секцией Result
-- Тикет остаётся на месте (перемещение выполняется отдельным stage)
-
-## Связанные skills
-
-- `check-conditions` — после выполнения проверить зависимые задачи
-- `create-report` — включить результат в отчёт

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

@@ -1,329 +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. Сверить результат с требованиями
-
-Сравнить секцию «Результат выполнения» с «Деталями задачи»:
-- Все ли требования учтены
-- Соответствует ли реализация описанию
-- Нет ли расхождений
-
-### 3.5. Проверка с позиции целевой аудитории
-
-> **Применяется** когда результат тикета — документ/ТЗ/спецификация, предназначенные для конкретного исполнителя (разработчик, дизайнер, внешний подрядчик и т.д.).
-
-Если в DoD есть критерий типа *"файл самодостаточен"* или *"исполнитель не должен смотреть другие документы"*:
-
-| Проверка | Как проверить | Провал → |
-|----------|---------------|----------|
-| Credentials указаны или описано где взять | Искать плейсхолдеры `XXX`, `TODO`, `заменить на реальный` — для каждого должна быть инструкция | failed |
-| Все системные зависимости перечислены | Для каждого API/библиотеки в сниппетах — проверить наличие в секции permissions/dependencies | failed |
-| Параметры вычислимы | Для условных параметров (`isFirst`, `count`) — описан способ получения значения | failed |
-| Environment-переключение описано | Если есть debug/dev/prod режимы — описан механизм переключения | failed |
-
-**Правило:** Прочитай документ глазами целевого исполнителя. Если он не может начать работу без дополнительных вопросов — это `failed`, даже если формальные DoD выполнены.
-
-### 3.6. Верификация реальных изменений
-
-> **Применяется только** для тикетов с `executor_type != human`.
-
-Даже если все DoD отмечены как `[x]`, необходимо убедиться что изменения реально существуют, а не являются галлюцинацией агента.
-
-| Проверка | Как проверить | Провал → |
-|----------|---------------|----------|
-| Файлы-артефакты существуют | Проверить все файлы из секции «Изменённые файлы» через Read/Glob | failed |
-| Файлы содержат реальный контент | Открыть файл, убедиться что содержимое — не шаблон/placeholder | failed |
-| Секция Result не пуста | Проверить что Summary заполнен содержательно (не заглушка) | failed |
-| DoD соответствует реальности | Для каждого `[x]` — открыть артефакт и убедиться что критерий действительно выполнен | failed |
-
-**Правило:** Если хотя бы одна проверка провалена → статус `failed`, даже если все DoD отмечены `[x]`.
-
-### 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 ↔ Детали задачи:
-   - Все ли файлы созданы
-   - Соответствует ли структура
-   - Нет ли расхождений
-
-3.5. Проверка с позиции целевой аудитории (для документов/ТЗ/спецификаций):
-   - Credentials указаны или описано где взять (нет голых плейсхолдеров)
-   - Все системные зависимости перечислены
-   - Условные параметры вычислимы
-   - Environment-переключение описано
-   - Любой провал → status: failed
-
-3.6. Верификация реальных изменений (только executor_type != human):
-   - Файлы из «Изменённые файлы» существуют
-   - Файлы содержат реальный контент (не placeholder)
-   - Summary заполнен содержательно
-   - Каждый [x] в DoD подтверждён реальным артефактом
-   - Любой провал → status: failed
-
-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` — проверка условий для зависимых задач