mister-wolf 2.14.1 → 2.15.1

package/templates/base/skills/wolf-sdd/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: wolf-sdd
-description: "Используй для исполнения планов реализации с независимыми задачами через субагентов: свежий воркер на каждую задачу через executor-lead + двухстадийное ревью worker-reviewer (соответствие брифу, затем качество)."
+description: 'Используй для исполнения планов реализации с независимыми задачами через субагентов: свежий воркер на каждую задачу через executor-lead + двухстадийное ревью worker-reviewer (соответствие брифу, затем качество).'
 ---
 
 # wolf-sdd: разработка через субагентов
@@ -40,11 +40,20 @@ digraph when_to_use {
 ```
 
 **vs wolf-execute (параллельная/линейная сессия):**
+
 - Та же сессия (без переключения контекста)
 - Свежий воркер на задачу (без загрязнения контекста)
 - Двухстадийное ревью после каждой задачи: сначала бриф, затем качество
 - Быстрее итерация (без человека между задачами)
 
+## Вход: план
+
+Источник входа — план волны: `requirements.md` + `design.md` + `plan.md` в `docs/dev/<дата>-<slug>/`. Спека-монолит как вход плана не используется.
+
+Задачи плана — чекбоксы `- [ ]`: исполнитель переворачивает чекбокс в `[x]` в конце
+задачи вместе со строкой «сделано → коммит <hash>» — часть Definition of Done задачи.
+wolf-sdd — основной диспетчерский путь конвейера.
+
 ## Ход процесса
 
 ```dot
@@ -92,6 +101,10 @@ digraph process {
 }
 ```
 
+## Валидация волны
+
+- Валидация волны сверяется с `docs/dev/<дата>-<slug>/test-plan.md`: прогон сценариев — заготовки финальной проверки плана.
+
 ## Тиринг задач
 
 Используй наименее мощную модель, которая справится с ролью — это экономит стоимость и время. Конкретные имена моделей — зона конфига проекта (тиринг), не этого скилла.
@@ -103,6 +116,7 @@ digraph process {
 **Архитектура, дизайн и ревью:** самая способная доступная модель.
 
 **Сигналы сложности задачи:**
+
 - Трогает 1–2 файла с полным брифом → воркерская модель
 - Трогает много файлов с интеграционными рисками → стандартная
 - Требует дизайнерского суждения или широкого понимания кодовой базы → самая способная
@@ -118,6 +132,7 @@ digraph process {
 **NEEDS_CONTEXT:** воркеру не хватило информации. Дай недостающий контекст и перезапусти.
 
 **BLOCKED:** воркер не может завершить задачу. Оцени блокер:
+
 1. Проблема контекста — дай больше контекста, перезапусти
 2. Задача требует больше рассуждений — поднимись на уровень выше тирингом
 3. Задача слишком велика — разбей на меньшие части
@@ -172,6 +187,7 @@ digraph process {
 ## Red Flags
 
 **Никогда:**
+
 - Не начинай исполнение в main без явного согласия владельца (работа — только в worktree-ветке)
 - Не пропускай ревью (соответствие брифу ИЛИ качество — оба обязательны)
 - Не продолжай с незакрытыми замечаниями
@@ -186,32 +202,38 @@ digraph process {
 - Не переходи к следующей задаче, пока любое из ревью имеет открытые замечания
 
 **Если воркер задаёт вопросы:**
+
 - Отвечай ясно и полностью
 - Дай дополнительный контекст при необходимости
 - Не подгоняй его к реализации
 
 **Если ревьюер нашёл проблемы:**
+
 - Правит тот же воркер-исполнитель
 - Ревьюер смотрит снова
 - Повторять до аппрува
 - Не пропускай повторное ревью
 
 **Если воркер завалил задачу:**
+
 - Спавнь чинящего воркера с точными инструкциями
 - Не чини сам (загрязнение контекста)
 
 ## Интеграция
 
 **Обязательные скиллы воркфлоу:**
+
 - **using-git-worktrees** — REQUIRED: изолированный worktree `.worktrees/<имя-задачи>` ДО старта исполнения
 - **wolf-plan** — создаёт план, который этот скилл исполняет
 - **requesting-code-review** — рамка ревью для воркеров-ревьюеров
 - **finishing-a-development-branch** — завершение разработки после всех задач
 
 **Воркеры используют:**
+
 - **test-driven-development** — воркеры следуют TDD на каждой задаче
 
 **Альтернатива:**
+
 - **wolf-execute** — линейное исполнение без субагентов, когда диспетчеризация недоступна
 
 ---
@@ -220,20 +242,20 @@ digraph process {
 
 > Источник: `~/.config/opencode/superpowers/skills/subagent-driven-development/SKILL.md`, upstream 6efe32c (2026-04-23)
 
-| Пункт источника | Судьба | Почему |
-|---|---|---|
-| «Fresh subagent per task + two-stage review» | сохранено | Ядро принципа |
-| «Why subagents» (изоляция контекста) | сохранено | Ядро |
-| When-to-use флоучарт | сохранено; executing-plans → wolf-execute | Рёбра набора |
-| Process-флоучарт | сохранено; диспетч субагентов → executor-lead/worker-implementer/worker-reviewer; TodoWrite → `{{tool.todowrite}}` | Research §1: диспетч субагентов непереносим — заменён ролями Wolf |
-| Model Selection | заменено → тиринг проекта без имён моделей | Research §1: выбор моделей непереносим |
-| Implementer Status (DONE/DONE_WITH_CONCERNS/NEEDS_CONTEXT/BLOCKED) | сохранено полностью (4/4) | Контракт статусов воркера |
-| Prompt-templates (3 sibling-файла) | отброшено | Файлы каталога скилла не переносятся; заменено ролями worker-* |
-| Example Workflow | сжато сохранено; сущность цикла сохранена | Иллюстрация |
-| Advantages/Cost | сохранено сжато | Ядро |
-| Red Flags «Never» (12) | сохранено полностью (12/12); main/master → trunk-based формулировка | H7 |
-| «Если спрашивает / нашёл / завалил» (3+4+2) | сохранено полностью (9/9) | H7 |
-| Integration | заменено: worktrees → H5-предусловие `.worktrees/<имя-задачи>`; writing-plans → wolf-plan; code-reviewer → worker-reviewer; TDD — воркерам | Wolf-переплетение |
-| — | добавлено: REQUIRED-предусловие worktree (H5) | Спека §5.2 |
+| Пункт источника                                                    | Судьба                                                                                                                                     | Почему                                                            |
+| ------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------- |
+| «Fresh subagent per task + two-stage review»                       | сохранено                                                                                                                                  | Ядро принципа                                                     |
+| «Why subagents» (изоляция контекста)                               | сохранено                                                                                                                                  | Ядро                                                              |
+| When-to-use флоучарт                                               | сохранено; executing-plans → wolf-execute                                                                                                  | Рёбра набора                                                      |
+| Process-флоучарт                                                   | сохранено; диспетч субагентов → executor-lead/worker-implementer/worker-reviewer; TodoWrite → `{{tool.todowrite}}`                         | Research §1: диспетч субагентов непереносим — заменён ролями Wolf |
+| Model Selection                                                    | заменено → тиринг проекта без имён моделей                                                                                                 | Research §1: выбор моделей непереносим                            |
+| Implementer Status (DONE/DONE_WITH_CONCERNS/NEEDS_CONTEXT/BLOCKED) | сохранено полностью (4/4)                                                                                                                  | Контракт статусов воркера                                         |
+| Prompt-templates (3 sibling-файла)                                 | отброшено                                                                                                                                  | Файлы каталога скилла не переносятся; заменено ролями worker-\*   |
+| Example Workflow                                                   | сжато сохранено; сущность цикла сохранена                                                                                                  | Иллюстрация                                                       |
+| Advantages/Cost                                                    | сохранено сжато                                                                                                                            | Ядро                                                              |
+| Red Flags «Never» (12)                                             | сохранено полностью (12/12); main/master → trunk-based формулировка                                                                        | H7                                                                |
+| «Если спрашивает / нашёл / завалил» (3+4+2)                        | сохранено полностью (9/9)                                                                                                                  | H7                                                                |
+| Integration                                                        | заменено: worktrees → H5-предусловие `.worktrees/<имя-задачи>`; writing-plans → wolf-plan; code-reviewer → worker-reviewer; TDD — воркерам | Wolf-переплетение                                                 |
+| —                                                                  | добавлено: REQUIRED-предусловие worktree (H5)                                                                                              | Спека §5.2                                                        |
 
 Перенесённые списки: «Never» 12/12, вспомогательные 3+4+2 (9/9), статусы воркера 4/4.

package/templates/base/skills/wolf-skill-intake/SKILL.md

@@ -0,0 +1,66 @@
+---
+name: wolf-skill-intake
+description: 'Подключение внешнего скилла: поиск (npx skills find, skills.sh) → ревью-линза кандидата → гейт владельца (явное «да») → установка → регистрация tool → откат. Без аппрува владельца установка не идёт.'
+---
+
+# wolf-skill-intake: подключение внешнего скилла
+
+## Обзор
+
+Чужой скилл меняет поведение агентов — это мутация лица. Процесс: поиск →
+ревью → гейт владельца → установка → регистрация → наблюдаемость. Единственный
+новый скилл блока intake; линза кандидата — роль в этом протоколе, не отдельный скилл.
+
+## 1. Поиск
+
+- CLI: `npx skills find <запрос>`; leaderboard: skills.sh.
+- Критерии качества: ≥1K установок, репутация источника, звёзды репозитория.
+- Изоляция: внешние вызовы только здесь; при поломке внешнего CLI — деградация
+  к ручному поиску; контур (линза, гейт, регистрация) не страдает.
+
+## 2. Ревью-линза кандидата
+
+Чистый воркер-ревьюер читает SKILL.md кандидата по ОДНОМУ вопросу:
+«опасен ли/конфликтует ли этот скилл?» Проверки:
+
+- опасные инструкции: `rm -rf`, `curl | sh`, запросы секретов, авто-коммиты;
+- конфликты с рамкой/правилами проекта — по памяти Wolf (`wolf search`);
+- качество промпта: расплывчатые/конфликтные предписания.
+
+Вердикт (подключаем/отклонить + находки) — владельцу. Отклонение = конец, установки нет.
+
+## 3. Гейт владельца
+
+Без явного «да» владельца установка не идёт. Вопрос формулируется: скилл, источник,
+находки линзы, вердикт. Только после явного аппрува — шаг 4.
+
+## 4. Установка
+
+`npx skills add <имя>` (в проекте-пользователе). Откат: `npx skills remove <имя>`.
+
+## 5. Регистрация
+
+Тул-объект в памяти Wolf (гасит линт скиллов-призраков doctor):
+
+```bash
+wolf add --type tool --title "skill: <имя>" \
+  --set name=<имя> \
+  --set script_path=.opencode/skills/<имя>/SKILL.md \
+  --set language=markdown \
+  --set owner_skill=<имя> \
+  --set version=<версия-источника> \
+  --set source_url=<URL репозитория/страницы>
+```
+
+Ребро на проект/поток — по необходимости (`wolf relation add`).
+
+## 6. Наблюдаемость (уже существует — проверяется, не строится)
+
+- телеметрия: `.wolf/metrics/skill-invocations.jsonl` (панель `analytics --view delivery`);
+- жалобы на скилл: `wolf complain --about skill:<имя>` → kind behavioral;
+- линт призраков: секция «Артефакты» в `wolf doctor`.
+
+## 7. Откат
+
+`npx skills remove <имя>` + `wolf supersede <tool-id> <new-id>` или
+`wolf transition <tool-id> archived` (существующими командами, без новых).

package/templates/base/skills/wolf-testplan/SKILL.md

@@ -0,0 +1,37 @@
+---
+name: wolf-testplan
+description: 'Вход: requirements.md (approved) + design.md. Выход: test-plan.md — Given/When/Then сценарий на каждый REQ-NN + маппинг на e2e/юнит-файлы. AC переизобретаться не должны.'
+---
+
+# wolf-testplan: test-plan.md по requirements.md
+
+## Обзор
+
+Отдельная ось специализации: один скилл — один тип артефакта (как линзы).
+Планирование (wolf-plan) и тест-планирование (этот скилл) раздельны.
+
+## Вход
+
+- `requirements.md` (approved) — AC, единый источник сценариев.
+- `design.md` (review или approved) — контракты: сценарии проверяют интерфейс, не реализацию.
+
+## Выход: test-plan.md
+
+1. **Сценарий на каждый REQ-NN** в формате Given/When/Then. Нетривиальные AC —
+   дословно их G/W/T из requirements.md; простые — развёртка AC без смены смысла.
+2. **Маппинг** — каждый сценарий → целевой тестовый файл (юнит/e2e), которого ещё
+   нет: путь `tests/…` + имя теста. Сценарии test-plan.md — заготовки КРАСНОЙ фазы
+   TDD (дисциплинарный скилл test-driven-development).
+3. **Прогоны** — точечные команды `npx vitest run <путь>`; полный гейт `npm run check`.
+
+## Запреты
+
+- Сценарии для поведения вне REQ/NFR (расширение объёма — дефект).
+- Менять AC — правки только через CR в requirements.md.
+- Реализовывать тесты: скилл пишет артефакт, не код.
+
+## Процесс
+
+1. Таблица трассировки REQ-NN → сценарий → целевой файл (покрытие 100% REQ;
+   NFR — по измеримым AC).
+2. Заполнить test-plan.md; front-matter `status: review`.

package/templates/base/skills/writing-skills/SKILL.md

@@ -0,0 +1,40 @@
+---
+name: writing-skills
+description: 'Жизненный цикл скиллов Wolf: templates/base → рендер со штампами → sync; таблица трассировки обязательна; граница с skill intake.'
+---
+
+# writing-skills: создание и правка скиллов Wolf
+
+## Обзор
+
+Скилл Wolf = промпт-методология в `templates/base/skills/<имя>/SKILL.md`; в
+проекты-пользователи попадает рендером (штампы, `wolf init`/`wolf sync`).
+Правка живого скилла ведётся в шаблоне, не в отрендеренной копии.
+
+## Жизненный цикл
+
+1. Новый скилл: папка `templates/base/skills/<имя>/SKILL.md` с front-matter
+   `name` + `description` (описание — триггер загрузки: когда применять).
+2. Тело: обзор → вход/выход → процесс (шаги) → железные запреты.
+3. **Таблица трассировки адаптации обязательна** для каждого адаптированного
+   скилла: источник → судьба пункта (сохранено/заменено/выброшено/добавлено) → почему.
+4. Правка существующего: шаблон → `wolf sync` → guard-тесты соответствующего набора.
+5. Граница с intake: скиллы базового набора — здесь; внешние скиллы мира —
+   через wolf-skill-intake (гейт владельца), не через этот скилл.
+
+## Запреты
+
+- Править `.opencode/skills/<имя>/SKILL.md` напрямую (перезатрётся sync).
+- Создавать скилл без таблицы трассировки (для адаптаций) или без описания
+  триггера (для новых).
+- Дублировать существующий скилл набора — сначала `wolf search`.
+
+## Трассировка адаптации
+
+| Пункт источника (superpowers writing-skills) | Судьба                                       | Почему                     |
+| -------------------------------------------- | -------------------------------------------- | -------------------------- |
+| Описание как триггер загрузки                | сохранено                                    | ядро                       |
+| Проверка скилла перед деплоем                | заменено → guard-тесты набора + sync         | harness-привязка           |
+| Шаблоны и реестр скиллов                     | заменено → templates/base + базовый набор    | жизненный цикл Wolf        |
+| —                                            | добавлено: трассировка адаптации обязательна | уроки переноса superpowers |
+| —                                            | добавлено: граница с intake                  | спека конвейера §4-B7      |