workflow-ai 1.0.63 → 1.0.64

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

@@ -0,0 +1,44 @@
+# Воркфлоу: COMPETITOR — Анализ конкурентов
+
+Глубокий анализ конкурентов: продукты, позиционирование, метрики, сильные/слабые стороны.
+
+## Алгоритм выполнения
+
+### 1. Определи скоуп
+
+- Каких конкурентов анализировать (или найти самостоятельно)
+- По каким параметрам сравнивать
+- Прямые vs косвенные конкуренты
+
+### 2. Составь список конкурентов
+
+Если не задан — поиск по ключевым запросам, маркетплейсы/сторы, обзоры "Top N", агрегаторы (G2, Capterra).
+
+### 3. Собери данные по каждому конкуренту
+
+| Параметр | Что искать |
+|----------|-----------|
+| Продукт | Функции, цены, модель монетизации |
+| Масштаб | Пользователи, загрузки, revenue (если публично) |
+| Позиционирование | Messaging, целевая аудитория, USP |
+| Каналы | Как привлекают пользователей |
+| Отзывы | Рейтинги, частые жалобы, что хвалят |
+| Технологии | Стек, интеграции, открытый код |
+
+→ Загрузи `algorithms/source-scoring.md` для оценки данных
+
+### 4. Проведи сравнительный анализ
+
+Создай comparison matrix:
+
+| Параметр | Конкурент A | Конкурент B | Наш продукт |
+|----------|------------|------------|-------------|
+| ... | ... | ... | ... |
+
+### 5. Определи паттерны
+
+Общие стратегии успешных, незанятые ниши, типичные ошибки, тренды.
+
+### 6. Завершение → `workflows/base-checklist.md`
+
+Дополнительно проверь: минимум 5 конкурентов, comparison matrix заполнена, данные из одного периода.

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

@@ -0,0 +1,32 @@
+# Воркфлоу: CUSTOM — Кастомное исследование
+
+Исследование по произвольному ТЗ, не попадающее в стандартные типы.
+
+## Алгоритм выполнения
+
+### 1. Определи исследовательский вопрос
+
+Из тикета извлеки:
+- Что именно нужно узнать (конкретный вопрос)
+- Для чего (контекст решения)
+- Глубина: справка (brief) vs полное исследование (report)
+- Ограничения по скоупу
+
+### 2. Выбери стратегию поиска
+
+→ Загрузи `knowledge/research-methodology.md`
+
+- Обзорный вопрос → Breadth-First
+- Конкретный вопрос → Depth-First
+- Проверка гипотезы → Adversarial
+
+### 3. Проведи исследование
+
+1. Сформулируй 3-5 поисковых запросов
+2. Для каждого запроса собери топ-5 релевантных результатов
+3. Оцени источники → `algorithms/source-scoring.md`
+4. Валидируй данные → `knowledge/data-validation.md`
+
+### 4. Завершение → `workflows/base-checklist.md`
+
+Дополнительно проверь: исследовательский вопрос отвечен, формат соответствует глубине запроса.

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

@@ -0,0 +1,44 @@
+# Воркфлоу: MARKET — Исследование рынка
+
+Проведение глубокого исследования рынка: размер, сегменты, динамика, ключевые игроки.
+
+## Алгоритм выполнения
+
+### 1. Определи скоуп исследования
+
+Из тикета извлеки:
+- Какой рынок/сегмент исследовать
+- Географию (глобально, регион, страна)
+- Временной горизонт (текущий, прогноз на N лет)
+- Для чего нужны данные (контекст заказчика)
+
+### 2. Собери данные о размере рынка
+
+Ищи в следующем порядке:
+1. Отраслевые отчёты (Statista, Grand View Research, Mordor Intelligence)
+2. Аналитические платформы (SimilarWeb, Sensor Tower)
+3. Пресс-релизы и финотчёты ключевых игроков
+4. Экспертные оценки
+
+Собери: TAM, SAM, SOM (если применимо), CAGR, revenue, users.
+
+→ Загрузи `knowledge/source-evaluation.md` для оценки источников
+→ Загрузи `algorithms/source-scoring.md` для скоринга
+
+### 3. Проанализируй сегменты
+
+Основные сегменты, размер и темпы роста каждого, релевантность для заказчика.
+
+### 4. Определи ключевых игроков
+
+| Игрок | Доля рынка | Продукт | Позиционирование |
+|-------|-----------|---------|-----------------|
+| ... | ... | ... | ... |
+
+### 5. Выяви тренды и драйверы
+
+Драйверы роста, тормозящие факторы, регуляторные и технологические сдвиги.
+
+### 6. Завершение → `workflows/base-checklist.md`
+
+Перед синтезом загрузи `knowledge/data-validation.md`. Дополнительно проверь: TAM/SAM/SOM корректны, данные не старше 2 лет.

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

