mister-wolf 2.15.0 → 2.15.2

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

@@ -1,293 +1,27 @@
 ---
 name: wolf-debug
-description: "Используй при любом баге, падении теста или неожиданном поведении — ДО предложения фиксов. 4 фазы root-cause: исследование причины → анализ паттернов → гипотеза и тест → реализация фикса под падающий тест."
+description: "Исследуй баг, падение проверки или неожиданное поведение: воспроизведение, evidence, гипотезы, изолированные эксперименты и регрессионный фикс. Различай устранение причины и аварийное снижение ущерба."
 ---
 
-# wolf-debug: систематический дебаг
+# Систематическая отладка
 
-## Обзор
+## Процесс
 
-Случайные фиксы тратят время и порождают новые баги. Быстрые заплатки маскируют лежащие под ними проблемы.
+1. Зафиксируй симптом, ожидаемое, revision, среду, частоту, точные шаги и исходный лог. Не воспроизводится — сохраняй наблюдение и собирай данные, не объявляй причину установленной.
+2. Проверь недавние изменения и работающий аналог. Прочитай относящиеся к проблеме контракты и зависимости; не требуй читать несвязанный большой референс целиком.
+3. Трассируй входы/выходы на подозреваемых границах. Логируй минимальные метаданные с редактированием секретов/PII; не печатай окружение и payload полностью. Диагностические изменения должны иметь cleanup.
+4. Веди журнал: hypothesis, evidence for/against, discriminating experiment, result, next step. Рассматривай альтернативы; каждый эксперимент меняет одну существенную переменную или явно описывает связанные изменения.
+5. Подтверждённую причину зафиксируй воспроизводимой проверкой. Исправление проведи по test-driven-development; проверь исходный сценарий, регрессии и важные взаимодействия.
+6. По завершении укажи root cause, fix, evidence, остаточные риски и удалённую временную диагностику. Урок записывай только при возможности переиспользования и с областью применимости.
 
-**Ядро принципа:** ВСЕГДА находи корневую причину до попыток фикса. Фикс симптома — это провал.
+## Повторы и эскалация
 
-**Нарушение буквы этого процесса — нарушение духа дебага.**
+После 2 неудачных исправлений либо повторения одной гипотезы останови угадывание: проверь качество воспроизведения, полноту модели и входы. Третья неудача — сигнал независимого разбора, не доказательство дефекта архитектуры. L2 возвращает BLOCKED с журналом; L1 решает о новом контексте, модели, декомпозиции или архитектурном исследовании. Scope не расширяй сам.
 
-## Железный закон
+## Инцидент
 
-```
-НИКАКИХ ФИКСОВ БЕЗ ИССЛЕДОВАНИЯ КОРНЕВОЙ ПРИЧИНЫ
-```
+При текущем ущербе сначала допустимо обратимое containment в пределах полномочий: откат, отключение функции или ограничение нагрузки. Зафиксируй разрешение, действие и способ возврата; не называй это устранением причины. Необратимые или внешние действия требуют действующего разрешения. После стабилизации продолжи расследование.
 
-Если ты не завершил фазу 1, ты не можешь предлагать фиксы.
+## Неизвестный исход
 
