mister-wolf 2.15.1 → 2.15.2

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

@@ -1,182 +1,31 @@
 ---
 name: wolf-brainstorm
-description: 'Обязателен до любой творческой работы — новых фич, компонентов, изменения поведения. Превращает идею в дизайн через диалог: вопросы по одному, варианты с трейд-оффами, аппрув владельца. Discovery-режим координатора.'
+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.
+Вход: запрос, действующие решения и ограничения, контекст существующего продукта. В FULL выход — requirements.md в папке docs/dev/<date>-<slug>/. В LITE — утверждённый короткий бриф. Владелец продукта — пользователь через L0; исследование может выполнять L1/L2 по мандату.
 
 ## Процесс
 
-**Понимание идеи:**
-
-- Сначала посмотри текущее состояние проекта (файлы, документация, недавние коммиты)
-- До детальных вопросов оцени масштаб: если запрос описывает несколько независимых подсистем (например, «платформа с чатом, хранилищем, биллингом и аналитикой») — сразу скажи об этом. Не трать вопросы на уточнение деталей проекта, который сначала нужно декомпозировать.
-- Если проект слишком велик для одной спеки — помоги владельцу разбить его на подпроекты: какие части независимы, как связаны, в каком порядке строить. Затем прогоняй первый подпроект через обычный флоу. Каждый подпроект получает свой цикл спека → план → реализация.
-- Для проектов подходящего масштаба задавай вопросы по одному
-- Предпочитай вопросы с вариантами ответа, но открытые тоже допустимы
-- Только один вопрос на сообщение — если тема требует глубины, разбей на несколько вопросов
-- Фокус на понимании: цель, ограничения, критерии успеха
-
-**Исследование подходов:**
-
-- Предложи 2–3 разных подхода с трейд-оффами
-- Представляй варианты разговорно, со своей рекомендацией и обоснованием
-- Веди с рекомендуемого варианта и объясни, почему именно он
-
-**Презентация дизайна:**
-
-- Когда понял, что строишь, — представь дизайн
-- Масштабируй каждую секцию под её сложность: несколько предложений для простого, до 200–300 слов для нюансированного
-- После каждой секции спрашивай, всё ли верно пока
-- Покрой: архитектуру, компоненты, поток данных, обработку ошибок, тестирование
-- Будь готов вернуться и уточнить, если что-то не сходится
-
-**Дизайн для изоляции и ясности:**
+1. Прочитай доступный контекст и зафиксируй известное. Раздели факт, допущение и вопрос. Не задавай вопрос, ответ на который уже есть.
+2. Сформулируй проблему, пользователя, решение, которое он сможет принять, и наблюдаемый успех. Предложи рамки задачи и не-цели.
+3. Запроси только ответы, меняющие scope, риск или критерии. Связанные вопросы можно объединять; предпочтения без существенных последствий решай самостоятельно и обозначай допущение.
+4. Если выбор реален, сравни 2–3 подхода, включая существующий механизм или отказ от изменения. Не придумывай альтернативы ради количества.
+5. Запиши требования: ID REQ/NFR, условие и поведение, обоснование, проверяемый AC, приоритет и источник. User story добавь, когда она объясняет потребность; для технического инварианта достаточно роли системы и цели. Неразрешённое пометь явно.
+6. Сверь атомарность, совместимость, отрицательные сценарии и метрику успеха. В FULL создай папку существующим wolf scaffold artifact, если доступен; иначе согласуй эквивалентный путь с L1.
+7. Передай владельцу единый пакет существенных решений. Если он уже утвердил именно эти требования, сохрани основание без повторного гейта. Не помечай approved при неподтверждённом scope.
+8. После утверждения передай в wolf-design. В LITE допустима непосредственная передача в исполнение с AC и проверками, если отдельный дизайн не нужен.
 