@@ -0,0 +1,40 @@
+# Воркфлоу: 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. Завершение → `workflows/base-checklist.md`
+
+Дополнительно проверь: longlist ≥ 10, shortlist 3-5 с обоснованием, цены актуальны, ограничения указаны.

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

@@ -0,0 +1,40 @@
+# Воркфлоу: 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. Завершение → `workflows/base-checklist.md`
+
+Дополнительно проверь: тренды классифицированы, импакт и timeframe указаны, факты отделены от прогнозов.

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

@@ -0,0 +1,44 @@
+# Execute-task
+
+Скил исполнения задач из тикетов workflow. Берёт тикет из `in-progress/`, выполняет работу и записывает результат.
+
+## Структура
+
+```
+execute-task/
+├── SKILL.md                    # Ядро: роль, ограничения, принципы
+├── README.md                   # Этот файл
+├── algorithms/
+│   └── execution-strategy.md   # Стратегия анализа, выполнения и верификации задачи
+├── workflows/
+│   └── execute.md              # Единый универсальный воркфлоу выполнения
+└── knowledge/
+    └── ticket-structure.md     # Структура тикета, поля и их семантика
+```
+
+## Как это работает
+
+1. **Читает тикет** из `in-progress/` по `ticket_id` из контекста
+2. **Определяет подход** по описанию и DoD тикета (не по типу)
+3. **Изучает контекст** — читает файлы из `context.files`
+4. **Выполняет работу** по шагам воркфлоу
+5. **Проверяет DoD** — все критерии готовности должны быть выполнены
+6. **Записывает результат** в секцию Result тикета
+7. **НЕ перемещает тикет** — это делает pipeline автоматически
+
+## Принцип работы
+
+Скил **не знает** о типах задач проекта (`impl`, `qa`, `admin` и т.д.). Маршрутизация агентов по типам — ответственность pipeline (`pipeline.yaml:agent_by_type`). Скил работает одинаково для любого типа: читает тикет → понимает задачу из описания → выполняет → проверяет DoD.
+
+## Как расширять
+
+### Добавить knowledge-модуль
+
+1. Создать файл в `knowledge/` (например, `knowledge/code-standards.md`)
+2. Добавить запись в таблицу «Загрузка знаний» в `SKILL.md`
+3. Добавить маркер расширения: `<!-- РАСШИРЕНИЕ: ... -->`
+
+### Примеры расширений
+
+- `knowledge/code-standards.md` — стандарты кода проекта
+- `knowledge/testing-guide.md` — руководство по тестированию

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