-## Когда использовать
-
-Используй для ЛЮБОЙ технической проблемы:
-- Падения тестов
-- Баги в проде
-- Неожиданное поведение
-- Проблемы производительности
-- Сломанные сборки
-- Интеграционные проблемы
-
-**Используй ОСОБЕННО, когда:**
-- Давит время (авралы делают угадывание соблазнительным)
-- «Просто один быстрый фикс» кажется очевидным
-- Ты уже попробовал несколько фиксов
-- Предыдущий фикс не сработал
-- Ты не до конца понимаешь проблему
-
-**Не пропускай, когда:**
-- Проблема кажется простой (у простых багов тоже есть корневые причины)
-- Ты спешишь (спешка гарантирует переделку)
-- Владелец требует «починить СЕЙЧАС» (систематичность быстрее метаний)
-
-## Четыре фазы
-
-Каждую фазу ОБЯЗАН завершить до перехода к следующей.
-
-### Фаза 1: исследование корневой причины
-
-**ДО попытки ЛЮБОГО фикса:**
-
-1. **Внимательно читай сообщения об ошибках**
-   - Не проскальзывай мимо ошибок и предупреждений
-   - Они часто содержат точное решение
-   - Читай стектрейсы полностью
-   - Отмечай номера строк, пути файлов, коды ошибок
-
-2. **Воспроизводи стабильно**
-   - Можешь ли вызвать это надёжно?
-   - Каковы точные шаги?
-   - Происходит ли каждый раз?
-   - Не воспроизводится → собирай больше данных, не угадывай
-
-3. **Проверь недавние изменения**
-   - Что изменилось из того, что могло это вызвать?
-   - Git diff, недавние коммиты
-   - Новые зависимости, изменения конфигурации
-   - Различия окружения
-
-4. **Собирай улики в мультикомпонентных системах**
-
-   **КОГДА система имеет много компонентов (CI → сборка → подпись, API → сервис → БД):**
-
-   **ДО предложения фиксов добавь диагностическую инструментацию:**
-   ```
-   Для КАЖДОЙ границы компонентов:
-     - Логируй, какие данные входят в компонент
-     - Логируй, какие данные выходят из компонента
-     - Проверяй проброс окружения/конфигурации
-     - Проверяй состояние на каждом слое
-
-   Один прогон для сбора улик — ГДЕ ломается
-   ЗАТЕМ анализ улик — какой компонент падает
-   ЗАТЕМ исследование именно этого компонента
-   ```
-
-   **Это показывает:** какой слой падает (секреты → workflow ✓, workflow → сборка ✗)
-
-5. **Трассируй поток данных**
-
-   **КОГДА ошибка глубоко в стектрейсе:**
-   - Где порождается плохое значение?
-   - Кто вызвал это с плохим значением?
-   - Трассируй вверх, пока не найдёшь источник
-   - Чини в источнике, а не в симптоме
-
-### Фаза 2: анализ паттернов
-
-**Найди паттерн до фикса:**
-
-1. **Найди работающие примеры**
-   - Найди похожий работающий код в той же кодовой базе
-   - Что работает так же, как то, что сломано?
-
-2. **Сравни с эталонами**
-   - Если реализуешь паттерн — прочитай референс ПОЛНОСТЬЮ
-   - Не просматривай по диагонали — каждую строку
-   - Пойми паттерн полностью до применения
-
-3. **Определи различия**
-   - Что отличается между работающим и сломанным?
-   - Перечисли каждое различие, каким бы малым ни было
-   - Не предполагай «это не может иметь значения»
-
-4. **Пойми зависимости**
-   - Какие ещё компоненты ему нужны?
-   - Какие настройки, конфигурация, окружение?
-   - Какие предположения он делает?
-
-### Фаза 3: гипотеза и тестирование
-
-**Научный метод:**
-
-1. **Сформулируй единственную гипотезу**
-   - Сформулируй ясно: «Я думаю, корневая причина — X, потому что Y»
-   - Запиши
-   - Будь конкретен, не расплывчат
-
-2. **Тестируй минимально**
-   - Сделай САМОЕ МАЛЕНЬКОЕ возможное изменение для проверки гипотезы
-   - Одна переменная за раз
-   - Не чини несколько вещей сразу
-
-3. **Верифицируй до продолжения**
-   - Сработало? Да → фаза 4
-   - Не сработало — сформулируй НОВУЮ гипотезу
-   - НЕ наслаивай ещё фиксы сверху
-
-4. **Когда не знаешь**
-   - Скажи «я не понимаю X»
-   - Не притворяйся, что знаешь
-   - Проси помощи
-   - Исследуй дальше
-
-### Фаза 4: реализация фикса
-
-**Чини корневую причину, а не симптом:**
-
-1. **Создай падающий тест**
-   - Простейшее возможное воспроизведение
-   - Автотест, если возможно
-   - Одноразовый тест-скрипт, если нет фреймворка
-   - ОБЯЗАН быть до фикса
-   - **Используй скилл test-driven-development для написания правильного падающего теста — фикс пишется ТОЛЬКО под падающий тест**
-
-2. **Реализуй единственный фикс**
-   - Адресуй выявленную корневую причину
-   - ОДНО изменение за раз
-   - Никаких улучшений «раз уж я здесь»
-   - Никакого сопутствующего рефакторинга
-
-3. **Верифицируй фикс**
-   - Тест теперь проходит?
-   - Другие тесты не сломались? (`npm run check` — verification-примитив проекта)
-   - Проблема реально решена?
-
-4. **Если фикс не сработал**
-   - СТОП
-   - Посчитай: сколько фиксов ты уже попробовал?
-   - Если < 3 — вернись к фазе 1, переанализируй с новой информацией
-   - **Если ≥ 3 — СТОП и поставь под вопрос архитектуру (шаг 5 ниже)**
-   - НЕ пытайся делать фикс №4 без архитектурного обсуждения
-
-5. **Если 3+ фиксов провалились: поставь под вопрос архитектуру**
-
-   **Паттерн, указывающий на архитектурную проблему:**
-   - Каждый фикс вскрывает новое общее состояние/связность/проблему в другом месте
-   - Фиксы требуют «массированного рефакторинга»
-   - Каждый фикс создаёт новые симптомы в других местах
-
-   **СТОП и спроси фундаментально:**
-   - Паттерн в принципе здрав?
-   - Не «держимся ли мы за него по чистой инерции»?
-   - Может, рефакторить архитектуру вместо продолжения латания симптомов?
-
-   **Обсуди с владельцем до новых попыток фикса.**
-
-   Это НЕ провалившаяся гипотеза — это неверная архитектура.
-
-## Red Flags — СТОП и вернись к процессу
-
-Если ловишь себя на мысли:
-- «Быстрый фикс сейчас, исследую потом»
-- «Просто поменяю X и посмотрю, сработает ли»
-- «Внесу несколько изменений, прогоню тесты»
-- «Пропущу тест, проверю руками»
-- «Наверное, это X, поправлю это»
-- «Я не до конца понимаю, но это может сработать»
-- «В паттерне сказано X, но я адаптирую по-своему»
-- «Вот основные проблемы: [список фиксов без исследования]»
-- Предлагаешь решения до трассировки потока данных
-- **«Ещё одна попытка фикса» (когда уже попробовал 2+)**
-- **Каждый фикс вскрывает новую проблему в другом месте**
-
-**ВСЁ это значит: СТОП. Вернись к фазе 1.**
-
-**Если 3+ фиксов провалились:** поставь под вопрос архитектуру (фаза 4, шаг 5).
-
-## Сигналы владельца, что ты делаешь не так
-
-**Следи за этими поправками:**
-- «А это вообще происходит?» — Ты предположил, не проверив
-- «Это нам покажет…?» — Надо было добавить сбор улик
-- «Перестань угадывать» — Ты предлагаешь фиксы без понимания
-- «Продумай фундаментально» — Ставь под вопрос основы, а не только симптомы
-- «Мы застряли?» (фрустрация) — Твой подход не работает
-
-**Увидел — СТОП. Вернись к фазе 1.**
-
-## Типичные рационализации
-
-| Оправдание | Реальность |
-|--------|---------|
-| «Проблема простая, процесс не нужен» | У простых проблем тоже есть корневые причины. Процесс быстр для простых багов. |
-| «Авария, нет времени на процесс» | Систематический дебаг БЫСТРЕЕ, чем метания угадай-и-проверь. |
-| «Сначала попробую это, потом исследую» | Первый фикс задаёт паттерн. Делай правильно с самого начала. |
-| «Тест напишу после подтверждения, что фикс работает» | Непроверенные фиксы не приживаются. Сначала тест — потом он доказывает. |
-| «Несколько фиксов сразу сэкономят время» | Не изолировать, что сработало. Порождает новые баги. |
-| «Референс слишком длинный, адаптирую паттерн по мотивам» | Частичное понимание гарантирует баги. Читай полностью. |
-| «Вижу проблему, давайте чинить» | Видеть симптомы ≠ понимать корневую причину. |
-| «Ещё одна попытка фикса» (после 2+ провалов) | 3+ провала = архитектурная проблема. Ставь паттерн под вопрос, не чини снова. |
-
-## Быстрая шпаргалка
-
-| Фаза | Ключевые активности | Критерий успеха |
-|-------|---------------|------------------|
-| **1. Корневая причина** | Читай ошибки, воспроизводи, проверь изменения, собери улики | Понимать ЧТО и ПОЧЕМУ |
-| **2. Паттерн** | Найди работающие примеры, сравни | Определить различия |
-| **3. Гипотеза** | Сформулируй теорию, тестируй минимально | Подтверждена или новая |
-| **4. Реализация** | Создай тест, чини, верифицируй | Баг решён, тесты зелёные |
-
-## Когда процесс показывает «корневой причины нет»
-
-Если систематическое исследование показало, что проблема действительно экологическая, зависит от таймингов или внешняя:
-
-1. Ты завершил процесс
-2. Задокументируй, что исследовал (`wolf add --type lesson` — следующий агент не должен повторять путь)
-3. Реализуй подходящую обработку (retry, timeout, сообщение об ошибке)
-4. Добавь мониторинг/логирование для будущих исследований
-
-**Но:** 95% случаев «нет корневой причины» — это незавершённое исследование.
-
-## Смежные скиллы
-
-- **test-driven-development** — для создания падающего теста (фаза 4, шаг 1): фикс только под падающий тест
-- **verification-before-completion** — проверь, что фикс сработал, до заявления об успехе
-
-## Реальный эффект
-
-Из дебаг-сессий:
-- Систематический подход: 15–30 минут на фикс
-- Подход случайных фиксов: 2–3 часа метаний
-- Фикс с первого раза: 95% против 40%
-- Новые баги: почти ноль против обычного дела
-
----
-
-## Трассировка адаптации
-
-> Источник: `~/.config/opencode/superpowers/skills/systematic-debugging/SKILL.md`, upstream 6efe32c (2026-04-23)
-
-| Пункт источника | Судьба | Почему |
-|---|---|---|
-| Обзор + ядро принципа | сохранено | Ядро |
-| Железный закон | сохранено | STOP-правило |
-| When to Use (6) / ESPECIALLY (5) / Don't skip (3) | сохранено полностью (14/14) | H7 |
-| Фаза 1 (5 пунктов) | сохранено; bash-пример (codesign/macOS) отброшен | Средо-специфичный; техника инструментации сохранена |
-| Ссылка на `root-cause-tracing.md` | заменено краткой версией (быстрая версия уже в источнике) | Sibling-файл не переносится |
-| Фаза 2 (4) | сохранено полностью | Ядро |
-| Фаза 3 (4) | сохранено полностью | Ядро |
-| Фаза 4 (5) | сохранено; `superpowers:test-driven-development` → жёсткая отсылка к test-driven-development (фикс только под падающий тест); верификация — `npm run check` | Спека §5.2 |
-| Red Flags (11) | сохранено полностью (11/11) | H7 |
-| «Signals You're Doing Wrong» (5) | сохранено полностью (5/5); human partner → владелец | H7 |
-| Common Rationalizations (8 строк) | сохранено полностью (8/8) | H7 |
-| Quick Reference | сохранено | Чеклист |
-| «No Root Cause» | сохранено; + `wolf add --type lesson` | Wolf-переплетение |
-| Supporting techniques (3 sibling-файла) | отброшено | Файлы каталога скилла не переносятся |
-| Related skills | сохранено; префикс superpowers: снят | Имена набора |
-| Real-World Impact | сохранено | Мотивация |
-
-Перенесённые списки: red flags 11/11, сигналы 5/5, рационализации 8/8, when-to-use 6/6 + особенно 5/5 + не-пропускать 3/3.
+Если подтверждены только симптомы, верни INCONCLUSIVE в отчёте: исследованное, отвергнутые гипотезы, недостающие данные и следующая проверка. Retry/timeout — осознанное mitigation с проверками и наблюдаемостью, а не доказательство отсутствия причины.

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

