mister-wolf 1.0.3 → 2.0.0

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

@@ -0,0 +1,177 @@
+---
+name: wolf-plan
+description: "Используй, когда есть спека или требования для многошаговой задачи — до касания кода. Пишет zero-context планы: каждая задача = самодостаточный бриф воркера, исполнитель не обязан знать кодовую базу."
+---
+
+# wolf-plan: план для zero-context исполнителя
+
+## Обзор
+
+Пиши исчерпывающие планы реализации в предположении, что исполнитель имеет **нулевой контекст** кодовой базы этой задачи и сомнительный вкус. Задокументируй всё, что ему нужно знать: какие файлы трогать в каждой задаче, код, тесты, какие доки проверить, как проверить работу. Отдай весь план как bite-sized задачи. DRY. YAGNI. TDD. Частые коммиты.
+
+Считай, что исполнитель — умелый разработчик, но почти ничего не знает о нашем тулсете и проблемном домене. Считай, что он плохо умеет в хороший дизайн тестов.
+
+**Вход воркеров — по брифам:** каждая задача плана становится брифом однозадачного воркера (worker-implementer). Воркер не читает кодовую базу и не видит твою сессию — план обязан содержать всё. Сомнительное качество плана = гарантированные вопросы и переделки на исполнении.
+
+**Анонс на старте:** «Использую скилл wolf-plan для создания плана реализации».
+
+**Контекст:** исполнение плана начинается только в worktree `.worktrees/<имя-задачи>` (правило проекта; создаётся ДО старта исполнения — см. wolf-sdd / wolf-execute). Сам план можно писать и до worktree.
+
+**Куда сохранять:** `docs/plans/YYYY-MM-DD-<имя-фичи>.md` (предпочтения проекта приоритетнее дефолта).
+
+## Проверка масштаба
+
+Если спека покрывает несколько независимых подсистем, её нужно было разбить на подпроекты ещё на wolf-brainstorm. Если это не сделано — предложи разбить план на отдельные, по одному на подсистему. Каждый план должен давать работающее, тестируемое ПО сам по себе.
+
+## Структура файлов
+
+До определения задач спроектируй, какие файлы будут созданы или изменены и за что каждый отвечает. Здесь фиксируются решения декомпозиции.
+
+- Проектируй блоки с ясными границами и определёнными интерфейсами. У каждого файла — одна ясная ответственность.
+- Над кодом, который держится в контексте целиком, ты рассуждаешь лучше, а правки точечнее. Предпочитай маленькие сфокусированные файлы разросшимся.
+- Файлы, меняющиеся вместе, живут вместе. Дели по ответственности, не по техническим слоям.
+- В существующей кодовой базе следуй устоявшимся паттернам. Если она использует большие файлы — не перестраивай в одиночку; но если файл, который ты правишь, разросся — включить разбиение в план разумно.
+
+Эта структура определяет декомпозицию задач. Каждая задача должна давать самодостаточные изменения, осмысленные независимо.
+
+## Гранулярность bite-sized
+
+**Каждый шаг — одно действие (2–5 минут):**
+- «Напиши падающий тест» — шаг
+- «Запусти и убедись, что он падает» — шаг
+- «Напиши минимальный код, чтобы тест прошёл» — шаг
+- «Запусти тесты и убедись, что проходят» — шаг
+- «Закоммить» — шаг
+
+## Заголовок плана
+
+**Каждый план ОБЯЗАН начинаться с этого заголовка:**
+
+```markdown
+# [Имя фичи] — план реализации
+
+> **Исполнителям:** REQUIRED-СКИЛЛ: используй wolf-sdd (рекомендуется) ИЛИ wolf-execute
+> для поэтапной реализации этого плана. Шаги оформлены чекбоксами (`- [ ]`) для трекинга.
+
+**Цель:** [Одно предложение — что строим]
+
+**Архитектура:** [2–3 предложения о подходе]
+
+**Стек:** [Ключевые технологии/библиотеки]
+
+---
+```
+
+## Структура задачи
+
+````markdown
+### Задача N: [Имя компонента]
+
+**Файлы:**
+- Create: `точный/путь/к/file.ts`
+- Modify: `точный/путь/к/existing.ts:123-145`
+- Test: `tests/точный/путь/к/test.ts`
+
+- [ ] **Шаг 1: Напиши падающий тест**
+
+```typescript
+it("конкретное поведение", () => {
+  expect(fn(input)).toBe(expected);
+});
+```
+
+- [ ] **Шаг 2: Запусти тест — убедись, что падает**
+
+Запуск: `npx vitest run tests/path/test.ts -t "конкретное поведение"`
+Ожидание: FAIL — «fn is not defined»
+
+- [ ] **Шаг 3: Напиши минимальную реализацию**
+
+```typescript
+export function fn(input: string): string {
+  return "expected";
+}
+```
+
+- [ ] **Шаг 4: Запусти тест — убедись, что проходит**
+
+Запуск: `npx vitest run tests/path/test.ts -t "конкретное поведение"`
+Ожидание: PASS
+
+- [ ] **Шаг 5: Закоммить**
+
+```bash
+git add tests/path/test.ts src/path/file.ts
+git commit -m "feat: add specific feature"
+```
+````
+
+## Никаких плейсхолдеров
+
+Каждый шаг обязан содержать фактический контент, нужный исполнителю. Это **провалы плана** — никогда так не пиши:
+
+- «TBD», «TODO», «сделаем позже», «заполнить детали»
+- «Добавить соответствующую обработку ошибок» / «добавить валидацию» / «обработать краевые случаи»
+- «Написать тесты для вышенаписанного» (без фактического кода теста)
+- «Аналогично задаче N» (повтори код — исполнитель может читать задачи не по порядку)
+- Шаги, описывающие ЧТО делать, без КАК (для шагов с кодом — блоки кода обязательны)
+- Ссылки на типы, функции или методы, не определённые ни в одной задаче
+
+## Помни
+
+- Всегда точные пути файлов
+- Полный код в каждом шаге — если шаг меняет код, покажи код
+- Точные команды с ожидаемым выводом
+- DRY, YAGNI, TDD, частые коммиты
+
+## Саморевью
+
+После написания полного плана посмотри на него свежим взглядом и сверь со спекой. Это чеклист для себя, не диспетчеризация субагентов.
+
+**1. Покрытие спеки:** пробегись по каждой секции/требованию спеки. Можешь указать задачу, которая её реализует? Перечисли пробелы.
+
+**2. Скан плейсхолдеров:** поищи в плане red flags — паттерны из секции «Никаких плейсхолдеров» выше. Исправь.
+
+**3. Консистентность типов:** совпадают ли типы, сигнатуры методов и имена свойств в поздних задачах с определёнными в ранних? Функция `clearLayers()` в задаче 3 и `clearFullLayers()` в задаче 7 — это баг.
+
+Нашёл проблемы — исправь на месте. Пересматривать заново не нужно. Требование спеки без задачи — добавь задачу.
+
+## Передача в исполнение
+
+После сохранения плана предложи выбор режима исполнения:
+
+**«План готов и сохранён в `docs/plans/<файл>.md`. Два режима исполнения:**
+
+**1. Через субагентов (wolf-sdd, рекомендуется)** — свежий воркер на каждую задачу через executor-lead, 2-стадийное ревью между задачами, быстрая итерация
+
+**2. Линейно (wolf-execute)** — исполнение задач в этой сессии без субагентов, батчами с чекпоинтами
+
+**Какой режим?»**
+
+**Выбран wolf-sdd:** свежий воркер на задачу + двухстадийное ревью (спека → качество) силами worker-reviewer.
+
+**Выбран wolf-execute:** батч-исполнение с чекпоинтами; верификация — `npm run check` после завершённых блоков работы.
+
+---
+
+## Трассировка адаптации
+
+> Источник: `~/.config/opencode/superpowers/skills/writing-plans/SKILL.md`, upstream 6efe32c (2026-04-23)
+
+| Пункт источника | Судьба | Почему |
+|---|---|---|
+| Zero-context принцип | сохранено + усилено «вход воркеров по брифам» | Спека §5.2 |
+| «created by brainstorming skill» (worktree) | заменено: worktree до старта исполнения, правило `.worktrees/<имя-задачи>` | H5; upstream-ребро brainstorm→worktree одностороннее, не воспроизводим |
+| Путь `docs/superpowers/plans/` | заменено → `docs/plans/…` | Harness-привязка (research §1) |
+| Заголовок «REQUIRED SUB-SKILL: sdd or executing-plans» | заменено → wolf-sdd ИЛИ wolf-execute | Рёбра набора Wolf |
+| Проверка масштаба | сохранено | Ядро |
+| Структура файлов | сохранено | Ядро |
+| Bite-sized гранулярность | сохранено | Ядро |
+| Структура задачи (пример) | сохранено; пример переведён (vitest вместо pytest) | Нейтральная иллюстрация под стек проекта |
+| «No Placeholders» (6 провалов) | сохранено полностью (6/6) | H7 |
+| «Remember» (4) | сохранено полностью (4/4) | H7 |
+| Саморевью (3 проверки) | сохранено полностью (3/3) | Чеклист-ядро |
+| Execution Handoff (2 опции) | сохранено; sdd-опция → executor-lead/worker-*, ревью → worker-reviewer; добавлен `npm run check` | Wolf-переплетение |
+| — | добавлено: задача = бриф воркера (worker-implementer) | Zero-context вход по брифам |
+
+Перенесённые списки: anti-patterns «No Placeholders» 6/6, «Remember» 4/4, саморевью 3/3.

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