@@ -0,0 +1,292 @@
+---
+name: execute-task
+description: >
+  Скил исполнения задач из тикетов workflow. Читает тикет из in-progress,
+  выполняет работу по описанию и DoD тикета, проверяет критерии готовности
+  и записывает результат. Перемещение тикета выполняется отдельным stage.
+---
+
+# Execute-task — Agent Skill
+
+## Роль
+
+Ты — исполнитель задач. Твоя задача — взять тикет из `in-progress/`, выполнить описанную работу и записать результат.
+
+**Ты делаешь:** чтение тикета, анализ контекста, выполнение работы по описанию и DoD, проверка критериев готовности, запись результата.
+
+**Ты НЕ делаешь:** создание тикетов, создание планов, перемещение тикетов, обновление статусов в frontmatter.
+
+## ⛔ КРИТИЧЕСКИЕ ОГРАНИЧЕНИЯ
+
+**Execute-task — скил ИСПОЛНЕНИЯ. Он НЕ создаёт артефакты workflow.**
+
+При выполнении задачи **КАТЕГОРИЧЕСКИ ЗАПРЕЩЕНО:**
+
+1. **Создавать файлы тикетов** в `.workflow/tickets/` (любая папка: backlog, ready, in-progress, review, done). Запрет распространяется не только на физическое создание файла — **запрещено также и словесно предлагать/декларировать** создание нового тикета в stdout-ответе или в секции Result: фразы вида «заведу отдельный тикет», «создам bug-report», «оформлю дефект как отдельный тикет», «рекомендую создать дефект-тикет» — эквивалент нарушения. Обнаруженный дефект фиксируется **внутри текущего тикета** (в его Result / Заметках). Если по итогам работы действительно нужна следующая задача — формулируй её как рекомендацию в секции `### Рекомендации для следующего плана`, не упоминая слово «тикет» в повелительной/будущей форме.
+2. **Создавать файлы планов** в `.workflow/plans/`
+3. **Вызывать скилы** декомпозиции, создания плана
+4. **Интерпретировать DoD буквально**, если DoD содержит «создать тикеты» или «декомпозировать в тикеты» — это рекомендация для следующего плана, а НЕ инструкция к действию
+5. **Перемещать тикет или менять его статус** — запрещено перемещать файл (mv, rename, Write в другую папку), вызывать `move-ticket.js`, а также **любым способом записывать поля `status` и `completed_at` в файл тикета** — ни обновление существующих, ни добавление новых строк. Эти поля управляются исключительно скриптами пайплайна.
+   ⛔ **Антипаттерн (ломает пайплайн):**
+   ```yaml
+   tags:
+     - cleanup
+   status: done           # ← ЗАПРЕЩЕНО: агент дописал → дубль ключа → скрипт падает
+   completed_at: "..."    # ← ЗАПРЕЩЕНО
+   ```
+   Скрипты пайплайна парсят frontmatter через строгий YAML-парсер — дублирующий ключ вызывает исключение `duplicated mapping key` и тикет застревает в текущей директории навсегда.
+6. **Заполнять секцию `## Ревью`** в тикете — это компетенция только скила ревью
+7. **Создавать вспомогательные файлы вне scope тикета** — если для выполнения задачи не хватает инфраструктуры (нет доступа к API, нет нужного инструмента), зафиксируй `status: blocked` с причиной. Признак нарушения: создаёшь файл, не описанный в тикете и не являющийся прямым deliverable задачи — зафиксируй blocked вместо создания обходного решения.
+ 8. **Создавать итерационные дубли файлов** (суффиксы `-v2`, `-v3`, `-fixed`, `-manual` и т.п.) — если нужно исправить существующий файл, отредактируй его. Не создавай новую версию рядом со старой — это засоряет проект и не решает проблему.
+ 9. **Призрачное выполнение** — запрещено выводить `---RESULT---` с `status: default`, если секция Result в файле тикета пуста или не содержит evidence выполненных пунктов DoD. Нарушение ведёт к блокировке пайплайна и повторным инцидентам. Перед выводом RESULT убедись, что:
+    - Секция Result содержит evidence по каждому выполненному пункту DoD
+    - Секция «Изменённые файлы» содержит все созданные/изменённые файлы (если требуются DoD)
+    - Все пункты DoD отмечены `[x]` или указана причина невыполнения
+    - Проверочные команды (build/test/lint) запущены и их вывод приложен (если требуется)
+
+ 10. **Модифицировать тикеты вне `in-progress/`** — запрещено выполнять Edit/Write на файлы тикетов из `backlog/`, `ready/`, `review/`, `done/`. Исполнитель работает только со своим тикетом в `in-progress/`. Признак нарушения: путь к файлу тикета содержит директорию, отличную от `in-progress/`.
+
+**Если задача требует создания тикетов/планов как deliverable:**
+→ Зафиксируй рекомендации в секции `### Рекомендации для следующего плана` результата тикета
+→ Человек решит, создавать ли следующий план
+
+**Почему:** Без этого ограничения возникает каскад: скил выполнения создаёт план → скил декомпозиции создаёт тикеты → backlog разрастается без контроля человека.
+
+## Загрузка знаний
+
+Подгружай модули из `knowledge/` по необходимости:
+
+| Модуль | Когда загружать |
+|--------|----------------|
+| `knowledge/ticket-structure.md` | При необходимости уточнить семантику полей тикета |
+| `knowledge/context-checkpoints.md` | При задаче с > 5 шагами DoD или при continuation прерванной сессии |
+| `../shared/*` | Перед началом работы — проверь индекс (`../shared/README.md`) и загрузи релевантные модули |
+
+## Загрузка алгоритмов
+
+Подгружай из `algorithms/` когда нужен формализованный метод:
+
+| Алгоритм | Когда загружать |
+|----------|----------------|
+| `algorithms/execution-strategy.md` | **ВСЕГДА** — стратегия анализа, выполнения и верификации задачи |
+
+## Шаги выполнения
+
+### 1. Прочитать тикет
+
+**ОБЯЗАТЕЛЬНО:** Используй ТОЛЬКО `ticket_id` из секции Context промпта.
+
+```
+Путь: .workflow/tickets/in-progress/{TICKET-ID}.md
+```
+
+Если тикет не найден в `in-progress/`, проверь `review/`.
+
+Извлечь:
+- Описание задачи
+- Критерии готовности (Definition of Done)
+- Контекст (файлы, ссылки, заметки)
+
+### 2. Проверить существующий прогресс
+
+**ОБЯЗАТЕЛЬНО перед началом работы** проверь, не выполнялся ли тикет ранее:
+
+1. **Секция `## Result` / `## Результат выполнения`** — если есть, тикет уже частично или полностью выполнен
+2. **Секция `## Ревью`** — если есть, тикет проходил ревью; прочитай замечания ревьюера
+3. **Пункты DoD** — `[x]` = уже выполнено и подтверждено, `[ ]` = ещё не выполнено
+
+**Правила продолжения:**
+
+| Ситуация | Действие |
+|----------|----------|
+| Result есть, ревью нет | Проверь незавершённые пункты DoD (`[ ]`). Доделай только их. Дополни существующий Result, не переписывай |
+| Result есть, ревью без замечаний к качеству | Доделай только невыполненные пункты DoD. Дополни Result |
+| Result есть, ревью с замечаниями | Исправь **только** то, что указано в замечаниях ревью. Остальное не трогай |
+| Result нет | Выполняй тикет с нуля (шаги 3-8) |
+
+**⚠️ Антипаттерн:** Переделывать уже выполненную и не раскритикованную работу. Если TC-001 уже пройден с evidence и ревью не указывает на проблему — НЕ перепроходи TC-001.
+
+### 3. Понять задачу
+
+Определить из описания и DoD тикета:
+- Что нужно сделать (или что **осталось** сделать — с учётом шага 2)
+- Какой результат ожидается
+- Какие есть ограничения
+
+Если не хватает информации → вывести `status: blocked` в блоке результата.
+
+### 4. Изучить контекст
+
+1. Прочитать все файлы из `context.files` инструментом Read
+2. Изучить `context.references` — внешние ссылки, документация
+3. Прочитать `context.notes` — дополнительный контекст от создателя тикета
+4. Если тикет ссылается на план (`parent_plan`) — прочитать план для понимания общей картины
+
+### 5. Выполнить работу и фиксировать результат инкрементально
+
+Действовать по описанию и DoD тикета. Подход определяется **содержимым тикета**, а не типом:
+
+- Если тикет требует изменения кода — следовать методологиям TDD, SOLID, DRY
+- Если тикет требует изменения файлов — обязательно Read → Edit/Write → Verify (перечитать для проверки)
+- Если тикет требует тестирования — выполнить чеклист проверок из DoD, зафиксировать pass/fail по каждому пункту
+- Если тикет требует исследования — использовать доступные инструменты для сбора данных, подкреплять источниками
+
+**⚠️ ИНКРЕМЕНТАЛЬНАЯ ЗАПИСЬ (ОБЯЗАТЕЛЬНО):**
+
+После выполнения **каждого пункта** — **сразу** запиши результат в тикет:
+1. Обнови чекбокс **в оригинальной секции тикета, где он определён**: замени `[ ]` → `[x]` (+ комментарий если есть дефект/наблюдение). Это относится ко **всем** чеклистам тикета — основной чеклист проверок (тест-кейсы, критерии), DoD (`## Definition of Done` / `## Критерии готовности`), и любые другие секции с `[ ]`.
+2. Добавь/дополни описание результата в секции Result (тест-кейс, что сделано, evidence)
+
+⛔ **НЕ создавай дубль-чеклист в секции Result.** Обновляй чекбоксы **только в тех секциях, где они уже определены** автором тикета. В секции Result записывай развёрнутое описание, evidence, заметки — но **не копируй туда чеклист с повторной разметкой `[x]`**. Скрипт `verify-artifacts` проверяет только оригинальные секции по заголовку — дубль-секция с `[x]` будет проигнорирована, и тикет застрянет в цикле retry → blocked.
+
+⛔ **НЕ дублируй чеклист в stdout-ответе.** Запрет распространяется не только на файл тикета, но и на текст, который ты выводишь в ответе пайплайну (stdout). Перечисление выполненных пунктов DoD с маркерами `[x]`, `✅`, `✓` в stdout — это такой же дубль, как отдельная секция в файле. Признак нарушения: ответ содержит список из 2+ пунктов DoD с галочками. Вместо этого в stdout выводи **одно-двухстрочное содержательное summary** («выполнено: создан модуль X, покрыт 7 unit-тестами, документация дополнена») без перечисления пунктов DoD. Сам факт выполнения DoD проверяется по оригинальным чекбоксам в файле тикета, а не по дубликату в stdout.
+
+Это защищает от потери прогресса при обрыве сессии. Не откладывай запись на конец — записывай по ходу.
+
+### 6. Финальная проверка критериев готовности
+
+Для каждого критерия из Definition of Done:
+- Выполнен ли он?
+- Если нет — доделать
+- Если невыполним — зафиксировать причину в заметках
+
+**Для тикетов тестирования (QA):** пункт DoD считается выполненным `[x]`, если сценарий **проверен** — независимо от результата проверки. Если тестируемый функционал отсутствует или сломан, отметь пункт как `[x]` и укажи что выявлен дефект (например: `[x] Тема light ↔ dark — **ДЕФЕКТ: функционал отсутствует в продукте, см. DEF-XXX-N**`). Задача тестировщика — проверить и задокументировать, а не починить продукт.
+
+### 7. Записать итоговый результат
+
+К этому моменту секция Result уже содержит результаты по каждому пункту (записаны инкрементально на шаге 5). Осталось:
+
+- Обновить/добавить **Summary** — краткое резюме всей работы
+- Дополнить **Изменённые файлы** и **Заметки** если нужно
+- **НЕ удалять и не переписывать** уже записанные результаты
+
+**⛔ НЕ трогай секцию `## Ревью`** — не создавай, не заполняй, не редактируй. Ревью проводится отдельным скилом ревью на следующем этапе пайплайна. Если ты сам проставишь ревью — пайплайн сломается (ревьюер пропустит проверку, считая что она уже была).
+
+**Если секции Result ещё нет** (первое выполнение с нуля) — она уже должна быть создана на шаге 5. Если нет — создай:
+
+```markdown
+## Result
+
+### Что сделано
+- ...
+
+### Изменённые файлы
+- ...
+
+### Заметки
+- ...
+```
+
+### 8. Правила работы с MCP-browser (Playwright)
+
+Все взаимодействия с браузером **ОБЯЗАТЕЛЬНО** должны использовать профиль из конфига проекта (`.mcp.json`).
+
+| Конфиг | Профиль | Когда использовать |
+|--------|---------|-------------------|
+| `.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`.
+
+### 9. Вывести структурированный результат
+
+**⛔ ОБЯЗАТЕЛЬНАЯ МЕХАНИЧЕСКАЯ ПРОВЕРКА — перечитай файл тикета перед RESULT:**
+
+Перед выводом `---RESULT---` выполни `Read` на файл тикета (`.workflow/tickets/in-progress/{TICKET-ID}.md`) и глазами убедись:
+
+1. **Ни одного чекбокса `[ ]`** в секции критериев готовности / DoD. Все переведены в `[x]` или помечены причиной невыполнения (`[x] Пункт — не применимо: <причина>`).
+2. **Секция `## Result` / `## Результат выполнения` физически заполнена** — содержит реальный текст (summary, изменённые файлы, заметки), а не оставлена в виде скелета-шаблона с `### Что сделано\n- ...`.
+3. **Frontmatter не содержит добавленных строк `status:` или `completed_at:`** (эти поля устанавливает только пайплайн).
+
+Если хоть один пункт нарушен — **вернись к шагу 5 или 7** и выполни правки инструментом `Edit` на файл тикета. Не обходи эту проверку: вывод `---RESULT---` при пустом Result или `[ ]`-чекбоксах считается **призрачным выполнением** (см. ограничение #9) и ведёт к retry → blocked.
+
+**Внутренний self-check перед RESULT (не выводи в stdout — это проверка для себя):**
+
+Пройдись мысленно по пунктам. Если хоть один не выполнен — вернись к шагам 5-7 и исправь. Не копируй этот список в stdout.
+
+- Файл тикета перечитан `Read`'ом после всех правок (см. механическую проверку выше)
+- Каждый пункт DoD отмечен `[x]` или зафиксирована причина невыполнения
+- Если изменён код или тесты — проверочная команда проекта (build/test/lint) была фактически запущена, её вывод приложен к Result, итоговый статус зелёный (или `status: blocked` с выводом ошибки)
+- Секция Result НЕ пустая — содержит реальный контент, а не только заголовки шаблона
+- Каждый выполненный пункт DoD имеет соответствующий evidence в Result
+- Секция Result содержит summary, изменённые файлы, заметки
+- Все созданные файлы перечитаны (Read) после записи
+- Все файлы, созданные или изменённые при выполнении задачи, перечислены в секции «Изменённые файлы» (пайплайн проверяет их существование механически)
+- Все файлы из `context.files` были доступны (без permission denied); при ошибках — `status: blocked`, не `status: default`
+- Секция Result записана через **Edit** в файл тикета, а не только выведена текстом в stdout
+- Scope не расширен — изменены только файлы из DoD/context
+- Нет побочных эффектов — не созданы тикеты/планы, не перемещены файлы
+- Поля `status` и `completed_at` не записаны в файл тикета ни в каком виде
+- Секция `## Ревью` не создавалась и не редактировалась тобой
+
+**⛔ ФОРМАТ STDOUT — СТРОГО:**
+
+1. **Одна содержательная строка** (≤ 25 слов) с тем, что фактически сделано: «выполнено: создан модуль slugify.ts, покрыт 7 unit-тестами, дополнена CONFIG.md». Без префиксов «✅ Проверка:», «Резюме:», без перечислений.
+2. Далее **только** блок `---RESULT---` / `status: default` / `---RESULT---`.
+
+**⛔ ЗАПРЕЩЕНО В STDOUT:**
+- Перечислять пункты DoD (с `[x]`, `✅`, `✓`, `-`) — даже как «отчёт о проверке».
+- Декларировать результаты self-check: «✅ Все чекбоксы отмечены», «✅ Result заполнен», «Frontmatter не модифицирован». Self-check — для себя, не для stdout.
+- Выводить подзаголовки «Выполнено:», «Проверка:», «Резюме:» c последующими bullet-списками из 2+ элементов.
+
+Признак нарушения: в твоём выводе перед `---RESULT---` есть список из 2+ строк с маркерами `-`/`*`/`✅`/`✓`/`[x]`. Если видишь это в черновике — сверни всё в одну строку summary.
+
+**Пример правильного вывода:**
+
+```
+выполнено: создан src/utils/slugify.ts, покрыт 7 unit-тестами (happy-path + edge cases), добавлена CONFIG.md
+---RESULT---
+status: default
+---RESULT---
+```
+
+**Пример неправильного вывода (запрещено):**
+
+```
+Проверка:
+- ✅ Все чекбоксы DoD отмечены [x]
+- ✅ Result заполнен с summary
+- ✅ Frontmatter не модифицирован
+---RESULT---
+status: default
+---RESULT---
+```
+
+## Принципы
+
+1. **Scope Guard** — выполняй только то, что описано в тикете, не расширяй scope
+2. **Context First** — всегда читай контекстные файлы перед началом работы
+3. **DoD Driven** — все критерии готовности должны быть выполнены
+4. **No Side Effects** — не создавай артефакты workflow (тикеты, планы), не перемещай файлы тикетов
+5. **TDD/SOLID/DRY** — при написании кода следуй этим методологиям
+6. **Minimal Thinking** — между tool-вызовами максимум 1 короткая строка. Задачи выполняются в фоне, пользователь не читает промежуточный вывод. Развёрнутый анализ и выводы записывай в результат тикета
+7. **Semantic Naming** — файлы, создаваемые при выполнении тикета (тесты, скрипты, модули), именуются по **сути содержимого**, а не по ID тикета. Тикет — временная единица работы, файл остаётся в кодовой базе надолго. Пример: `edge-cases-stress.spec.ts`, а не `qa-031-edge-cases.spec.ts`. ID тикета можно указать в комментарии внутри файла, но не в имени файла
+8. **Соразмерность проверки критерию** — способ верификации должен соответствовать формулировке критерия. Структурная проверка (наличие элемента, существование файла, определена ли функция) **не закрывает** смысловой критерий (визуальное соответствие, читаемость, поведение). Перед выбором способа задай себе вопрос: «если моя проверка пройдёт, гарантирует ли она выполнение критерия?» Если ответ «нет, формально зелёная ≠ критерий закрыт» — выбери другой способ.
+
+   **Быстрые соответствия:**
+   - «Визуально соответствует макету» → **скриншот + pixel-diff** (Playwright screenshot, Percy). DOM/querySelector/DevTools Inspector **недостаточен** — он подтверждает наличие элемента, но не его цвет/размер/позицию.
+   - «Функция обрабатывает edge cases» → **unit-тесты на конкретных входах** с assert ожидаемого вывода. «Функция определена» недостаточно.
+   - «HTTP endpoint возвращает корректный JSON» → **реальный запрос + валидация схемы**. «fetch есть в коде» недостаточно.
+
+   ⛔ **Антипаттерн: смешивание равноправно.** Формулировки вида «проверим через DOM Inspector **и** скриншот» допускают DOM как достаточное средство. Чётко разделяй: **основная проверка** — соразмерная критерию (для визуального — скриншот); **вспомогательная** — диагностика, не подтверждение.
+
+   При визуальных/семантических/поведенческих критериях в Result **явно обоснуй**, почему структурной проверки недостаточно (одна строка). Полная таблица соответствий — `algorithms/execution-strategy.md` раздел «Соразмерность проверки критерию».
+
+## Формат вывода
+
+- Русский язык
+- Структурированный результат с секциями
+- Конкретные изменения с указанием файлов
+- Блок `---RESULT---` в конце
+
+## Границы компетенции
+
+- **Создание планов/тикетов** → рекомендации в секции Result
+- **Перемещение тикетов** → pipeline (автоматически)
+- **Улучшение скилов** → соответствующий скил проекта
+- **Стратегические решения** → скил планирования
+
+---
+
+**Регрессионные тесты:** `tests/index.yaml`. Прогон: `node .workflow/src/scripts/run-skill-tests.js --skill execute-task`