@@ -1,45 +1,26 @@
 ---
 name: wolf-design
-description: 'Вход: requirements.md (approved) + кодовая база. Выход: design.md — компоненты, контракты кодом (≤10 строк), псевдокод алгоритмов, ADR-карточки, глоссарий. Копипаста реализации запрещена.'
+description: "Проектируй решение по утверждённым требованиям: компоненты, контракты, потоки, риски и проверяемые решения. Используй при FULL или изменении интерфейсов, состояния, миграций и границ доверия."
 ---
 
-# wolf-design: design.md по requirements.md
+# Требования → дизайн
 
-## Обзор
+## Вход и выход
 
-Артефакт-конвейер Wolf: requirements.md (approved владельцем) → design.md.
-Скилл исполняется чистым воркером; диспетчеризация не меняется.
+Вход: approved requirements или утверждённый бриф, baseline SHA, существующая архитектура и профиль проекта. Выход: design.md с состоянием review, картой покрытия REQ/NFR и решениями для согласования. Автор — назначенный L1/L2; утверждение — по политике проекта через L0.
 
-## Вход
-
-- `docs/dev/<дата>-<slug>/requirements.md` со статусом `approved` (draft — стоп:
-  сначала гейт владельца/линз по wolf-review).
-- Кодовая база (чтение; file:line для контрактов).
-
-## Выход: design.md (в папке фичи)
-
-Секция заполняется поверх скелета из `wolf scaffold artifact`:
-
-1. **Глоссарий** — технические термины; термин вводится до использования.
-2. **Компоненты и ответственность** — имя — ответственность — файл.
-3. **Контракты** — типы, схемы, форматы событий блоками ≤ 10 строк; псевдокод
-   алгоритмов разрешён, когда точное описание делает дизайн однозначнее прозы.
-4. **ADR-карточки** — «Контекст → Решение → Последствия» ключевых решений.
-   ADR — продуктовые выборы: владелец визирует отдельно (список ADR — в отчёт).
-5. **Ссылки на NFR** — design ссылается на `NFR-NN` из requirements.md и добавляет
-   технические бюджеты; собственных ID-записей не заводит (двойное владение запрещено).
-
-## Железные запреты
+## Процесс
 
