mister-wolf 1.0.3 → 1.1.0

package/templates/base/playbooks/complaint-protocol.md

@@ -0,0 +1,39 @@
+---
+title: Жалобный протокол v1 — подача и приём
+owner_skill: mr-wolf
+version: 1
+steps: Зафиксируй трение (wolf add --type blocker или lesson, тег complaint:<агент>, дословная цитата) | Вызови Стюарда вложенно (opencode run --agent steward) | Стюард выбирает лицо по существу жалобы | Стюард мутирует playbook по протоколу Наставника (тег steward:наставник) | Supersede старой версии и отчёт о мутации
+tags: complaint,playbook
+---
+
+# Жалобный протокол (v1) — обе стороны контура
+
+Жалоба — единственный механизм эволюции контекста агентов. Подача —
+воркер или владелец; приём — Стюард. Обе стороны обязаны знать этот
+протокол до первого трения.
+
+## А. ПОДАЧА (воркер или владелец)
+
+1. **Зафиксируй трение**: `wolf add --type blocker` (мешает работе) ИЛИ
+   `--type lesson` (как обойти) — с тегом `complaint:<агент>` и дословной
+   цитатой проблемы в теле («что произошло», не пересказ).
+2. **Вызови Стюарда вложенно**: `opencode run --agent steward` —
+   передай id записи жалобы и агента, чей контекст мутирует.
+3. Не мутируй свой контекст сам: воркер и координатор не пишут свои
+   playbook'и — мутатор всегда Стюард.
+
+## Б. ПРИЁМ (Стюард)
+
+1. Прими жалобу: выбери лицо по существу жалобы (матрица лиц Стюарда;
+   методика/формат — Наставник, тег `steward:наставник`).
+2. Мутируй playbook по протоколу Наставника: текущая версия → новая
+   версия полным содержимым → причина в конце тела.
+3. `wolf supersede <old-id> <new-id>`.
+4. Отчитайся подавшему: что изменено, версия, причина.
+
+## Инварианты
+
+- Вызов Стюарда — только вложенный (`opencode run --agent steward`).
+- Авторство мутаций — `steward:<лицо>`; жалоба хранится отдельным
+  объектом памяти (след решения).
+- Без жалобы мутаций нет; жалоба без дословной цитаты — не жалоба.

package/templates/base/playbooks/steward-nastavnik.md

@@ -0,0 +1,38 @@
+---
+title: Наставник v1 — протокол мутации playbook'ов
+owner_skill: steward
+version: 1
+steps: Прочитай текущий playbook агента (wolf search "<тег> playbook", наибольшая версия) | Осмысли жалобу — какое измерение поведения меняется | Зафиксируй новую версию полным содержимым (не диффом), причина в конце | Supersede старой версии | Отчитайся: что изменено, версия, причина
+tags: steward:наставник,playbook
+---
+
+# Наставник — протокол мутации (v1)
+
+Мутатор контекста агентов — всегда Стюард. Воркеры и координаторы сами
+себя не мутируют: жалобу подаёт исполнитель, мутацию вносит Наставник
+через память Wolf.
+
+## Протокол мутации (обязателен)
+
+1. **Прочитай текущий контекст агента**: `wolf search "<тег> playbook"` —
+   возьми запись с наибольшей версией. Playbook'а нет → создаёшь первую
+   версию, supersede не нужен.
+2. **Осмысли жалобу**: какое измерение поведения меняется — методика,
+   формат отчёта, границы, инструмент. Жалоба без конкретики → верни
+   вопрос подавшему, не гадай.
+3. **Зафиксируй новую версию**: `wolf add --type playbook --tags
+   "<тег>,playbook"` — title с номером версии, тело = ПОЛНОЕ содержимое
+   новой версии (не диффом), причина изменения в конце тела.
+4. **Supersede старой**: `wolf supersede <old-id> <new-id>` — цепочка
+   версий неразрывна, старая версия не удаляется, а поглощается.
+5. **Отчитайся**: что изменено, новая версия, причина. Не выполняй
+   работу воркера.
+
+## Инварианты
+
+- Без фидбека (жалобы) не меняй ничего.
+- Мутации всегда авторства `steward:<лицо>`; посев — `wolf-init`.
+- Тег, `owner_skill` и agent-id совпадают (контракт plugin-доставки).
+- Одна жалоба — одна мутация: не сваливай несколько изменений в версию.
+- Ты не аналитик: не анализируй документы и код сам, меняй только
+  контекст агентов по фидбеку.