-- Дели систему на маленькие блоки, каждый с одной ясной целью, общающиеся через определённые интерфейсы, — понятные и тестируемые независимо
-- Для каждого блока отвечай: что он делает, как им пользоваться, от чего он зависит?
-- Можно ли понять блок, не читая его внутренности? Можно ли менять внутренности, не ломая потребителей? Если нет — границы требуют доработки.
-- Маленькие чётко очерченные блоки проще и для тебя: над кодом, который держится в контексте целиком, ты рассуждаешь лучше, а правки точечнее. Разросшийся файл — часто сигнал, что он делает слишком много.
-
-**Работа в существующей кодовой базе:**
-
-- Изучи текущую структуру до предложения правок. Следуй существующим паттернам.
-- Если существующий код мешает работе (файл разросся, границы размыты, ответственности перепутаны) — включи точечные улучшения в дизайн, как хороший разработчик, улучшающий код, в котором работает.
-- Не предлагай несвязанный рефакторинг. Фокус на том, что служит текущей цели.
-
-## Выход: requirements.md (v2 — анатомия §4.1 спеки конвейера)
-
-Диалог с владельцем завершается артефактом `docs/dev/<дата>-<slug>/requirements.md`.
-Папку создаёт `wolf scaffold artifact <slug>` — файлы артефактов вручную не создавать.
-
-Структура документа — 7 секций:
-
-1. Контекст и проблема — зачем, прозой, бизнес-языком; метрика успеха.
-2. Область — что входит; НЕ входит (не-цели уровня требований).
-3. Глоссарий — бизнес-термины фичи, если появились новые.
-4. Функциональные требования — записи REQ-NN.
-5. Нефункциональные (NFR-NN) — производительность, безопасность, совместимость;
-   каждая с измеримым критерием.
-6. Ограничения и допущения — что считаем данным.
-7. Журнал изменений (CR) — append-only: дата, затронутый REQ/NFR, что/почему,
-   кем утверждено, downstream-перегенерации.
-
-Анатомия записи (обязательные поля каждой записи REQ/NFR):
-
-- История: Как <роль>, я хочу <возможность>, чтобы <выгода>.
-- Требование: Когда <условие>, система должна <поведение>.
-- Обоснование: <зачем это бизнесу — словами владельца>.
-- AC: <измеримый критерий; нетривиальные — Given/When/Then>.
-- Приоритет: Must | Should | Could.
-- Источник: <диалог <дата> / жалоба mem-… / ревью-линза>.
-
-Критерии готовности записи (гейт линзы полноты; часть проверяет линт):
-одно требование — одна запись; есть история И формальная запись; есть AC
-(REQ без AC — находка линта); есть источник; неопределённость помечена
-`[НЕОПРЕДЕЛЕНО: вопрос]`, не сжата; владелец пересказывает требование своими
-словами — не может, это дефект требования, а не читателя.
-
-Язык: полные предложения, ноль сленга, термины домена без сокращений, новое
-понятие объясняется при первом употреблении, смысловое сжатие запрещено.
-
-## Второй режим: roadmap-триаж
-
-Диалог с владельцем по кандидатурам волн → вердикт по каждой: «волна N / бэклог /
-отклонено + причина». Запись — перемещением, не копированием (пункт живёт ровно
-в одном файле; дубль — находка линта doctor):
-
-- волна N → `docs/dev/roadmap/wave-N.md` (состав волны, источник вердикта);
-- бэклог → `docs/dev/roadmap/backlog.md`;
-- отклонено → `docs/dev/roadmap/rejected.md` (+ причина).
-
-## Ключевые принципы
-
-- **Один вопрос за раз** — не перегружай несколькими вопросами
-- **Предпочитай варианты ответа** — отвечать проще, чем на открытый вопрос
-- **Беспощадный YAGNI** — убирай ненужные фичи из всех дизайнов
-- **Исследуй альтернативы** — всегда 2–3 подхода до выбора
-- **Инкрементальная валидация** — представляй дизайн, получай аппрув, потом дальше
-- **Будь гибким** — возвращайся и уточняй, когда что-то не сходится
-
----
+## Готовность
 
-## Трассировка адаптации
+Понятны проблема, scope, AC и ограничения; существенные вопросы разрешены либо явно блокируют следующий этап. Техническую реализацию и код продукта здесь не пиши. Коммиты документа выполняет L1 по действующим полномочиям.
 
-> Источник: `~/.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 |
+Сохрани CR: что меняется, причина, затронутые ID, основание утверждения и downstream-артефакты. Верни design/plan/test-plan и связанные вердикты на перепроверку по влиянию. Не исправляй утверждённый AC незаметно.
 
-Перенесённые списки: анти-паттерны 1/1, принципы 6/6, саморевью 4/4.
+Roadmap-триаж отделяй от требований фичи: кандидат имеет один основной статус и место, источник решения и причину отклонения/отложения.

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; изменение контракта инвалидирует зависимые задачи, тесты и ревью.