-- Копипаста реализации продукта в design.md запрещена (урок старых планов: ошибка
-  была не в наличии кода, а в наличии готовой реализации в документе планирования).
-- Переопределять требования: единственный источник AC — requirements.md.
-- Писать design.md до approved requirements.md.
+1. Проверь актуальность требований и прочитай код затронутых компонентов и потребителей. Ссылки задавай как revision:path:symbol; номера строк — дополнительный ориентир.
+2. Для каждого REQ/NFR укажи компонент, контракт, проверяемое свойство либо обоснованное «дизайн не требуется».
+3. Опиши ответственность компонентов, владение состоянием, границы интерфейсов, потоки данных и зависимостей. Для конкурентной работы задай инварианты и порядок записи.
+4. Контракты задавай типами/схемами достаточной длины; алгоритмы — псевдокодом, если проза допускает разные реализации. Не вставляй готовую реализацию продукта.
+5. Для существенного решения запиши ADR: контекст, альтернативы, выбор, последствия, риск, проверка допущения. Продуктовые компромиссы, scope и необратимые решения передай L0; локальные технические выборы оставь L1 в рамках мандата.
+6. Проверь отказ зависимостей, частичный сбой, retry/idempotency, восстановление, observability, совместимость и миграции. Для каждой неприменимой области достаточно обоснования.
+7. При работе с внешним контентом или исполнением команд опиши trust boundary, права, защиту секретов и validation. Не объявляй механизм реализованным только по наличию запрета в тексте.
+8. Укажи технические бюджеты NFR и способ измерения; предложи ограниченный spike для неопределённости, блокирующей выбор. Результат spike не становится реализацией автоматически.
+9. Передай design на wolf-review. Получи требуемые согласования и сохрани revision вердикта.
 