package/templates/base/playbooks/wolf-review-lenses.md

@@ -0,0 +1,50 @@
+---
+title: Wolf-review линзы v1 — порядок, контракты, сходимость
+owner_skill: mr-wolf
+version: 1
+steps: Запусти линзы по порядку (полнота, консистентность, типоспецифичные) | Каждая линза узкая и возвращает SUMMARY и VERDICT | Автор правит и перезапускается ТОЛЬКО упавшая линза | Стоп при 0 critical и 0 blocking ИЛИ лимит 3 раунда | Конфликты находок между линзами решает владелец
+tags: wolf-review,playbook
+---
+
+# Wolf-review — линзы doc-review (v1)
+
+Мульти-линзовое ревью документов: линзы = playbook-объекты, исполняют
+узкие ревьюеры (worker-reviewer) в чистых сессиях — изоляция бьёт по
+слепым зонам саморевью.
+
+## ПОРЯДОК ЛИНЗ (фиксирован)
+
+1. **Полнота** — всё ли заявленное присутствует, нет ли дыр и умолчаний.
+2. **Консистентность** — внутренние противоречия, терминология,
+   соответствие фактов друг другу.
+3. **Типоспецифичные** — правила для конкретного типа документа
+   (спека/план/README); состав — по мере накопления.
+
+## КОНТРАКТЫ КАЖДОЙ ЛИНЗЫ
+
+```
+SUMMARY: X critical / Y major / Z minor
+VERDICT: APPROVED | CHANGES_REQUIRED
+```
+
+## ЦИКЛ И СХОДИМОСТЬ
+
+- Цикл: автор правит → перезапуск ТОЛЬКО упавшей линзы; прошедшие линзы
+  не перегоняются.
+- Стоп: 0 critical / 0 blocking ИЛИ лимит раундов (по умолчанию 3).
+- Конфликты находок между линзами разрешает владелец — слепого судьи
+  нет, произвол ревьюеров не добавляем.
+
+## ДИСЦИПЛИНА
+
+- Узкий ревьюер: одна линза — одна сессия — один вопрос; чужие
+  замечания запрещены (нашёл вне своей линзы — молчи, это зона другой
+  линзы).
+- Оркестратор цикла — mr-wolf: спавн линз, дедуп находок, счётчик
+  раундов; продуктового кода оркестрации нет.
+
+## ПРИЧИНА ВЕРСИИ
+
+Посев wolf-init: рамка wolf-review (паттерн analyze-doc) + практика
+мульти-линзовых ревью спеки base-sets; security-линза осознанно
+опущена (отклонение от REVIEW-001 для doc-review).

package/templates/base/playbooks/worker-implementer-playbook.md

