workflow-ai 1.0.31 → 1.0.33

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "workflow-ai",
-  "version": "1.0.31",
+  "version": "1.0.33",
   "description": "AI Agent Workflow Coordinator — kanban-based pipeline for AI coding agents",
   "type": "module",
   "bin": {

package/src/runner.mjs

@@ -289,7 +289,19 @@ class PromptBuilder {
    * @returns {string} Промпт для агента
    */
   build(stage, stageId) {
-    const parts = [stage.skill || stageId];
+    const skillName = stage.skill || stageId;
+    const ticketId = this.context.ticket_id;
+    const parts = [];
+
+    // Директивная первая строка — агент сразу понимает задание
+    if (ticketId) {
+      const skillPath = `.workflow/src/skills/${skillName}/SKILL.md`;
+      parts.push(`Выполни скилл "${skillName}" для тикета ${ticketId}.`);
+      parts.push(`Инструкция скилла: ${skillPath}`);
+      parts.push(`Прочитай инструкцию и выполни все шаги.`);
+    } else {
+      parts.push(skillName);
+    }
 
     // Добавляем контекст если есть непустые значения
     const contextEntries = Object.entries(this.context)
@@ -837,8 +849,15 @@ class StageExecutor {
       const timeout = this.pipeline.execution?.timeout_per_stage || 300;
       const args = [...agent.args];
 
-      // Промпт всегда передаётся последним аргументом
-      args.push(prompt);
+      // Если args содержит -p с ролью — объединяем роль и промпт в один аргумент
+      // Иначе Claude CLI интерпретирует роль как промпт, а реальный промпт игнорирует
+      const lastPIdx = args.lastIndexOf('-p');
+      if (lastPIdx !== -1 && lastPIdx < args.length - 1) {
+        const rolePrompt = args[lastPIdx + 1];
+        args[lastPIdx + 1] = `${rolePrompt}\n\n${prompt}`;
+      } else {
+        args.push(prompt);
+      }
 
       // Логгируем команду перед запуском (вместо промпта — имя skill)
       if (this.logger) {

package/src/scripts/check-plan-decomposed.js

@@ -8,7 +8,7 @@
  *   B) Если plan_id НЕ задан — сканирует все планы в plans/current/
  *
  *   Для каждого плана:
- *   1. Если есть тикеты (backlog/, ready/, in-progress/, review/) с parent_plan == planId — decomposed
+ *   1. Если есть тикеты (backlog/, ready/, in-progress/, review/, done/, blocked/) с parent_plan == planId — decomposed
  *   2. Иначе — needs_decomposition
  *
  *   Результат:
@@ -31,7 +31,25 @@ const WORKFLOW_DIR = path.join(PROJECT_DIR, '.workflow');
 const TICKETS_DIR = path.join(WORKFLOW_DIR, 'tickets');
 const PLANS_DIR = path.join(WORKFLOW_DIR, 'plans', 'current');
 
-const TICKET_DIRS = ['backlog', 'ready', 'in-progress', 'review'];
+const TICKET_DIRS = ['backlog', 'ready', 'in-progress', 'review', 'done', 'blocked'];
+
+/**
+ * Читает статус плана из frontmatter.
+ * Только планы со статусом "approved" могут быть декомпозированы автоматически.
+ * Планы со статусом "draft", "active" или без статуса — пропускаются.
+ */
+function getPlanStatus(planFile) {
+  const fullPath = path.join(WORKFLOW_DIR, planFile);
+  if (!fs.existsSync(fullPath)) return null;
+  try {
+    const content = fs.readFileSync(fullPath, 'utf8');
+    const { frontmatter } = parseFrontmatter(content);
+    return frontmatter.status || null;
+  } catch (e) {
+    console.error(`[WARN] Failed to read plan status from ${planFile}: ${e.message}`);
+    return null;
+  }
+}
 
 /**
  * Проверяет, есть ли тикеты, привязанные к данному плану
@@ -113,6 +131,13 @@ async function main() {
 
     console.log(`[INFO] Found plan file: ${planFile}`);
 
+    const planStatus = getPlanStatus(planFile);
+    if (planStatus !== 'approved') {
+      console.log(`[INFO] Plan ${planId} has status "${planStatus}" (not "approved") — skipping decomposition`);
+      printResult({ status: 'decomposed' });
+      return;
+    }
+
     if (hasTicketsForPlan(planId)) {
       console.log(`[INFO] Plan ${planId} already has tickets — decomposed`);
       printResult({ status: 'decomposed' });
@@ -137,6 +162,11 @@ async function main() {
   console.log(`[INFO] Found ${allPlans.length} plan(s) in plans/current/`);
 
   for (const { planId: pid, planFile } of allPlans) {
+    const planStatus = getPlanStatus(planFile);
+    if (planStatus !== 'approved') {
+      console.log(`[INFO] Plan ${pid} has status "${planStatus}" (not "approved") — skipping`);
+      continue;
+    }
     if (!hasTicketsForPlan(pid)) {
       console.log(`[INFO] Plan ${pid} has no tickets — needs decomposition`);
       printResult({ status: 'needs_decomposition', plan_file: planFile });

package/src/skills/check-relevance/SKILL.md

@@ -1,224 +1,224 @@
----
-name: check-relevance
-description: Проверить актуальность тикета перед выполнением. Используется для предотвращения выполнения устаревших или уже завершённых задач.
----
-
-# Проверка актуальности тикета
-
-> **ЗАПРЕТ:** НЕ перемещай, НЕ удаляй, НЕ переименовывай файлы тикетов. Твоя задача — ТОЛЬКО прочитать, при irrelevant добавить запись в таблицу ревью, и вернуть вердикт. Перемещение выполняет отдельный stage пайплайна. Проверяй ТОЛЬКО тикет из `ticket_id` контекста, игнорируй остальные поля (`ready_tickets` и т.д.).
-
-Этот skill проверяет актуальность тикета перед его выполнением. Предотвращает выполнение устаревших/неактуальных задач.
-
-## Когда использовать
-
-- Тикет только что перемещён в `in-progress/`
-- Перед выполнением основной задачи (execute-task)
-- Для фильтрации задач с неактивными планами или выполненными DoD
-
-## Шаги проверки
-
-### 0. Быстрый выход по существующему ревью
-
-**До любых проверок** найди в тикете секцию `## Ревью`.
-
-Если последняя запись имеет статус `⏭ skipped` — тикет уже был проверен и пропущен. **Повторно проверять НЕ НАДО**, новую запись skipped добавлять НЕ НАДО. Немедленно верни:
-
-```
----RESULT---
-status: irrelevant
-reason: already_skipped
----RESULT---
-```
-
-Если последней записи нет или статус другой — переходи к шагу 1.
-
-### 1. Прочитать тикет
-
-**ОБЯЗАТЕЛЬНО:** Используй `ticket_id` из секции Context промпта.
-
-```
-Путь: .workflow/tickets/in-progress/{TICKET-ID}.md
-```
-
-Извлечь:
-- `parent_plan` — ссылка на родительский план
-- `dependencies` — зависимости тикета
-- `conditions` — условия выполнения
-- Критерии готовности (Definition of Done)
-
-### 2. Проверить родительский план
-
-Проверить статус родительского плана:
-
-```
-Путь: .workflow/plans/current/{PARENT_PLAN}.md
-```
-
-**Критерии неактуальности:**
-- План имеет `status: completed` — план уже завершён
-- План имеет `status: archived` — план заархивирован
-- План имеет `status: cancelled` — план отменён
-
-**Если план неактивен:** тикет `irrelevant`
-
-### 3. Проверить выполнение DoD
-
-Проверить все критерии из Definition of Done тикета:
-
-**Критерии неактуальности:**
-- Все критерии уже отмечены как выполненные `[x]`
-- В секции "Результат выполнения" уже есть заполненные данные
-
-**Если DoD полностью выполнен:** тикет `irrelevant` (задача уже сделана)
-
-### 4. Проверить зависимости
-
-Проверить тикеты из секции `dependencies`:
-
-```
-Путь: .workflow/tickets/{status}/{DEP-TICKET}.md
-```
-
-**Критерии неактуальности:**
-- Зависимый тикет находится в `blocked/` с причиной "неактуально"
-- Зависимый тикет был удалён или перемещён в архив
-
-**Если критические зависимости неактуальны:** тикет `irrelevant`
-
-### 5. Проверить статус blocked
-
-**Проверить секцию `## Блокировки` или frontmatter:**
-
-Если тикет помечен как заблокированный → **неактуален**.
-
-### 6. При irrelevant — записать в таблицу ревью тикета
-
-Если вердикт `irrelevant`, **ОБЯЗАТЕЛЬНО** добавь запись в секцию `## Ревью` тикета:
-
-- Если секции `## Ревью` нет — создай её в конце файла
-- Если таблица уже есть — добавь строку в конец таблицы
-
-Формат записи:
-
-```
-| {текущая дата} | ⏭️ skipped | {причина irrelevant: plan_inactive / dod_completed / dependencies_inactive} |
-```
-
-Пример:
-
-```markdown
-## Ревью
-
-| Дата | Статус | Самари |
-|------|--------|--------|
-| 2026-03-10 | ⏭️ skipped | DoD уже выполнен, тикет неактуален |
-```
-
-Это единственная допустимая запись в файл — только добавление строки в таблицу ревью.
-
-### 7. Принять решение
-
-На основе проверок вывести результат:
-
-| Проверка | Результат | Статус |
-|----------|-----------|--------|
-| План неактивен | Plan inactive | `irrelevant` |
-| DoD выполнен | DoD completed | `irrelevant` |
-| Зависимости неактуальны | Dependencies inactive | `irrelevant` |
-| Все проверки пройдены | All checks passed | `relevant` |
-
-## Fail-safe дизайн
-
-**Важно:** При неизвестном статусе или ошибке проверки использовать fallback → `relevant`
-
-Это гарантирует что тикет будет выполнен даже при проблемах с проверкой. Лучше выполнить лишний тикет, чем пропустить нужный.
-
-## Формат результата
-
-Обязательно выведи блок результата:
-
-```
----RESULT---
-status: relevant
----RESULT---
-```
-
-Или для неактуальных:
-
-```
----RESULT---
-status: irrelevant
-reason: <причина: plan_inactive / dod_completed / dependencies_inactive>
----RESULT---
-```
-
-## Примеры
-
-### Пример 1: Тикет актуален
-
-```markdown
-## Result
-
-### Что проверено
-- Родительский план PLAN-001: status: active ✓
-- DoD: не все критерии выполнены ✓
-- Зависимости: все активны ✓
-
-### Решение
-Тикет актуален, можно выполнять
-
----RESULT---
-status: relevant
----RESULT---
-```
-
-### Пример 2: План завершён
-
-```markdown
-## Result
-
-### Что проверено
-- Родительский план PLAN-001: status: completed ✗
-
-### Решение
-План уже завершён, тикет неактуален
-
----RESULT---
-status: irrelevant
-reason: plan_inactive
----RESULT---
-```
-
-### Пример 3: DoD выполнен
-
-```markdown
-## Result
-
-### Что проверено
-- Родительский план PLAN-001: status: active ✓
-- DoD: все критерии отмечены [x] ✗
-- Секция "Результат выполнения": заполнена ✗
-
-### Решение
-Задача уже выполнена, тикет неактуален
-
----RESULT---
-status: irrelevant
-reason: dod_completed
----RESULT---
-```
-
-## Интеграция с pipeline
-
-Этот skill используется в stage `check-relevance` который размещается между:
-- `move-to-in-progress` → `check-relevance` → `execute-task`
-
-Переходы:
-- `relevant` → перейти к `execute-task`
-- `irrelevant` → переместить тикет в `done/` с пометкой
-- `default` (fallback) → `execute-task` (fail-safe)
-
-## Связанные skills
-
-- `execute-task` — выполняет задачу после проверки актуальности
-- `move-ticket` — перемещает неактуальные тикеты в done/
+---
+name: check-relevance
+description: Проверить актуальность тикета перед выполнением. Используется для предотвращения выполнения устаревших или уже завершённых задач.
+---
+
+# Проверка актуальности тикета
+
+> **ЗАПРЕТ:** НЕ перемещай, НЕ удаляй, НЕ переименовывай файлы тикетов. Твоя задача — ТОЛЬКО прочитать, при irrelevant добавить запись в таблицу ревью, и вернуть вердикт. Перемещение выполняет отдельный stage пайплайна. Проверяй ТОЛЬКО тикет из `ticket_id` контекста, игнорируй остальные поля (`ready_tickets` и т.д.).
+
+Этот skill проверяет актуальность тикета перед его выполнением. Предотвращает выполнение устаревших/неактуальных задач.
+
+## Когда использовать
+
+- Тикет только что перемещён в `in-progress/`
+- Перед выполнением основной задачи (execute-task)
+- Для фильтрации задач с неактивными планами или выполненными DoD
+
+## Шаги проверки
+
+### 0. Быстрый выход по существующему ревью
+
+**До любых проверок** найди в тикете секцию `## Ревью`.
+
+Если последняя запись имеет статус `⏭ skipped` — тикет уже был проверен и пропущен. **Повторно проверять НЕ НАДО**, новую запись skipped добавлять НЕ НАДО. Немедленно верни:
+
+```
+---RESULT---
+status: irrelevant
+reason: already_skipped
+---RESULT---
+```
+
+Если последней записи нет или статус другой — переходи к шагу 1.
+
+### 1. Прочитать тикет
+
+**ОБЯЗАТЕЛЬНО:** Используй `ticket_id` из секции Context промпта.
+
+```
+Путь: .workflow/tickets/in-progress/{TICKET-ID}.md
+```
+
+Извлечь:
+- `parent_plan` — ссылка на родительский план
+- `dependencies` — зависимости тикета
+- `conditions` — условия выполнения
+- Критерии готовности (Definition of Done)
+
+### 2. Проверить родительский план
+
+Проверить статус родительского плана:
+
+```
+Путь: .workflow/plans/current/{PARENT_PLAN}.md
+```
+
+**Критерии неактуальности:**
+- План имеет `status: completed` — план уже завершён
+- План имеет `status: archived` — план заархивирован
+- План имеет `status: cancelled` — план отменён
+
+**Если план неактивен:** тикет `irrelevant`
+
+### 3. Проверить выполнение DoD
+
+Проверить все критерии из Definition of Done тикета:
+
+**Критерии неактуальности:**
+- Все критерии уже отмечены как выполненные `[x]`
+- В секции "Результат выполнения" уже есть заполненные данные
+
+**Если DoD полностью выполнен:** тикет `irrelevant` (задача уже сделана)
+
+### 4. Проверить зависимости
+
+Проверить тикеты из секции `dependencies`:
+
+```
+Путь: .workflow/tickets/{status}/{DEP-TICKET}.md
+```
+
+**Критерии неактуальности:**
+- Зависимый тикет находится в `blocked/` с причиной "неактуально"
+- Зависимый тикет был удалён или перемещён в архив
+
+**Если критические зависимости неактуальны:** тикет `irrelevant`
+
+### 5. Проверить статус blocked
+
+**Проверить секцию `## Блокировки` или frontmatter:**
+
+Если тикет помечен как заблокированный → **неактуален**.
+
+### 6. При irrelevant — записать в таблицу ревью тикета
+
+Если вердикт `irrelevant`, **ОБЯЗАТЕЛЬНО** добавь запись в секцию `## Ревью` тикета:
+
+- Если секции `## Ревью` нет — создай её в конце файла
+- Если таблица уже есть — добавь строку в конец таблицы
+
+Формат записи:
+
+```
+| {текущая дата} | ⏭️ skipped | {причина irrelevant: plan_inactive / dod_completed / dependencies_inactive} |
+```
+
+Пример:
+
+```markdown
+## Ревью
+
+| Дата | Статус | Самари |
+|------|--------|--------|
+| 2026-03-10 | ⏭️ skipped | DoD уже выполнен, тикет неактуален |
+```
+
+Это единственная допустимая запись в файл — только добавление строки в таблицу ревью.
+
+### 7. Принять решение
+
+На основе проверок вывести результат:
+
+| Проверка | Результат | Статус |
+|----------|-----------|--------|
+| План неактивен | Plan inactive | `irrelevant` |
+| DoD выполнен | DoD completed | `irrelevant` |
+| Зависимости неактуальны | Dependencies inactive | `irrelevant` |
+| Все проверки пройдены | All checks passed | `relevant` |
+
+## Fail-safe дизайн
+
+**Важно:** При неизвестном статусе или ошибке проверки использовать fallback → `relevant`
+
+Это гарантирует что тикет будет выполнен даже при проблемах с проверкой. Лучше выполнить лишний тикет, чем пропустить нужный.
+
+## Формат результата
+
+Обязательно выведи блок результата:
+
+```
+---RESULT---
+status: relevant
+---RESULT---
+```
+
+Или для неактуальных:
+
+```
+---RESULT---
+status: irrelevant
+reason: <причина: plan_inactive / dod_completed / dependencies_inactive>
+---RESULT---
+```
+
+## Примеры
+
+### Пример 1: Тикет актуален
+
+```markdown
+## Result
+
+### Что проверено
+- Родительский план PLAN-001: status: active ✓
+- DoD: не все критерии выполнены ✓
+- Зависимости: все активны ✓
+
+### Решение
+Тикет актуален, можно выполнять
+
+---RESULT---
+status: relevant
+---RESULT---
+```
+
+### Пример 2: План завершён
+
+```markdown
+## Result
+
+### Что проверено
+- Родительский план PLAN-001: status: completed ✗
+
+### Решение
+План уже завершён, тикет неактуален
+
+---RESULT---
+status: irrelevant
+reason: plan_inactive
+---RESULT---
+```
+
+### Пример 3: DoD выполнен
+
+```markdown
+## Result
+
+### Что проверено
+- Родительский план PLAN-001: status: active ✓
+- DoD: все критерии отмечены [x] ✗
+- Секция "Результат выполнения": заполнена ✗
+
+### Решение
+Задача уже выполнена, тикет неактуален
+
+---RESULT---
+status: irrelevant
+reason: dod_completed
+---RESULT---
+```
+
+## Интеграция с pipeline
+
+Этот skill используется в stage `check-relevance` который размещается между:
+- `move-to-in-progress` → `check-relevance` → `execute-task`
+
+Переходы:
+- `relevant` → перейти к `execute-task`
+- `irrelevant` → переместить тикет в `done/` с пометкой
+- `default` (fallback) → `execute-task` (fail-safe)
+
+## Связанные skills
+
+- `execute-task` — выполняет задачу после проверки актуальности
+- `move-ticket` — перемещает неактуальные тикеты в done/

package/src/skills/coach/README.md

@@ -0,0 +1,100 @@
+# Coach — Модульный скилл
+
+Скилл для агента workflow-ai, обрабатывающего тикеты `COACH-*`.
+Мета-скил для создания, аудита и совершенствования других скилов.
+
+## Структура
+
+```
+coach/
+├── SKILL.md                          # Ядро: роль, маршрутизация, принципы
+│
+├── workflows/                        # Пошаговые воркфлоу по типам тикетов
+│   ├── create.md                     #   COACH-*: CREATE — создание нового скила
+│   ├── audit.md                      #   COACH-*: AUDIT — полный аудит скила
+│   ├── analyze.md                    #   COACH-*: ANALYZE — анализ эффективности
+│   ├── improve.md                    #   COACH-*: IMPROVE — точечное улучшение
+│   ├── research.md                   #   COACH-*: RESEARCH — поиск знаний
+│   └── review.md                     #   COACH-*: REVIEW — ревью структуры и качества
+│
+├── knowledge/                        # Экспертные знания (подгружаются по запросу)
+│   ├── skill-anatomy.md              #   Эталонная структура скила
+│   ├── common-antipatterns.md        #   Типичные ошибки в скилах
+│   └── prompt-engineering.md         #   Принципы написания инструкций
+│
+├── algorithms/                       # Формализованные методы принятия решений
+│   ├── skill-scoring.md              #   Оценка качества скила (0–100)
+│   ├── gap-analysis.md               #   Поиск пробелов в покрытии скила
+│   └── improvement-prioritization.md #   Приоритизация улучшений (ICE)
+│
+├── templates/                        # Шаблоны вывода
+│   ├── new-skill.md                  #   Структура нового скила
+│   ├── audit-report.md               #   Результат аудита
+│   └── improvement-plan.md           #   План улучшений
+│
+└── README.md                         # Этот файл
+```
+
+## Как это работает
+
+1. Агент получает тикет `COACH-*` из `in-progress/`
+2. **SKILL.md** — всегда в контексте: роль, маршрутизация, принципы
+3. По типу тикета агент подгружает нужный **workflow**
+4. Воркфлоу ссылается на **knowledge** и **algorithms** по необходимости
+5. Результат оформляется по **template**
+
+## Типичные сценарии
+
+| Задача | Тикет | Воркфлоу |
+|--------|-------|----------|
+| Создать скил для новой роли | COACH-001: CREATE | `workflows/create.md` |
+| Проверить качество GML-скила | COACH-002: AUDIT | `workflows/audit.md` |
+| Понять почему тикеты GML выполняются плохо | COACH-003: ANALYZE | `workflows/analyze.md` |
+| Добавить знания в скил | COACH-004: IMPROVE | `workflows/improve.md` |
+| Найти лучшие практики для домена | COACH-005: RESEARCH | `workflows/research.md` |
+| Быстро проверить новый скил | COACH-006: REVIEW | `workflows/review.md` |
+
+## Как расширять
+
+### Добавить новый тип тикета
+
+1. Создай `workflows/new-type.md` с алгоритмом выполнения
+2. Добавь строку в таблицу маршрутизации в `SKILL.md`
+3. Если нужен шаблон вывода — добавь в `templates/`
+
+### Добавить новые знания
+
+1. Создай файл в `knowledge/` (например `knowledge/skill-versioning.md`)
+2. Добавь строку в таблицу «Загрузка знаний» в `SKILL.md`
+3. Укажи в каких воркфлоу его подгружать
+
+### Добавить новый алгоритм
+
+1. Создай файл в `algorithms/` (например `algorithms/complexity-estimation.md`)
+2. Добавь строку в таблицу «Загрузка алгоритмов» в `SKILL.md`
+3. Укажи в каких воркфлоу его использовать
+
+### Добавить новый шаблон
+
+1. Создай файл в `templates/`
+2. Укажи в соответствующем воркфлоу ссылку на шаблон
+
+### Расширить существующие модули
+
+Каждый файл в `knowledge/` содержит маркер:
+```
+<!-- РАСШИРЕНИЕ: добавляй ... ниже -->
+```
+Дописывай новую информацию после этого маркера.
+
+## Примеры расширений
+
+**Новый антипаттерн:** допиши в `knowledge/common-antipatterns.md` строку в таблицу по формату существующих.
+
+**Новый критерий scoring:** допиши в `algorithms/skill-scoring.md` строку в нужную категорию (пересчитай максимум баллов).
+
+**Новый тип исследования:** допиши в `workflows/research.md` строку в таблицу поисковых запросов.
+
+**Новый воркфлоу (пример — миграция скила на новую версию):**
+1. Создай `workflows/migrate.md`
+2. В `SKILL.md` добавь строку: `| MIGRATE | «миграция», «обновить формат» | ... | → workflows/migrate.md |`