-## Процесс
+## Готовность и возврат
 
-1. Прочитать requirements.md целиком; каждый REQ/NFR должен иметь место в design
-   (компонент, контракт или осознанное «не требует дизайна»).
-2. Сверить контракты с кодом базлайна (file:line).
-3. Заполнить секции; front-matter `status: review`.
-4. Отчёт: список ADR-карточек (владельцу на визу) + открытые `[НЕОПРЕДЕЛЕНО: …]`.
+Каждое требование покрыто, контракты согласованы с baseline, критические допущения проверены или заблокированы. Утверждённый дизайн передай в wolf-plan и wolf-testplan. Изменение требования верни в discovery; изменение контракта инвалидирует зависимые задачи, тесты и ревью.

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

@@ -1,113 +1,25 @@
 ---
 name: wolf-execute
-description: 'Fallback-режим линейного исполнения плана без субагентов (FLAT): загрузи план, критически осмотрись, исполняй задачи батчами с чекпоинтами. Используй, когда диспетчеризация воркеров недоступна.'
+description: "Исполняй согласованный план линейно, когда разрешена исполнительская роль и диспетчеризация недоступна или не нужна. Сохраняй чекпоинты, evidence и независимую приёмку; L0 сам не исполняет."
 ---
 
-# wolf-execute: линейное исполнение плана (FLAT)
+# Линейное исполнение
 