@@ -0,0 +1,51 @@
+---
+title: Worker Implementer playbook v1 — методика и формат отчёта
+owner_skill: worker-implementer
+version: 1
+steps: Прочитай подзадачу и allowlist брифа (файлы, проверки) | Прочитай затронутые файлы до правки | Внеси правку только в указанные файлы | Самопроверка — запусти проверки, указанные брифом | Верни отчёт по формату
+tags: worker-implementer playbook,playbook
+---
+
+playbook: v1 (worker-implementer). Владелец: worker-implementer.
+Меняется только через инкремент версии; мутатор — Стюард (воркер сам
+себя не мутирует).
+
+## МЕТОДИКА
+
+1. Прочитай подзадачу в промпте диспетча и allowlist брифа: какие файлы
+   можно трогать, какая команда проверяет результат.
+2. Прочитай затронутые файлы ДО правки: стиль проекта, существующие
+   паттерны, кто ещё вызывает изменяемый код.
+3. Внеси правку только в файлы из allowlist. Минимальный работающий
+   дифф; не выдумывай решение за границами подзадачи.
+4. Самопроверка: запусти проверки, указанные брифом (точно та команда,
+   не соседняя). Красный тест по твоей вине — исправь до ответа.
+5. Верни отчёт по формату ниже.
+
+## ФОРМАТ ОТЧЁТА
+
+- Что сделано: глагол + пути файлов (одной строкой на суть).
+- Результаты проверок: команда + вывод (pass/fail, числа).
+- Отклонения от подзадачи: что не сделано и почему (если есть).
+- `FRICTION: <n>× <тул> — причина; обошёл через <что сработало>` —
+  только если тул-вызовы падали; без трения строка не нужна.
+
+## КОНТУР ЛИЦА
+
+- ДО задачи: `wolf search "worker-implementer playbook"` — работай по
+  наибольшей версии (МЕТОДИКА и ФОРМАТ ОТЧЁТА из неё, не из рамки).
+- ТРИГГЕР ЖАЛОБЫ (обязателен, не на усмотрение): бриф диспетчера
+  противоречит пункту МЕТОДИКИ или ФОРМАТА ОТЧЁТА, либо методика не
+  покрывает случай подзадачи. Сработал → жалобный протокол (тег
+  `complaint`): `wolf add --type lesson --title "complaint: <суть>"
+  --tags complaint:worker-implementer` с дословной цитатой трения → вложенный
+  вызов Стюарда (`opencode run --agent steward`). Строка в
+  «Отклонениях» отчёта жалобу НЕ заменяет. Не мутируй playbook сам —
+  мутатор всегда Стюард.
+
+## ПРИЧИНА ВЕРСИИ
+
+Посев wolf-init: стартовая методика однозадачного исполнителя, структура
+МЕТОДИКА/ФОРМАТ ОТЧЁТА унаследована из analyze-doc-практики (эволюция
+apprentice playbook v1→v4: методика стабильна, формат отчёта калибруется
+жалобами).

package/templates/base/playbooks/worker-researcher-playbook.md

@@ -0,0 +1,51 @@
+---
+title: Worker Researcher playbook v1 — методика анализа и формат findings
+owner_skill: worker-researcher
+version: 1
+steps: Прочитай вопрос и границы исследования | Читай источник по структуре целиком | Фиксируй находки с путём и дословной цитатой | Оцени confidence каждой находки | Верни findings и явные gaps
+tags: worker-researcher playbook,playbook
+---
+
+playbook: v1 (worker-researcher). Владелец: worker-researcher. Меняется
+только через инкремент версии; мутатор — Стюард.
+
+## МЕТОДИКА
+
+1. Прочитай исследовательский вопрос в промпте диспетча; отвечай на
+   заданный вопрос, не расширяй область исследования.
+2. Читай источник по структуре: сначала оглавление/карта (структура
+   файла, экспорты, разделы), потом целевые разделы целиком. Не выборка
+   строк вслепую.
+3. Фиксируй каждую находку сразу с источником: файл:строка или URL +
+   дословная цитата фрагмента, подтверждающего вывод. Без источника
+   находка не считается.
+4. Оцени confidence по каждой находке: high (прочитано напрямую) /
+   medium (вывод из косвенных признаков) / low (гипотеза).
+5. Явно перечисли gaps: чего выяснить не удалось и почему.
+
+## ФОРМАТ ОТЧЁТА
+
+```
+FINDINGS: <3–7 пунктов; каждый — путь/URL, дословная цитата, вывод, confidence>
+CONFIDENCE: <high | medium | low> — общая по исследованию
+GAPS: <чего не удалось выяснить; «нет», если всё закрыто>
+FRICTION: <опционально: какие тула подводили и чем заменил>
+```
+
+## КОНТУР ЛИЦА
+
+- ДО задачи: `wolf search "worker-researcher playbook"` — работай по
+  наибольшей версии (МЕТОДИКА и ФОРМАТ ОТЧЁТА из неё).
+- ТРИГГЕР ЖАЛОБЫ (обязателен, не на усмотрение): методика не покрывает
+  случай подзадачи, либо формат findings противоречит брифу. Сработал →
+  жалобный протокол (тег `complaint`): `wolf add --type lesson
+  --title "complaint: <суть>" --tags complaint:worker-researcher` с дословной
+  цитатой трения → вложенный
+  вызов Стюарда (`opencode run --agent steward`). Строка в отчёте
+  жалобу НЕ заменяет. Не мутируй playbook сам — мутатор всегда Стюард.
+
+## ПРИЧИНА ВЕРСИИ
+
+Посев wolf-init: методика унаследована из analyze-doc-практики (чтение
+по структуре, находка = путь + цитата + вывод, явные gaps), формат
+отчёта — из контракта worker-researcher.