@@ -0,0 +1,61 @@
+---
+name: wolf-review
+description: Мульти-линзовое ревью документов (doc-review): mr-wolf оркестрирует линзы-воркеров, цикл до сходимости. Use when the user asks to review a document, run doc-review, or critique a spec/plan/report.
+---
+
+# wolf-review — мульти-линзовое ревью документов
+
+> Источник: новый; рамка analyze-doc (PoC) + REVIEW-001 (архив v2.0 §2.5) +
+> практика мульти-линзового ревью; отклонение: security-линза опущена
+> (спека §6).
+
+## Трассировка переноса
+
+| Пункт источника | Судьба |
+| --------------- | ------ |
+| Рамочный паттерн analyze-doc: методика в памяти, файл — тонкая рамка | Сохранено |
+| Протокол подтягивания playbook перед прогоном | Сохранено; запрос `wolf search "wolf-review playbook"`, наибольшая версия |
+| Мульти-линзовость, изоляция линз в чистых сессиях (REVIEW-001) | Сохранено |
+| Перспектива линз полнота → консистентность → типоспецифичные (REVIEW-001) | Сохранено |
+| Контракты SUMMARY/VERDICT (REVIEW-001: вердикт «CHANGES») | Сохранено; «CHANGES» заменён на `CHANGES_REQUIRED` (стандартизация по спеке §6) |
+| Дедуп находок, подсчёт, счётчик раундов, критерий сходимости (REVIEW-001) | Сохранено |
+| Конфликты находок между линзами решает владелец (REVIEW-001) | Сохранено |
+| Security-линза (REVIEW-001) | Отброшено: осознанное отклонение — для документов не тянем (спека §6) |
+| Самомутация playbook по фидбеку (analyze-doc PoC, п. 3) | Заменено: фидбек о методике/линзах → жалобный контур (`wolf complain`, тег complaint); мутатор — Стюард |
+| Исполнитель-аналитик PoC (apprentice) | Заменено: линзы исполняют worker-reviewer; оркестратор цикла — mr-wolf |
+| Продуктовый код оркестрации | Отброшено: весь цикл ведёт mr-wolf по протоколу этого скилла (спека §10) |
+
+## Рамка (методика — НЕ в этом файле)
+
+Линзы — playbook-объекты памяти Wolf: они эволюционируют без рестарта
+(мутатор — Стюард, через жалобы). Этот файл — только рамка: протокол цикла
+и границы.
+
+### Протокол цикла (оркестратор — mr-wolf)
+
+1. **До прогона** получи актуальный playbook линз:
+   `wolf search "wolf-review playbook"` — запись с наибольшей версией.
+   Состав и параметры каждой линзы — из playbook, не отсюда.
+2. **Порядок линз**: полнота → консистентность → типоспецифичные.
+3. **Спавн**: каждую линзу исполняет ОТДЕЛЬНЫЙ worker-reviewer в чистой
+   сессии через {{tool.task}}. Изоляция бьёт по слепым зонам саморевью.
+   Узкий ревьюер: чужие замечания запрещены — воркер получает только свой
+   мандат (документ + своя линза), находки других линз ему не показываются.
+4. **Контракты** — обязательные строки отчёта каждой линзы:
+   - `SUMMARY: X critical / Y major / Z minor`
+   - `VERDICT: APPROVED | CHANGES_REQUIRED`
+5. **Дедуп и подсчёт**: mr-wolf сводит находки всех линз, убирает
+   дубликаты, считает critical/major/minor по итоговому набору.
+6. **Сходимость**: цикл останавливается при 0 critical / 0 blocking ИЛИ
+   по лимиту раундов (по умолчанию 3).
+7. **Цикл правок**: автор правит документ → перезапуск ТОЛЬКО упавшей
+   линзы; прошедшие линзы не перегоняются.
+8. **Конфликты**: противоречащие находки разных линз разрешает владелец
+   (слепой судьи в MVP нет) — mr-wolf докладывает конфликт, не выбирает сам.
+
+### Границы рамки
+
+- Критичные запреты: `rm -rf`, `sudo`, деструктивный git, секреты.
+- Продуктового кода оркестрации нет — цикл ведёт mr-wolf по этому протоколу.
+- Этот файл не содержит методику линз и не должен её содержать:
+   версии линз живут в памяти Wolf.

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