-## Обзор
+## Вход и ограничения
 
-Загрузи план, критически его осмотрись, исполняй все задачи, отчитайся по завершении. Это FLAT-режим — без спавна воркеров, всё в одной сессии.
-
-**Анонс на старте:** «Использую скилл wolf-execute для исполнения этого плана».
-
-**Если доступны субагенты** — используй wolf-sdd вместо этого скилла: свежий воркер на задачу + двухстадийное ревью дают заметно более высокое качество. wolf-execute — fallback для платформ/сессий без диспетчеризации.
-
-wolf-execute — FLAT-fallback линейного исполнения для агентов без диспетчеризации;
-mr-wolf его не использует (правило роли `mem_20260903_..._e95317`). Вопрос о судьбе
-скилла — в backlog роадмапа, вне волны 2.15.
-
-## REQUIRED-предусловие: worktree
-
-**До старта исполнения worktree ОБЯЗАН существовать:** `.worktrees/<имя-задачи>` внутри проекта (правило проекта). Trunk-based: main — истина, работа идёт в ветке внутри worktree (см. скилл using-git-worktrees). Никогда не начинай исполнение в main без явного согласия владельца.
+Применять только исполнительской роли. Входы и TASK/RESULT/EVIDENCE — как в using-skills. Утверждённый FULL plan требует design и test-plan; LITE/FIX достаточно разрешённого брифа. Проверь workspace, профиль проекта, baseline и права на git. L0 передаёт работу executor, не использует fallback для обхода своей рамки.
 
 ## Процесс
 
-### Шаг 1: загрузи и осмотрись
-
-1. Прочитай файл плана
-2. Критическое ревью — определи вопросы и сомнения по плану
-3. Есть сомнения — подними их перед владельцем до старта
-4. Нет сомнений — заведи трекинг задач через {{tool.todowrite}} и продолжай
-
-Вход плана — трио `requirements.md` + `design.md` + `plan.md` в `docs/dev/<дата>-<slug>/`. Спека-монолит как вход плана не используется.
-
-Задачи плана — чекбоксы `- [ ]`: исполнитель переворачивает чекбокс в `[x]` в конце
-задачи вместе со строкой «сделано → коммит <hash>» — часть Definition of Done задачи.
-wolf-sdd — основной диспетчерский путь конвейера.
-
-### Шаг 2: исполняй задачи
-
-Для каждой задачи:
-
-1. Отметь in_progress
-2. Следуй каждому шагу точно (план состоит из bite-sized шагов)
-3. Запускай верификацию, как предписано планом; после завершённых блоков — `npm run check` (verification-примитив проекта)
-4. Отметь завершённой
-
-### Шаг 3: заверши разработку
-
-После всех задач и верификации:
-
-- Анонс: «Использую скилл finishing-a-development-branch для завершения работы»
-- **REQUIRED-СКИЛЛ:** finishing-a-development-branch
-- Следуй ему: верифицируй тесты, представь опции финала ветки, исполни выбор владельца
-- Валидация волны сверяется с `docs/dev/<дата>-<slug>/test-plan.md`: прогон сценариев — заготовки финальной проверки плана.
-
-## Когда остановиться и спросить
-
-**СТОП исполнения немедленно, когда:**
-
-- Ударился в блокер (нет зависимости, падает тест, инструкция непонятна)
-- В плане критические пробелы, мешающие стартовать
-- Ты не понимаешь инструкцию
-- Верификация падает повторно
-
-**Проси уточнения, а не угадывай.** Застрял — зафиксируй блокер в памяти (`wolf add --type blocker`) и поднимись к владельцу.
-
-## Когда вернуться к ранним шагам
-
-**Вернись к ревью (шаг 1), когда:**
-
-- Владелец обновил план по твоему фидбеку
-- Фундаментальный подход требует пересмотра
-
-**Не продавливай блокеры силой** — остановись и спроси.
-
-## Помни
-
-- Сначала критически осмотрись планом
-- Следуй шагам плана точно
-- Не пропускай верификации
-- Обращайся к скиллам, когда план говорит
-- Остановился — не угадывай, спроси
-- Никогда не начинай исполнение в main без явного согласия владельца
-
-## Интеграция
-
-**Обязательные скиллы воркфлоу:**
-
-- **using-git-worktrees** — REQUIRED: изолированный worktree `.worktrees/<имя-задачи>` ДО старта исполнения
-- **wolf-plan** — создаёт план, который этот скилл исполняет
-- **finishing-a-development-branch** — завершение разработки после всех задач
-
----
-
-## Трассировка адаптации
+1. Сверь входы с текущим кодом; обозначь несовместимость до правок. Зафиксируй зависимости и исходные падения проверок.
+2. Выполняй ready-задачи последовательно: прочитай затронутый код, пройди подходящую тестовую дисциплину, внеси allowlist-изменения, проверь результат и сохранённые инварианты.
+3. После каждой задачи запиши RESULT/evidence. Коммит выполняй только при разрешении роли и пользователя. Отметку [x] ставь после нужного ревью; до него сохрани состояние «готово к ревью» без выдуманного значения таксономии.
+4. Чекпоинт делай на завершённом компоненте, перед сменой этапа или сессии; default не более 3 небольших задач без сохранения состояния. В него включи baseline/current state, completed/remaining, evidence и dirty-state.
+5. Независимое ревью запроси через доступный разрешённый канал. Если его нет, сообщи ограничение и передай результат L0/владельцу; саморевью не выдавай за независимое.
+6. После интеграции выполни test-plan и полный применимый гейт; сформируй ACCEPTANCE. Дальнейший git-финал — finishing-a-development-branch.
 