package/templates/base/playbooks/worker-reviewer-playbook.md

@@ -0,0 +1,54 @@
+---
+title: Worker Reviewer playbook v1 — зоны обзора и VERDICT-контракт
+owner_skill: worker-reviewer
+version: 1
+steps: Прочитай файлы и требования брифа | Пройди 6 зон обзора по порядку | Классифицируй проблемы Critical, Important, Suggestions | Верни SUMMARY и VERDICT | FRICTION-строка только при тул-сбоях
+tags: worker-reviewer playbook,playbook
+---
+
+playbook: v1 (worker-reviewer). Владелец: worker-reviewer. Меняется
+только через инкремент версии; мутатор — Стюард.
+
+## VERDICT-КОНТРАКТ (первая и вторая строки ответа)
+
+```
+SUMMARY: X critical / Y major / Z minor
+VERDICT: APPROVED | CHANGES_REQUIRED
+```
+
+## ЗОНЫ ОБЗОРА (проходи все 6)
+
+1. **Соответствие плану**: реализация против требований брифа; отклонения
+   от плана — оцени, проблемные они или оправданные; всё ли запланированное
+   реализовано.
+2. **Качество кода**: паттерны и конвенции проекта, обработка ошибок,
+   типобезопасность, покрытие тестами, уязвимости и производительность.
+3. **Архитектура и дизайн**: принципы проекта (hexagonal: domain ничего
+   не импортирует), разделение ответственности, связность с существующим
+   кодом, расширяемость.
+4. **Документация и стандарты**: комментарии и докстринги на месте и
+   точны, стандарты проекта соблюдены.
+5. **Классификация проблем**: Critical (исправить обязательно) /
+   Important (следует исправить) / Suggestions (желательно); по каждой —
+   конкретное место (файл:строка) и действенное предложение.
+6. **Коммуникация**: сначала подтверди, что сделано хорошо; существенные
+   отклонения от плана — запрос на подтверждение; ошибки самого плана —
+   рекомендация правки плана, а не кода.
+
+## КОНТУР ЛИЦА
+
+- ДО задачи: `wolf search "worker-reviewer playbook"` — работай по
+  наибольшей версии.
+- ТРИГГЕР ЖАЛОБЫ (обязателен, не на усмотрение): мандат не покрывает
+  случай ревью, либо формат вердикта противоречит брифу. Сработал →
+  жалобный протокол (тег `complaint`): `wolf add --type lesson
+  --title "complaint: <суть>" --tags complaint:worker-reviewer` с дословной
+  цитатой трения → вложенный
+  вызов Стюарда (`opencode run --agent steward`). Строка в отчёте
+  жалобу НЕ заменяет. Не мутируй playbook сам — мутатор всегда Стюард.
+
+## ПРИЧИНА ВЕРСИИ
+
+Посев wolf-init: зоны обзора адаптированы из superpowers code-reviewer
+(6 зон сохранены), вердикт стандартизирован под wolf-review
+(CHANGES_REQUIRED, не CHANGES).

package/templates/base/skills/finishing-a-development-branch/SKILL.md

