mister-wolf 1.0.3 → 1.1.0

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

@@ -0,0 +1,128 @@
+---
+name: using-skills
+description: Мета-скилл: как находить и применять скиллы — 1%-правило, лестница приоритетов, порядок и типы. Use at the start of any session; для воркеров L2 диспетчерский контур отключён (см. ниже).
+---
+
+# using-skills — как пользоваться скиллами
+
+> Источник: ~/.config/opencode/superpowers/skills/using-superpowers/SKILL.md,
+> upstream 6efe32c (2026-04-23).
+
+## Трассировка переноса
+
+| Пункт источника | Судьба |
+| --------------- | ------ |
+| Frontmatter name/description | Сохранено (description переработан) |
+| SUBAGENT-STOP-блок | Заменено: воркеры L2 — диспетчерский контур отключён; скиллы пассивны (воркер читает процесс своей единственной задачи, но не диспетчит и не выбирает) |
+| EXTREMELY-IMPORTANT (1%-правило) | Сохранено, по смыслу дословно |
+| Instruction Priority (CLAUDE.md > skills > system prompt) | Заменено: лестница «правила проекта/память Wolf (AGENTS.md, `wolf search`) > скиллы > дефолт-поведение» |
+| How to Access Skills (разделы Claude Code / Copilot / Gemini) | Заменено: один нейтральный вызов {{tool.skill}} |
+| Platform Adaptation (tool mappings, references/*.md) | Отброшено: платформенная специфика — зона рендерера (подстановка имён тулов через плейсхолдеры) |
+| The Rule + flowchart | Сохранено; Skill-тул → {{tool.skill}}, TodoWrite → {{tool.todowrite}}, Task (субагенты) → {{tool.task}}; вершина «About to EnterPlanMode?» — отброшена (концепт Claude Code, в Wolf нет аналога) |
+| Red Flags — таблица рационализаций | Сохранено ПОЛНОСТЬЮ: 12/12, по смыслу дословно (upstream запрещает правки списка) |
+| Skill Priority (process → implementation) | Сохранено |
+| Skill Types (rigid / flexible) | Сохранено |
+| User Instructions (WHAT ≠ HOW) | Сохранено |
+
+## Воркеры L2 — пассивный режим
+
+Если ты воркер L2 (диспетчерский контур отключён): скиллы для тебя —
+**пассивные процессы**. Читай процесс своей единственной задачи (дисциплина
+из подзадачи — например TDD), но не диспетчь скиллы, не выбирай их сам и не
+запускай перебор применимости. Спавн субагентов не твой — у воркеров
+{{tool.task}} отключён; нужна чужая работа — верни диспетчеру «нужен
+executor: <причина>».
+
+## Правило
+
+**Загружай релевантный или запрошенный скилл ДО любого ответа или
+действия.** Даже 1% шанс применимости → загрузи скилл и проверь. Если
+загруженный скилл оказался неподходящим — использовать его не обязан.
+
+Если думаешь, что скилл может примениться к твоей задаче, — у тебя нет
+выбора: загрузи его. Это не обсуждается и не является опциональным.
+Рационализировать выход из этого нельзя.
+
+```dot
+digraph skill_flow {
+    "Сообщение пользователя" [shape=doublecircle];
+    "Может примениться какой-то скилл?" [shape=diamond];
+    "Загрузи через {{tool.skill}}" [shape=box];
+    "Анонс: «Использую [скилл] для [цель]»" [shape=box];
+    "Есть чек-лист?" [shape=diamond];
+    "Создай задачи в {{tool.todowrite}} по пунктам" [shape=box];
+    "Следуй скиллу точно" [shape=box];
+    "Ответь (включая уточнения)" [shape=doublecircle];
+
+    "Сообщение пользователя" -> "Может примениться какой-то скилл?";
+    "Может примениться какой-то скилл?" -> "Загрузи через {{tool.skill}}" [label="да, даже 1%"];
+    "Может примениться какой-то скилл?" -> "Ответь (включая уточнения)" [label="точно нет"];
+    "Загрузи через {{tool.skill}}" -> "Анонс: «Использую [скилл] для [цель]»";
+    "Анонс: «Использую [скилл] для [цель]»" -> "Есть чек-лист?";
+    "Есть чек-лист?" -> "Создай задачи в {{tool.todowrite}} по пунктам" [label="да"];
+    "Есть чек-лист?" -> "Следуй скиллу точно" [label="нет"];
+    "Создай задачи в {{tool.todowrite}} по пунктам" -> "Следуй скиллу точно";
+    "Следуй скиллу точно" -> "Ответь (включая уточнения)";
+}
+```
+
+## Лестница приоритетов
+
+Скиллы перекрывают дефолтное поведение, но **правила проекта и память Wolf
+всегда выше**:
+
+1. **Правила проекта и память Wolf** (AGENTS.md проекта; актуальные
+   правила, решения и уроки из памяти — `wolf search`, `wolf brief`) —
+   высший приоритет.
+2. **Скиллы** — перекрывают дефолтное поведение там, где не конфликтуют
+   с п. 1.
+3. **Дефолт-поведение** — низший приоритет.
+
+Если правила проекта говорят «без TDD», а скилл требует «всегда TDD» —
+следуй правилам проекта. Владелец управляет.
+
+## Red Flags
+
+Эти мысли означают СТОП — ты рационализируешь:
+
+| Мысль | Реальность |
+| ----- | ---------- |
+| «Это просто вопрос» | Вопросы — это задачи. Проверь скиллы. |
+| «Сначала мне нужен больше контекста» | Проверка скиллов — ДО уточняющих вопросов. |
+| «Дай сначала осмотрю кодовую базу» | Скиллы говорят, КАК осматривать. Сначала проверь. |
+| «Быстро гляну git/файлы» | У файлов нет контекста разговора. Проверь скиллы. |
+| «Сначала соберу информацию» | Скиллы говорят, КАК собирать информацию. |
+| «Тут не нужен формальный скилл» | Если скилл существует — используй. |
+| «Я помню этот скилл» | Скиллы эволюционируют. Читай актуальную версию. |
+| «Это не считается задачей» | Действие = задача. Проверь скиллы. |
+| «Скилл — из пушки по воробьям» | Простое становится сложным. Используй его. |
+| «Сделаю сперва вот это одно» | Проверь ДО того, как что-либо делать. |
+| «Это ощущается продуктивным» | Недисциплинированные действия — впустую. Скиллы предотвращают это. |
+| «Я знаю, что это значит» | Знать концепцию ≠ использовать скилл. Загрузи. |
+
+## Порядок скиллов
+
+Когда применимо несколько — порядок такой:
+
+1. **Сначала process-скиллы** (wolf-brainstorm, wolf-debug — класс
+   brainstorming/debugging) — они определяют, КАК подойти к задаче.
+2. **Потом implementation-скиллы** — они ведут исполнение.
+
+«Построим X» → сначала brainstorming-класс, затем implementation.
+«Почини баг» → сначала debugging-класс, затем доменные скиллы.
+
+Диспетчеризация исполнения на воркеров — через {{tool.task}} (зона
+координаторов L0/L1, не воркеров).
+
+## Типы скиллов
+
+**Rigid** (TDD, wolf-debug): следуй точно. Не адаптируй дисциплину.
+
+**Flexible** (паттерны): адаптируй принципы к контексту.
+
+Скилл сам говорит, какого он типа.
+
+## Инструкции пользователя
+
+Инструкции говорят ЧТО, а не КАК. «Добавь X» или «Почини Y» не означает
+пропускать процессы.

package/templates/base/skills/verification-before-completion/SKILL.md

@@ -0,0 +1,157 @@
+---
+name: verification-before-completion
+description: Используй перед любым заявлением о завершённости, исправленности или прохождении тестов, перед коммитом или PR — требует запуска верификационных команд и подтверждения вывода до любых заявлений об успехе; доказательства раньше утверждений, всегда
+---
+
+# Verification Before Completion
+
+> Источник: ~/.config/opencode/superpowers/skills/verification-before-completion/SKILL.md, upstream 6efe32c (2026-04-23).
+> Адресат: все уровни (L0–L2); в контуре Wolf — обязательная дисциплина отчётов executor-lead и воркеров.
+
+## Трассировка адаптации
+
+| Пункт upstream | Судьба |
+|---|---|
+| Iron Law, функция-гейт (5 шагов), таблица типовых сбоев (7), red flags (8), рационализации (8), ключевые паттерны (5), «Why This Matters» (5), «When To Apply» (2 списка) | **сохранено полностью** по смыслу дословно (H7; research §1: «Нет — полностью переносим») |
+| «Agent delegation» | **заменено**: агенты → воркеры контура Wolf (worker-\*); отчёт воркера — не доказательство, dispatcher проверяет git-дифф и верификацию |
+| Тестовая команда | **конкретизировано**: `npm run check` — верификационный примитив проекта (+ точечные прогоны `npx vitest run <путь>`) |
+| Nothing | **отброшено**: ничего — привязок к harness у источника нет |
+
+## Обзор
+
+Заявлять о завершённости работы без верификации — нечестность, а не эффективность.
+
+**Принцип:** доказательства раньше утверждений. Всегда.
+
+**Нарушение буквы этого правила — нарушение духа этого правила.**
+
+## Iron Law
+
+```
+НИКАКИХ ЗАЯВЛЕНИЙ О ЗАВЕРШЕНИИ БЕЗ СВЕЖИХ ДОКАЗАТЕЛЬСТВ ВЕРИФИКАЦИИ
+```
+
+Не запустил верификационную команду в этом сообщении — не можешь заявлять, что она проходит.
+
+## Функция-гейт
+
+```
+ПЕРЕД любым заявлением статуса или выражением удовлетворения:
+
+1. ОПРЕДЕЛИ: какая команда доказывает это заявление?
+2. ЗАПУСТИ: полную команду (свежую, целиком)
+3. ПРОЧИТАЙ: весь вывод, проверь exit code, посчитай падения
+4. СВЕРЬ: вывод подтверждает заявление?
+   - НЕТ → назови фактический статус с доказательствами
+   - ДА → делай заявление С доказательствами
+5. ТОЛЬКО ПОТОМ: заявляй
+
+Пропустил любой шаг = ложь, а не верификация
+```
+
+## Типовые сбои
+
+| Заявление | Требуется | Недостаточно |
+|-------|----------|----------------|
+| Тесты проходят | Вывод тестовой команды: 0 падений | Прошлый прогон, «должно пройти» |
+| Линтер чист | Вывод линтера: 0 ошибок | Частичная проверка, экстраполяция |
+| Сборка проходит | Команда сборки: exit 0 | Линтер зелёный, логи выглядят хорошо |
+| Баг исправлен | Тест исходного симптома: проходит | Код изменён, «предположительно исправлено» |
+| Регрессионный тест работает | Проверен цикл красный-зелёный | Тест прошёл один раз |
+| Воркер завершил задачу | git-дифф показывает изменения | Отчёт воркера «успех» |
+| Требования выполнены | Построчный чеклист | Тесты проходят |
+
+## Red flags — СТОП
+
+- «должно», «вероятно», «кажется»
+- Выражение удовлетворения до верификации («Отлично!», «Идеально!», «Готово!» и т.п.)
+- Вот-вот коммит/пуш/PR без верификации
+- Доверие отчётам воркеров об успехе
+- Опора на частичную верификацию
+- Мысль «только этот раз»
+- Устал и хочешь, чтобы работа закончилась
+- **ЛЮБАЯ формулировка, подразумевающая успех без запуска верификации**
+
+## Профилактика рационализаций
+
+| Оправдание | Реальность |
+|--------|---------|
+| «Сейчас должно работать» | ЗАПУСТИ верификацию |
+| «Я уверен» | Уверенность ≠ доказательство |
+| «Только этот раз» | Без исключений |
+| «Линтер прошёл» | Линтер ≠ компилятор |
+| «Воркер доложил об успехе» | Проверь независимо |
+| «Я устал» | Усталость ≠ оправдание |
+| «Частичной проверки хватит» | Частичное не доказывает ничего |
+| «Другие слова — правило не применяется» | Дух важнее буквы |
+
+## Ключевые паттерны
+
+**Тесты:**
+```
+✅ [npm run check] [Видно: 591/591 pass] «Все тесты проходят»
+❌ «Сейчас должно пройти» / «Выглядит корректно»
+```
+
+**Регрессионные тесты (TDD красный-зелёный):**
+```
+✅ Написал → Запустил (проходит) → Откатил фикс → Запустил (ОБЯЗАН УПАСТЬ) → Вернул → Запустил (проходит)
+❌ «Я написал регрессионный тест» (без красно-зелёной верификации)
+```
+
+**Сборка:**
+```
+✅ [npm run build] [Видно: exit 0] «Сборка проходит»
+❌ «Линтер прошёл» (линтер не проверяет компиляцию)
+```
+
+**Требования:**
+```
+✅ Перечитай план → составь чеклист → проверь каждый пункт → доложи пробелы или завершение
+❌ «Тесты проходят, фаза завершена»
+```
+
+**Делегирование воркерам:**
+```
+✅ Воркер доложил успех → проверь git-дифф → верифицируй изменения → доложи фактическое состояние
+❌ Доверять отчёту воркера (воркер, спавненный через {{tool.task}}, мог ошибиться)
+```
+
+## Почему это важно
+
+Из 24 воспоминаний о сбоях:
+- партнёр сказал «я тебе не верю» — доверие разрушено
+- В прод уехали неопределённые функции — урон
+- В прод уехали пропущенные требования — незавершённые фичи
+- Время потрачено на ложное «готово» → перенаправление → переделка
+- Нарушение принципа: «Честность — ключевая ценность. Солжёшь — тебя заменят»
+
+## Когда применять
+
+**ВСЕГДА перед:**
+- Любой вариацией заявлений об успехе/завершённости
+- Любым выражением удовлетворения
+- Любым позитивным утверждением о состоянии работы
+- Коммитом, созданием PR, завершением задачи
+- Переходом к следующей задаче
+- Делегированием воркерам
+
+**Правило распространяется на:**
+- Точные формулировки
+- Парафразы и синонимы
+- Импликации успеха
+- ЛЮБУЮ коммуникацию, предполагающую завершённость/корректность
+
+## Интеграция с Wolf
+
+- **Верификационный примитив** проекта — `npm run check`; точечные проверки — `npx vitest run <путь-к-тесту>`.
+- **Отчёты воркеров** — не доказательство: dispatcher (executor-lead) проверяет git-дифф и свежий прогон, прежде чем доложить наверх.
+- **Инцидент ложного «готово»** — урок в память: `wolf add --type lesson`, чтобы ловушка была видна следующим сессиям.
+
+## Итог
+
+**Нет коротких путей для верификации.**
+
+Запусти команду. Прочитай вывод. ТОЛЬКО ПОТОМ заявляй результат.
+
+Это не обсуждается.

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

@@ -0,0 +1,167 @@
+---
+name: wolf-brainstorm
+description: "Обязателен до любой творческой работы — новых фич, компонентов, изменения поведения. Превращает идею в дизайн через диалог: вопросы по одному, варианты с трейд-оффами, аппрув владельца. Discovery-режим координатора."
+---
+
+# wolf-brainstorm: идея → дизайн
+
+Превращай идеи в законченные дизайны и спеки через естественный совместный диалог.
+
+Начни с понимания контекста проекта, затем задавай вопросы по одному, чтобы уточнить идею. Когда понял, что строится, — представь дизайн и получи аппрув владельца.
+
+Это Discovery-режим координатора: ты исследуешь и проясняешь, а не строишь.
+
+<HARD-GATE>
+Не вызывай ни один скилл реализации, не пиши код, не создавай скелет проекта и не предпринимай никаких действий реализации, пока не представил дизайн и владелец его не аппробовал. Это касается КАЖДОГО проекта независимо от воспринимаемой простоты.
+</HARD-GATE>
+
+## Анти-паттерн: «Это слишком просто, чтобы нужен дизайн»
+
+Через этот процесс проходит каждый проект. Туду-лист, утилита из одной функции, правка конфига — все они. «Простые» проекты — именно там, где непроверенные предположения дают больше всего лишней работы. Дизайн может быть коротким (несколько предложений для действительно простых проектов), но ты ОБЯЗАН его представить и получить аппрув.
+
+## Чеклист
+
+Создай задачи по каждому пункту через {{tool.todowrite}} и выполняй по порядку:
+
+1. **Изучи контекст проекта** — файлы, документация, недавние коммиты
+2. **Задавай уточняющие вопросы** — по одному; цель, ограничения, критерии успеха
+3. **Предложи 2–3 подхода** — с трейд-оффами и своей рекомендацией
+4. **Представь дизайн** — секциями, масштаб каждой под её сложность; аппрув после каждой секции
+5. **Запиши дизайн-документ** — в каталог спек проекта (по умолчанию `docs/specs/YYYY-MM-DD-<тема>-design.md`; предпочтения проекта приоритетнее дефолта) и закоммить (правило проекта: коммит после завершённой работы)
+6. **Саморевью спеки** — быстрая проверка на плейсхолдеры, противоречия, двусмысленность, scope (см. ниже)
+7. **Ревью спеки владельцем** — владелец читает файл спеки до продолжения
+8. **Переход к планированию** — вызови {{tool.skill}} wolf-plan
+
+**Worktree этот скилл НЕ создаёт** — изоляция рабочего каталога начинается только на этапе исполнения (см. wolf-sdd / wolf-execute, правило `.worktrees/<имя-задачи>`).
+
+## Ход процесса
+
+```dot
+digraph wolf_brainstorm {
+    "Изучи контекст проекта" [shape=box];
+    "Задавай уточняющие вопросы" [shape=box];
+    "Предложи 2-3 подхода" [shape=box];
+    "Представь секции дизайна" [shape=box];
+    "Владелец аппрувает дизайн?" [shape=diamond];
+    "Запиши дизайн-документ" [shape=box];
+    "Саморевью спеки\n(правки на месте)" [shape=box];
+    "Владелец ревьюит спеку?" [shape=diamond];
+    "Вызови {{tool.skill}} wolf-plan" [shape=doublecircle];
+
+    "Изучи контекст проекта" -> "Задавай уточняющие вопросы";
+    "Задавай уточняющие вопросы" -> "Предложи 2-3 подхода";
+    "Предложи 2-3 подхода" -> "Представь секции дизайна";
+    "Представь секции дизайна" -> "Владелец аппрувает дизайн?";
+    "Владелец аппрувает дизайн?" -> "Представь секции дизайна" [label="нет, доработай"];
+    "Владелец аппрувает дизайн?" -> "Запиши дизайн-документ" [label="да"];
+    "Запиши дизайн-документ" -> "Саморевью спеки\n(правки на месте)";
+    "Саморевью спеки\n(правки на месте)" -> "Владелец ревьюит спеку?";
+    "Владелец ревьюит спеку?" -> "Запиши дизайн-документ" [label="запрошены правки"];
+    "Владелец ревьюит спеку?" -> "Вызови {{tool.skill}} wolf-plan" [label="аппрув"];
+}
+```
+
+**Терминальное состояние — вызов wolf-plan.** Не вызывай скиллы реализации и никакие другие. ЕДИНСТВЕННЫЙ скилл после wolf-brainstorm — wolf-plan.
+
+## Процесс
+
+**Понимание идеи:**
+
+- Сначала посмотри текущее состояние проекта (файлы, документация, недавние коммиты)
+- До детальных вопросов оцени масштаб: если запрос описывает несколько независимых подсистем (например, «платформа с чатом, хранилищем, биллингом и аналитикой») — сразу скажи об этом. Не трать вопросы на уточнение деталей проекта, который сначала нужно декомпозировать.
+- Если проект слишком велик для одной спеки — помоги владельцу разбить его на подпроекты: какие части независимы, как связаны, в каком порядке строить. Затем прогоняй первый подпроект через обычный флоу. Каждый подпроект получает свой цикл спека → план → реализация.
+- Для проектов подходящего масштаба задавай вопросы по одному
+- Предпочитай вопросы с вариантами ответа, но открытые тоже допустимы
+- Только один вопрос на сообщение — если тема требует глубины, разбей на несколько вопросов
+- Фокус на понимании: цель, ограничения, критерии успеха
+
+**Исследование подходов:**
+
+- Предложи 2–3 разных подхода с трейд-оффами
+- Представляй варианты разговорно, со своей рекомендацией и обоснованием
+- Веди с рекомендуемого варианта и объясни, почему именно он
+
+**Презентация дизайна:**
+
+- Когда понял, что строишь, — представь дизайн
+- Масштабируй каждую секцию под её сложность: несколько предложений для простого, до 200–300 слов для нюансированного
+- После каждой секции спрашивай, всё ли верно пока
+- Покрой: архитектуру, компоненты, поток данных, обработку ошибок, тестирование
+- Будь готов вернуться и уточнить, если что-то не сходится
+
+**Дизайн для изоляции и ясности:**
+
+- Дели систему на маленькие блоки, каждый с одной ясной целью, общающиеся через определённые интерфейсы, — понятные и тестируемые независимо
+- Для каждого блока отвечай: что он делает, как им пользоваться, от чего он зависит?
+- Можно ли понять блок, не читая его внутренности? Можно ли менять внутренности, не ломая потребителей? Если нет — границы требуют доработки.
+- Маленькие чётко очерченные блоки проще и для тебя: над кодом, который держится в контексте целиком, ты рассуждаешь лучше, а правки точечнее. Разросшийся файл — часто сигнал, что он делает слишком много.
+
+**Работа в существующей кодовой базе:**
+
+- Изучи текущую структуру до предложения правок. Следуй существующим паттернам.
+- Если существующий код мешает работе (файл разросся, границы размыты, ответственности перепутаны) — включи точечные улучшения в дизайн, как хороший разработчик, улучшающий код, в котором работает.
+- Не предлагай несвязанный рефакторинг. Фокус на том, что служит текущей цели.
+
+## После дизайна
+
+**Документация:**
+
+- Запиши валидированный дизайн (спеку) в каталог спек проекта (по умолчанию `docs/specs/YYYY-MM-DD-<тема>-design.md`; предпочтения проекта приоритетнее)
+- Закоммить дизайн-документ (правило проекта: коммит после завершённой работы)
+- Ключевые решения дизайна зафиксируй в памяти: `wolf add --type decision` — с обоснованием; они переживут сессию и достанутся исполнителям
+
+**Саморевью спеки:**
+После записи спеки посмотри на неё свежим взглядом:
+
+1. **Скан плейсхолдеров:** есть ли «TBD», «TODO», незаполненные секции, размытые требования? Исправь.
+2. **Внутренняя согласованность:** противоречат ли секции друг другу? Согласуется ли архитектура с описанием фич?
+3. **Проверка scope:** достаточно ли фокусировки для одного плана реализации, или нужна декомпозиция?
+4. **Проверка двусмысленности:** можно ли истолковать требование двумя способами? Если да — выбери одну трактовку и сделай явной.
+
+Исправляй на месте. Пересматривать заново не нужно — исправил и двигайся дальше.
+
+**Гейт ревью владельца:**
+После прохождения саморевью попроси владельца прочитать записанную спеку до продолжения:
+
+> «Спека записана и закоммичена в `<путь>`. Посмотри её и скажи, нужны ли правки, прежде чем начнём писать план реализации».
+
+Жди ответа. Запрошены правки — внеси и прогони саморевью заново. Продолжай только после аппрува владельца.
+
+**Реализация:**
+
+- Вызови {{tool.skill}} wolf-plan для создания детального плана реализации
+- НЕ вызывай никаких других скиллов. Следующий шаг — только wolf-plan.
+
+## Ключевые принципы
+
+- **Один вопрос за раз** — не перегружай несколькими вопросами
+- **Предпочитай варианты ответа** — отвечать проще, чем на открытый вопрос
+- **Беспощадный YAGNI** — убирай ненужные фичи из всех дизайнов
+- **Исследуй альтернативы** — всегда 2–3 подхода до выбора
+- **Инкрементальная валидация** — представляй дизайн, получай аппрув, потом дальше
+- **Будь гибким** — возвращайся и уточняй, когда что-то не сходится
+
+---
+
+## Трассировка адаптации
+
+> Источник: `~/.config/opencode/superpowers/skills/brainstorming/SKILL.md`, upstream 6efe32c (2026-04-23)
+
+| Пункт источника | Судьба | Почему |
+|---|---|---|
+| HARD-GATE до аппрува | сохранено | Ядро скилла; «user» → «владелец» |
+| Анти-паттерн «слишком просто для дизайна» | сохранено полностью (1/1) | H7 |
+| Чеклист (9 пунктов) | сохранено; п.2 (visual companion) отброшен, п.9 → wolf-plan | Браузерный компаньон вне базового набора |
+| Пункт «Invoke writing-plans skill» | заменено → `{{tool.skill}} wolf-plan` | H4: терминальное состояние — только wolf-plan |
+| TodoWrite | заменено → `{{tool.todowrite}}` | Плейсхолдер |
+| Flowchart | сохранено; терминальный узел → wolf-plan | Ядро-флоу |
+| «The Process» (5 блоков) | сохранено | Переносимое ядро |
+| Путь `docs/superpowers/specs/` | заменено → `docs/specs/…` + предпочтения проекта | Harness-привязка (research §1) |
+| Саморевью спеки (4 проверки) | сохранено полностью (4/4) | Чеклист-ядро |
+| Гейт ревью владельца | сохранено | Ядро |
+| Ключевые принципы (6) | сохранено полностью (6/6) | H7 |
+| Скилл elements-of-style (секция «Документация») | отброшено | Скилл вне базового набора (research §6) |
+| Visual Companion (секция + `visual-companion.md`) | отброшено | Браузерный компаньон и sibling-файл не переносятся |
+| — | добавлено: Discovery-режим; worktree НЕ создаёт; `wolf add --type decision` | Спека §5.2 (архив §2.3), H5-распределение владения worktree |
+
+Перенесённые списки: анти-паттерны 1/1, принципы 6/6, саморевью 4/4.