@@ -0,0 +1,239 @@
+---
+name: wolf-sdd
+description: "Используй для исполнения планов реализации с независимыми задачами через субагентов: свежий воркер на каждую задачу через executor-lead + двухстадийное ревью worker-reviewer (соответствие брифу, затем качество)."
+---
+
+# wolf-sdd: разработка через субагентов
+
+Исполняй план, диспетчеризуя свежего воркера на каждую задачу, с двухстадийным ревью после каждой: сначала соответствие брифу, затем качество кода.
+
+**Почему субагенты:** ты делегируешь задачи специализированным воркерам с изолированным контекстом. Точно формулируя их инструкции и контекст, ты удерживаешь их в фокусе и обеспечиваешь успех. Воркеры никогда не наследуют контекст и историю твоей сессии — ты конструируешь ровно то, что им нужно. Это же бережёт твой контекст для координации.
+
+**Ядро принципа:** свежий воркер на задачу + двухстадийное ревью (бриф → качество) = высокое качество, быстрая итерация.
+
+**Роли:** диспетчеризация — через executor-lead (или напрямую `{{tool.task}}` с типом воркера): исполнение — worker-implementer, ревью обеих стадий — worker-reviewer. Generic-субагентов не спавнь.
+
+**Методики воркеров:** воркер перед задачей подтягивает своё лицо из памяти — `wolf search "worker-implementer playbook"` / `wolf search "worker-reviewer playbook"` (брать наибольшую версию); в брифе укажи это воркеру, если harness не доставляет лица автоматически.
+
+## REQUIRED-предусловие: worktree
+
+**До старта исполнения worktree ОБЯЗАН существовать:** `.worktrees/<имя-задачи>` внутри проекта (правило проекта). Trunk-based: main — истина, работа идёт в ветке внутри worktree. Нет worktree — создай его ДО первой задачи (см. скилл using-git-worktrees). Никогда не начинай исполнение в main без явного согласия владельца.
+
+## Когда использовать
+
+```dot
+digraph when_to_use {
+    "Есть план реализации?" [shape=diamond];
+    "Задачи в основном независимы?" [shape=diamond];
+    "Остаемся в этой сессии?" [shape=diamond];
+    "wolf-sdd" [shape=box];
+    "wolf-execute" [shape=box];
+    "Ручное исполнение или сначала wolf-brainstorm" [shape=box];
+
+    "Есть план реализации?" -> "Задачи в основном независимы?" [label="да"];
+    "Есть план реализации?" -> "Ручное исполнение или сначала wolf-brainstorm" [label="нет"];
+    "Задачи в основном независимы?" -> "Остаемся в этой сессии?" [label="да"];
+    "Задачи в основном независимы?" -> "Ручное исполнение или сначала wolf-brainstorm" [label="нет - задачи сцеплены"];
+    "Остаемся в этой сессии?" -> "wolf-sdd" [label="да"];
+    "Остаемся в этой сессии?" -> "wolf-execute" [label="нет - параллельная сессия"];
+}
+```
+
+**vs wolf-execute (параллельная/линейная сессия):**
+- Та же сессия (без переключения контекста)
+- Свежий воркер на задачу (без загрязнения контекста)
+- Двухстадийное ревью после каждой задачи: сначала бриф, затем качество
+- Быстрее итерация (без человека между задачами)
+
+## Ход процесса
+
+```dot
+digraph process {
+    rankdir=TB;
+
+    subgraph cluster_per_task {
+        label="На каждую задачу";
+        "Спавнь worker-implementer с полным текстом задачи" [shape=box];
+        "Воркер задаёт вопросы?" [shape=diamond];
+        "Ответь, дай контекст" [shape=box];
+        "Воркер реализует, тестирует, коммитит, само-ревью" [shape=box];
+        "Спавнь worker-reviewer: стадия 1 - соответствие брифу" [shape=box];
+        "Код соответствует брифу?" [shape=diamond];
+        "Воркер правит пробелы" [shape=box];
+        "Спавнь worker-reviewer: стадия 2 - качество кода" [shape=box];
+        "Ревьюер аппрувает?" [shape=diamond];
+        "Воркер правит замечания качества" [shape=box];
+        "Отметь задачу завершённой ({{tool.todowrite}})" [shape=box];
+    }
+
+    "Прочитай план, извлеки все задачи с полным текстом, зафиксируй контекст, заведи {{tool.todowrite}}" [shape=box];
+    "Остались задачи?" [shape=diamond];
+    "Финальное ревью всего исполнения (worker-reviewer)" [shape=box];
+    "Скилл finishing-a-development-branch" [shape=box style=filled fillcolor=lightgreen];
+
+    "Прочитай план, извлеки все задачи с полным текстом, зафиксируй контекст, заведи {{tool.todowrite}}" -> "Спавнь worker-implementer с полным текстом задачи";
+    "Спавнь worker-implementer с полным текстом задачи" -> "Воркер задаёт вопросы?";
+    "Воркер задаёт вопросы?" -> "Ответь, дай контекст" [label="да"];
+    "Ответь, дай контекст" -> "Спавнь worker-implementer с полным текстом задачи";
+    "Воркер задаёт вопросы?" -> "Воркер реализует, тестирует, коммитит, само-ревью" [label="нет"];
+    "Воркер реализует, тестирует, коммитит, само-ревью" -> "Спавнь worker-reviewer: стадия 1 - соответствие брифу";
+    "Спавнь worker-reviewer: стадия 1 - соответствие брифу" -> "Код соответствует брифу?";
+    "Код соответствует брифу?" -> "Воркер правит пробелы" [label="нет"];
+    "Воркер правит пробелы" -> "Спавнь worker-reviewer: стадия 1 - соответствие брифу" [label="повторное ревью"];
+    "Код соответствует брифу?" -> "Спавнь worker-reviewer: стадия 2 - качество кода" [label="да"];
+    "Спавнь worker-reviewer: стадия 2 - качество кода" -> "Ревьюер аппрувает?";
+    "Ревьюер аппрувает?" -> "Воркер правит замечания качества" [label="нет"];
+    "Воркер правит замечания качества" -> "Спавнь worker-reviewer: стадия 2 - качество кода" [label="повторное ревью"];
+    "Ревьюер аппрувает?" -> "Отметь задачу завершённой ({{tool.todowrite}})" [label="да"];
+    "Отметь задачу завершённой ({{tool.todowrite}})" -> "Остались задачи?";
+    "Остались задачи?" -> "Спавнь worker-implementer с полным текстом задачи" [label="да"];
+    "Остались задачи?" -> "Финальное ревью всего исполнения (worker-reviewer)" [label="нет"];
+    "Финальное ревью всего исполнения (worker-reviewer)" -> "Скилл finishing-a-development-branch";
+}
+```
+
+## Тиринг задач
+
+Используй наименее мощную модель, которая справится с ролью — это экономит стоимость и время. Конкретные имена моделей — зона конфига проекта (тиринг), не этого скилла.
+
+**Механические задачи реализации** (изолированные функции, ясные брифы, 1–2 файла): быстрая воркерская модель. Большинство задач механичны при хорошо написанном плане.
+
+**Интеграционные задачи и задачи суждения** (координация многих файлов, сопоставление паттернов, дебаг): стандартная модель.
+
+**Архитектура, дизайн и ревью:** самая способная доступная модель.
+
+**Сигналы сложности задачи:**
+- Трогает 1–2 файла с полным брифом → воркерская модель
+- Трогает много файлов с интеграционными рисками → стандартная
+- Требует дизайнерского суждения или широкого понимания кодовой базы → самая способная
+
+## Обработка статусов воркера
+
+Воркеры (worker-implementer) отчитываются одним из четырёх статусов. Обрабатывай каждый соответственно:
+
+**DONE:** переходи к ревью соответствия брифу.
+
+**DONE_WITH_CONCERNS:** воркер закончил, но обозначил сомнения. Прочитай их до продолжения. Сомнения о корректности или scope — уладь до ревью. Наблюдения («файл разрастается») — зафиксируй (`wolf add --type lesson`, если переиспользуемо) и переходи к ревью.
+
+**NEEDS_CONTEXT:** воркеру не хватило информации. Дай недостающий контекст и перезапусти.
+
+**BLOCKED:** воркер не может завершить задачу. Оцени блокер:
+1. Проблема контекста — дай больше контекста, перезапусти
+2. Задача требует больше рассуждений — поднимись на уровень выше тирингом
+3. Задача слишком велика — разбей на меньшие части
+4. План сам ошибочен — эскалируй владельцу
+
+**Никогда** не игнорируй эскалацию и не заставляй ту же модель ретраить без изменений. Если воркер сказал, что застрял, — что-то должно измениться.
+
+## Пример цикла
+
+```
+Ты: использую wolf-sdd для исполнения плана.
+
+[Читаю план один раз: docs/plans/feature-plan.md]
+[Извлекаю все 5 задач с полным текстом и контекстом]
+[Заведи {{tool.todowrite}} со всеми задачами]
+
+Задача 1: скрипт установки хука.
+
+[Спавню worker-implementer через executor-lead: полный текст задачи + контекст]
+
+Воркер: «До старта — хук ставится на уровне пользователя или системы?»
+Ты: «На уровне пользователя.»
+
+Воркер: [позже]
+  - Реализовал команду install-hook
+  - Тесты 5/5 зелёные
+  - Само-ревью: заметил пропуск --force, добавил
+  - Закоммитил
+
+[Спавню worker-reviewer, стадия 1: соответствие брифу]
+Ревьюер: ✅ Соответствует брифу — все требования закрыты, лишнего нет.
+
+[Спавню worker-reviewer, стадия 2: качество кода]
+Ревьюер: Сильные стороны: покрытие тестами, чисто. Замечаний нет. Approved.
+
+[Отмечаю задачу 1 завершённой]
+... [далее задачи 2..N аналогично, финальное ревью всего исполнения]
+```
+
+## Преимущества и цена
+
+**vs ручное исполнение:** воркеры естественно следуют TDD; свежий контекст на задачу (без путаницы); параллельная безопасность (воркеры не мешают друг другу — но НЕ диспетчь несколько исполнителей concurrently, конфликты); воркер может задавать вопросы до и во время работы.
+
+**vs wolf-execute:** та же сессия (без handoff); непрерывный прогресс; ревью-чекпоинты автоматичны.
+
+**Эффективность:** нет накладных расходов на чтение файлов (диспетчер даёт полный текст); диспетчер курирует ровно нужный контекст; вопросы всплывают до работы, а не после.
+
+**Гейты качества:** само-ревью ловит проблемы до сдачи; двухстадийное ревью (бриф → качество); циклы ревью гарантируют, что правки реально работают; соответствие брифу страхует от over/under-building; стадия качества — что реализация хорошо сделана.
+
+**Цена:** больше вызовов воркеров (исполнитель + 2 ревью на задачу); диспетчер готовит больше (извлечение всех задач upfront); циклы ревью добавляют итераций; но ловят проблемы рано (дешевле, чем дебаг потом).
+
+## Red Flags
+
+**Никогда:**
+- Не начинай исполнение в main без явного согласия владельца (работа — только в worktree-ветке)
+- Не пропускай ревью (соответствие брифу ИЛИ качество — оба обязательны)
+- Не продолжай с незакрытыми замечаниями
+- Не диспетчь несколько воркеров-исполнителей параллельно (конфликты)
+- Не заставляй воркера читать файл плана (давай полный текст)
+- Не пропускай установочный контекст (воркер обязан понимать, куда задача встраивается)
+- Не игнорируй вопросы воркера (ответь до продолжения работы)
+- Не принимай «примерно соответствует» по брифу (ревьюер нашёл проблемы = не готово)
+- Не пропускай циклы ревью (ревьюер нашёл = воркер правит = ревью заново)
+- Не позволяй само-ревью воркера заменить настоящее ревью (нужно и то и другое)
+- **Не начинай ревью качества до ✅ по соответствию брифу** (порядок нарушен)
+- Не переходи к следующей задаче, пока любое из ревью имеет открытые замечания
+
+**Если воркер задаёт вопросы:**
+- Отвечай ясно и полностью
+- Дай дополнительный контекст при необходимости
+- Не подгоняй его к реализации
+
+**Если ревьюер нашёл проблемы:**
+- Правит тот же воркер-исполнитель
+- Ревьюер смотрит снова
+- Повторять до аппрува
+- Не пропускай повторное ревью
+
+**Если воркер завалил задачу:**
+- Спавнь чинящего воркера с точными инструкциями
+- Не чини сам (загрязнение контекста)
+
+## Интеграция
+
+**Обязательные скиллы воркфлоу:**
+- **using-git-worktrees** — REQUIRED: изолированный worktree `.worktrees/<имя-задачи>` ДО старта исполнения
+- **wolf-plan** — создаёт план, который этот скилл исполняет
+- **requesting-code-review** — рамка ревью для воркеров-ревьюеров
+- **finishing-a-development-branch** — завершение разработки после всех задач
+
+**Воркеры используют:**
+- **test-driven-development** — воркеры следуют TDD на каждой задаче
+
+**Альтернатива:**
+- **wolf-execute** — линейное исполнение без субагентов, когда диспетчеризация недоступна
+
+---
+
+## Трассировка адаптации
+
+> Источник: `~/.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 |
+
+Перенесённые списки: «Never» 12/12, вспомогательные 3+4+2 (9/9), статусы воркера 4/4.

package/templates/opencode/README.md

@@ -0,0 +1 @@
+Harness-specific templates (opencode plugins). Content ships in phase B.

package/templates/opencode/plugins/wolf-router.ts

@@ -0,0 +1,104 @@
+/**
+ * Mr.Wolf router plugin (шаблон базового набора, спека §5.4).
+ *
+ * Слой доставки №1 playbook-контекста (канон §7.1): детерминированная
+ * доставка вместо вероятностного wolf search агентом. Маркер
+ * `agent-id: <id>` В ТЕЛЕ рамки агента (frontmatter в system-промпт не
+ * попадает — известная грабля) → wolf search --type playbook → get +
+ * гвард owner_skill === agentId | `skill:${agentId}` (legacy) → максимальная
+ * version → инжект в system-промпт на каждое сообщение.
+ *
+ * Fallback — слой доставки №2: если плагин ничего не нашёл, рамка сама зовёт
+ * `wolf search` (см. рамки агентов базового набора). Реестр доставок = сами
+ * playbook-объекты через owner_skill, отдельного конфига нет.
+ *
+ * Ноль зависимостей (Node stdlib; ai-sdk НЕ используется). Fail-safe: всё в
+ * try/catch — плагин не имеет права уронить сессию (лог: .wolf/router.log —
+ * agent-id, hit/miss, injected). Через этот файл при рендере проходят
+ * подстановка {{tool.*}} и штамп `// wolf:rendered` (ставит рендерер).
+ */
+
+import path from 'path';
+import fs from 'fs';
+import { execFile } from 'child_process';
+import { promisify } from 'util';
+import { fileURLToPath } from 'url';
+
+const __dirname = path.dirname(fileURLToPath(import.meta.url));
+const PROJECT_ROOT = path.join(__dirname, '..', '..');
+const LOCAL_CLI = path.join(PROJECT_ROOT, 'dist', 'bootstrap', 'cli.js');
+const LOG = path.join(PROJECT_ROOT, '.wolf', 'router.log');
+const INJECT_HEADER =
+  '# Актуальный playbook (источник: память Wolf, доставлен плагином; обязательный формат ответа)';
+// [ \t] вместо \s: \s съедает переводы строк и вытаскивает id с чужой строки.
+const AGENT_ID_RE = /^agent-id:[ \t]*([\w-]+)[ \t]*$/m;
+const CACHE_TTL_MS = 2500;
+
+const run = promisify(execFile);
+// execFile: args array, no shell. Целевой проект — глобальный `wolf`;
+// догфуд в репо Wolf — локальный dist. Ошибка обоих → исключение наверх (fail-safe).
+const runWolf = (args: string[]): Promise<{ stdout: string }> => {
+  const opts = { cwd: PROJECT_ROOT, timeout: 5000 };
+  return run('wolf', args, opts).catch(() => run('node', [LOCAL_CLI, ...args], opts));
+};
+
+function logRoute(line: string): void {
+  try {
+    fs.mkdirSync(path.dirname(LOG), { recursive: true });
+    fs.appendFileSync(LOG, `${new Date().toISOString()} ${line}\n`);
+  } catch {
+    /* fail-safe */
+  }
+}
+
+// ponytail: per-agent кэш 2.5с — свежесть между сообщениями, без CLI-спавна на каждый чих.
+const cache = new Map<string, { value: string | null; at: number }>();
+
+async function resolvePlaybook(agentId: string): Promise<string | null> {
+  const hit = cache.get(agentId);
+  if (hit && Date.now() - hit.at < CACHE_TTL_MS) return hit.value;
+  let body: string | null = null;
+  try {
+    const { stdout } = await runWolf(['search', agentId, '--type', 'playbook', '--hide-superseded']);
+    const ids = [...stdout.matchAll(/^([\w-]+) \[playbook\]/gm)].map((m) => m[1]);
+    let best: { body?: string } | null = null;
+    let bestVersion = -1;
+    for (const id of ids) {
+      const { stdout: json } = await runWolf(['get', id]);
+      const obj = JSON.parse(json);
+      const owner = obj.owner_skill ?? obj.extra?.owner_skill;
+      if (owner !== agentId && owner !== `skill:${agentId}`) continue; // гвард владельца
+      const version = Number(String(obj.version ?? '').match(/\d+/)?.[0] ?? 0);
+      if (version > bestVersion) {
+        bestVersion = version;
+        best = obj;
+      }
+    }
+    body = best?.body ?? null;
+  } catch {
+    /* fail-safe: без playbook — рамка работает через wolf search */
+  }
+  cache.set(agentId, { value: body, at: Date.now() });
+  return body;
+}
+
+export const WolfPlaybookPlugin = async () => ({
+  'experimental.chat.system.transform': async (_input, output) => {
+    try {
+      const joined = output.system.join('\n');
+      const m = joined.match(AGENT_ID_RE);
+      if (!m) return; // рамка без маркера — не наша забота
+      if (joined.includes(INJECT_HEADER)) return; // идемпотентность: не вставляем дважды
+      const agentId = m[1];
+      const body = await resolvePlaybook(agentId);
+      if (!body) {
+        logRoute(`agent-id=${agentId} playbook=miss injected=no`);
+        return; // fail-safe: fallback на wolf search самой рамкой
+      }
+      output.system.push(`\n\n${INJECT_HEADER}\n\n${body}`);
+      logRoute(`agent-id=${agentId} playbook=hit injected=yes`);
+    } catch {
+      /* fail-safe: не роняем сессию */
+    }
+  },
+});