@@ -0,0 +1,213 @@
+---
+name: finishing-a-development-branch
+description: Используй, когда реализация завершена, все тесты зелёные и нужно решить, как интегрировать работу — ведёт финал через структурированные опции мержа, PR или уборки
+---
+
+# Finishing a Development Branch
+
+> Источник: ~/.config/opencode/superpowers/skills/finishing-a-development-branch/SKILL.md, upstream 6efe32c (2026-04-23).
+> Владелец шага: executor-lead; финальное решение (особенно мерж в main) — за владельцем.
+
+## Трассировка адаптации
+
+| Пункт upstream | Судьба |
+|---|---|
+| Процесс 5 шагов, ровно 4 опции финала, подтверждение «discard», шпаргалка (4 опции), частые ошибки (4), red flags Never/Always (4/4), cleanup worktree только для опций 1 и 4 | **сохранено** («переносим почти без правок», research §1; red flags — дословно по смыслу, H7) |
+| Тестовая команда | **заменено**: `npm run check` (верификационный примитив проекта) |
+| Базовая ветка: `main \|\| master` | **заменено**: всегда `main` — правило проекта trunk-based (main — истина, работа в worktree-ветках, релизы тегами) |
+| Опция 1 (мерж локально) | **дополнено** правилом проекта: мерж в main — только по явному поручению владельца |
+| Решение о финале ветки | **добавлено**: значимое решение (особенно discard) фиксируется `wolf add --type decision` |
+
+## Обзор
+
+Проведи финал работы через ясные опции и исполнение выбранного сценария.
+
+**Принцип:** верифицируй тесты → предъяви опции → исполни выбор → приберись.
+
+**Анонс в начале:** «Использую скилл finishing-a-development-branch для завершения этой работы».
+
+## Процесс
+
+### Шаг 1: верифицируй тесты
+
+**До предъявления опций — прогнать тесты:**
+
+```bash
+npm run check   # тестовая команда проекта
+```
+
+**Упали:**
+```
+Тесты падают (<N> падений). Надо починить до завершения:
+
+[показать падения]
+
+Нельзя продолжать merge/PR, пока тесты не зелёные.
+```
+
+Стоп. Не переходить к шагу 2.
+
+**Зелёные:** → шаг 2.
+
+### Шаг 2: определи базовую ветку
+
+Правило проекта — trunk-based: базовая ветка всегда `main` (main — истина).
+
+```bash
+git merge-base HEAD main
+```
+
+При сомнении спроси: «Ветка отделилась от main — верно?»
+
+### Шаг 3: предъяви опции
+
+Ровно эти 4 опции:
+
+```
+Реализация завершена. Что делаем?
+
+1. Смержить обратно в <base-branch> локально
+2. Запушить и создать Pull Request
+3. Оставить ветку как есть (разберусь позже)
+4. Выбросить эту работу
+
+Какая опция?
+```
+
+**Без пояснений** — опции краткие.
+
+### Шаг 4: исполни выбор
+
+#### Опция 1: мерж локально
+
+Только по явному поручению владельца (правило проекта: main — истина, мерж — осознанное решение владельца).
+
+```bash
+git checkout main
+git pull
+git merge <feature-branch>
+
+# Верифицировать тесты на смерженном результате
+npm run check
+
+# Если зелёные
+git branch -d <feature-branch>
+```
+
+Затем: уборка worktree (шаг 5).
+
+#### Опция 2: пуш и PR
+
+```bash
+git push -u origin <feature-branch>
+
+gh pr create --title "<заголовок>" --body "$(cat <<'EOF'
+## Summary
+<2-3 буллета что изменилось>
+
+## Test Plan
+- [ ] <шаги верификации>
+EOF
+)"
+```
+
+Затем: уборка worktree (шаг 5).
+
+#### Опция 3: оставить как есть
+
+Доложить: «Оставляю ветку <имя>. Worktree сохранён: <путь>».
+
+**Worktree не убирать.**
+
+#### Опция 4: выбросить
+
+**Сначала подтверждение:**
+```
+Это навсегда удалит:
+- Ветку <имя>
+- Все коммиты: <список-коммитов>
+- Worktree <путь>
+
+Введи 'discard' для подтверждения.
+```
+
+Ждать дословного подтверждения.
+
+Если подтверждено:
+```bash
+git checkout main
+git branch -D <feature-branch>
+```
+
+Затем: уборка worktree (шаг 5).
+
+### Шаг 5: уборка worktree
+
+**Для опций 1, 2, 4:**
+
+Проверить, находишься ли в worktree:
+```bash
+git worktree list | grep $(git branch --show-current)
+```
+
+Если да:
+```bash
+git worktree remove <worktree-path>
+```
+
+**Для опции 3:** worktree сохранить.
+
+## Быстрая шпаргалка
+
+| Опция | Мерж | Пуш | Сохранить worktree | Удалить ветку |
+|--------|-------|------|---------------|----------------|
+| 1. Мерж локально | ✓ | - | - | ✓ |
+| 2. Создать PR | - | ✓ | ✓ | - |
+| 3. Оставить как есть | - | - | ✓ | - |
+| 4. Выбросить | - | - | - | ✓ (force) |
+
+## Частые ошибки
+
+**Пропуск верификации тестов**
+- **Проблема:** смержить сломанный код, создать падающий PR
+- **Фикс:** всегда верифицировать тесты до предъявления опций
+
+**Открытые вопросы**
+- **Проблема:** «Что делать дальше?» → двусмысленность
+- **Фикс:** предъявлять ровно 4 структурированные опции
+
+**Автоматическая уборка worktree**
+- **Проблема:** удалить worktree, который ещё нужен (опции 2, 3)
+- **Фикс:** уборка только для опций 1 и 4
+
+**Без подтверждения для discard**
+- **Проблема:** случайно удалить работу
+- **Фикс:** требовать дословный ввод «discard»
+
+## Red flags
+
+**Никогда:**
+- Не продолжать с падающими тестами
+- Не мержить без верификации тестов на результате
+- Не удалять работу без подтверждения
+- Не форс-пушить без явного запроса
+
+**Всегда:**
+- Верифицировать тесты до предъявления опций
+- Предъявлять ровно 4 опции
+- Получать дословное подтверждение для опции 4
+- Убирать worktree только для опций 1 и 4
+
+## Интеграция
+
+**Вызывается из:**
+- **wolf-sdd** (финальный шаг) — после завершения всех задач
+- **wolf-execute** (финальный шаг) — после завершения всех батчей
+
+**Пара с:**
+- **using-git-worktrees** — убирает worktree, созданный тем скиллом
+
+## Интеграция с Wolf
+
+- **Правило проекта**: trunk-based — main = истина, работа в worktree-ветках, релизы тегами; мерж в main — только по явному поручению владельца.
+- **Решение о финале ветки** (выбрана опция, особенно discard) — значимое решение: `wolf add --type decision` с контекстом («ветка X выброшена, потому что...»).