-> Источник: `~/.config/opencode/superpowers/skills/executing-plans/SKILL.md`, upstream 6efe32c (2026-04-23)
+## Блокер и восстановление
 
-| Пункт источника                          | Судьба                                                          | Почему                                |
-| ---------------------------------------- | --------------------------------------------------------------- | ------------------------------------- |
-| Обзор (load → review → execute → report) | сохранено                                                       | Ядро                                  |
-| Note «subagents work better»             | заменено → wolf-sdd как приоритет, wolf-execute = FLAT-fallback | Спека §5.2 (FLAT-режим)               |
-| Упоминания платформ (Claude Code, Codex) | отброшено                                                       | Research §1: платформенные упоминания |
-| TodoWrite                                | заменено → `{{tool.todowrite}}`                                 | Research §1; плейсхолдер              |
-| Шаги 1–3                                 | сохранено; шаг 2 дополнен `npm run check`                       | Wolf-переплетение                     |
-| «When to Stop» (4)                       | сохранено полностью (4/4); + `wolf add --type blocker`          | H7 + Wolf                             |
-| «When to Revisit» (2)                    | сохранено полностью (2/2)                                       | H7                                    |
-| «Remember» (6)                           | сохранено полностью (6/6); main/master → trunk-based            | H7                                    |
-| Integration (worktrees REQUIRED)         | сохранено; H5-формулировка «до старта исполнения»               | H5; `.worktrees/<имя-задачи>`         |
-| —                                        | добавлено: REQUIRED-предусловие worktree (H5)                   | Спека §5.2                            |
+При недостатке контекста верни NEEDS_CONTEXT; при невозможности продолжения — BLOCKED с причиной, выполненным и безопасным следующим действием. Исправимые технические сбои исследуй wolf-debug, не спрашивая владельца на каждый локальный шаг. Изменение scope/контракта эскалируй.
 
-Перенесённые списки: Stop 4/4, Revisit 2/2, Remember 6/6.
+После прерывания сверяй план с фактическими файлами, git и evidence. Не повторяй миграции, публикации и внешние действия без проверки их исхода. По лимиту повторов (default 2) пересмотри подход. Недоступную запись памяти передай ответственному уровню.