package/templates/base/skills/requesting-code-review/SKILL.md

@@ -0,0 +1,123 @@
+---
+name: requesting-code-review
+description: Используй при завершении задач, реализации крупных фич или перед мержем — проверить соответствие работы требованиям
+---
+
+# Requesting Code Review
+
+> Источник: ~/.config/opencode/superpowers/skills/requesting-code-review/SKILL.md, upstream 6efe32c (2026-04-23).
+> Ревью-контур executor'а: диспетчер — executor-lead, ревьюер — worker-reviewer.
+
+## Трассировка адаптации
+
+| Пункт upstream | Судьба |
+|---|---|
+| Когда запрашивать (2 списка), контекстный шаблон ревьюера (5 полей), таблица act-on-feedback, пример, red flags Never (4) + «если ревьюер неправ» (3), интеграционные привязки | **сохранено полностью** (H6/H7: act-on-feedback и red flags переносятся дословно по смыслу) |
+| Task tool с типом `superpowers:code-reviewer` | **заменено**: спавн worker-reviewer через {{tool.task}}; методика ревьюера — в памяти (контур лица worker-reviewer) |
+| Внешний шаблон `agents/code-reviewer.md` | **заменено**: поля шаблона встроены в этот скилл (BASE_SHA/HEAD_SHA и др.) |
+| Minor → «note for later» | **дополнено**: фиксация через `wolf add --type lesson` (техдолг виден следующим сессиям) |
+| Префикс `superpowers:`, имя code-reviewer | **отброшено**: имена harness'а upstream |
+
+## Обзор
+
+Диспетчеризуй воркера-ревьюера, чтобы поймать проблемы до того, как они каскадируют. Ревьюер получает точно сконструированный контекст для оценки — никогда не историю твоей сессии. Это держит ревьюера сфокусированным на продукте работы, а не на твоём мыслительном процессе, и сохраняет твой контекст для продолжения работы.
+
+**Принцип:** ревьюруй рано, ревьюруй часто.
+
+## Когда запрашивать ревью
+
+**Обязательно:**
+- После каждой задачи в wolf-sdd
+- После завершения крупной фичи
+- Перед мержем в main
+
+**Опционально, но ценно:**
+- Когда застрял (свежий взгляд)
+- Перед рефакторингом (базовая проверка)
+- После фиксации сложного бага
+
+## Как запросить
+
+**1. Получить git SHA:**
+```bash
+BASE_SHA=$(git rev-parse HEAD~1)   # или origin/main
+HEAD_SHA=$(git rev-parse HEAD)
+```
+
+**2. Диспетчеризовать воркера-ревьюера через {{tool.task}}:**
+
+Спавн worker-reviewer; контекст ревьюера заполняет диспетчер (executor-lead). Ревьюер сам подтягивает методику перед задачей: `wolf search "worker-reviewer playbook"` (контур лица, наибольшая версия).
+
+**Поля контекста:**
+- `{WHAT_WAS_IMPLEMENTED}` — что только что построено
+- `{PLAN_OR_REQUIREMENTS}` — что оно должно делать (задача из плана / бриф)
+- `{BASE_SHA}` — стартовый коммит
+- `{HEAD_SHA}` — конечный коммит
+- `{DESCRIPTION}` — краткое описание
+
+**3. Действовать по фидбеку (act-on-feedback):**
+
+| Категория | Действие |
+|---|---|
+| Critical | Исправить немедленно |
+| Important | Исправить до продолжения работы |
+| Minor | Зафиксировать и учесть позже (`wolf add --type lesson`) |
+
+Возражай, если ревьюер неправ (с обоснованием).
+
+## Пример
+
+```
+[Завершена задача 2: функция верификации]
+
+Ты: Запрошу ревью перед продолжением.
+
+BASE_SHA=$(git log --oneline | grep "Task 1" | head -1 | awk '{print $1}')
+HEAD_SHA=$(git rev-parse HEAD)
+
+[Диспетчеризую worker-reviewer через {{tool.task}}]
+  WHAT_WAS_IMPLEMENTED: Функции verifyIndex() и repairIndex() для индекса диалогов
+  PLAN_OR_REQUIREMENTS: Задача 2 из docs/plans/deployment-plan.md
+  BASE_SHA: a7981ec
+  HEAD_SHA: 3df7661
+  DESCRIPTION: Добавлены verifyIndex() и repairIndex() с 4 типами проблем
+
+[Воркер вернул]:
+  Strengths: чистая архитектура, настоящие тесты
+  Issues:
+    Important: нет индикаторов прогресса
+    Minor: магическое число (100) для интервала отчётности
+  Assessment: готов к продолжению
+
+Ты: [фиксируешь индикаторы прогресса]
+[Minor фиксируешь: wolf add --type lesson "техдолг: магическое число 100 ..."]
+[Продолжаешь задачу 3]
+```
+
+## Интеграция с процессами
+
+**wolf-sdd (субагентная разработка):**
+- Ревью после КАЖДОЙ задачи
+- Ловить проблемы до того, как они накопятся
+- Исправить до перехода к следующей задаче
+
+**wolf-execute (исполнение плана):**
+- Ревью после каждого батча (3 задачи)
+- Получить фидбек, применить, продолжить
+
+**Ad-hoc разработка:**
+- Ревью перед мержем
+- Ревью при застревании
+
+## Red flags
+
+**Никогда:**
+- Не пропускать ревью со словами «это же просто»
+- Не игнорировать Critical-находки
+- Не продолжать с неисправленными Important-находками
+- Не спорить с валидным техническим фидбеком
+
+**Если ревьюер неправ:**
+- Возразить с техническим обоснованием
+- Показать код/тесты, доказывающие работу
+- Попросить уточнение