mister-wolf 1.0.3 → 1.1.0

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

@@ -0,0 +1,293 @@
+---
+name: wolf-debug
+description: "Используй при любом баге, падении теста или неожиданном поведении — ДО предложения фиксов. 4 фазы root-cause: исследование причины → анализ паттернов → гипотеза и тест → реализация фикса под падающий тест."
+---
+
+# wolf-debug: систематический дебаг
+
+## Обзор
+
+Случайные фиксы тратят время и порождают новые баги. Быстрые заплатки маскируют лежащие под ними проблемы.
+
+**Ядро принципа:** ВСЕГДА находи корневую причину до попыток фикса. Фикс симптома — это провал.
+
+**Нарушение буквы этого процесса — нарушение духа дебага.**
+
+## Железный закон
+
+```
+НИКАКИХ ФИКСОВ БЕЗ ИССЛЕДОВАНИЯ КОРНЕВОЙ ПРИЧИНЫ
+```
+
+Если ты не завершил фазу 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.

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

@@ -0,0 +1,96 @@
+---
+name: wolf-execute
+description: "Fallback-режим линейного исполнения плана без субагентов (FLAT): загрузи план, критически осмотрись, исполняй задачи батчами с чекпоинтами. Используй, когда диспетчеризация воркеров недоступна."
+---
+
+# wolf-execute: линейное исполнение плана (FLAT)
+
+## Обзор
+
+Загрузи план, критически его осмотрись, исполняй все задачи, отчитайся по завершении. Это FLAT-режим — без спавна воркеров, всё в одной сессии.
+
+**Анонс на старте:** «Использую скилл wolf-execute для исполнения этого плана».
+
+**Если доступны субагенты** — используй wolf-sdd вместо этого скилла: свежий воркер на задачу + двухстадийное ревью дают заметно более высокое качество. wolf-execute — fallback для платформ/сессий без диспетчеризации.
+
+## REQUIRED-предусловие: worktree
+
+**До старта исполнения worktree ОБЯЗАН существовать:** `.worktrees/<имя-задачи>` внутри проекта (правило проекта). Trunk-based: main — истина, работа идёт в ветке внутри worktree (см. скилл using-git-worktrees). Никогда не начинай исполнение в main без явного согласия владельца.
+
+## Процесс
+
+### Шаг 1: загрузи и осмотрись
+1. Прочитай файл плана
+2. Критическое ревью — определи вопросы и сомнения по плану
+3. Есть сомнения — подними их перед владельцем до старта
+4. Нет сомнений — заведи трекинг задач через {{tool.todowrite}} и продолжай
+
+### Шаг 2: исполняй задачи
+
+Для каждой задачи:
+1. Отметь in_progress
+2. Следуй каждому шагу точно (план состоит из bite-sized шагов)
+3. Запускай верификацию, как предписано планом; после завершённых блоков — `npm run check` (verification-примитив проекта)
+4. Отметь завершённой
+
+### Шаг 3: заверши разработку
+
+После всех задач и верификации:
+- Анонс: «Использую скилл finishing-a-development-branch для завершения работы»
+- **REQUIRED-СКИЛЛ:** finishing-a-development-branch
+- Следуй ему: верифицируй тесты, представь опции финала ветки, исполни выбор владельца
+
+## Когда остановиться и спросить
+
+**СТОП исполнения немедленно, когда:**
+- Ударился в блокер (нет зависимости, падает тест, инструкция непонятна)
+- В плане критические пробелы, мешающие стартовать
+- Ты не понимаешь инструкцию
+- Верификация падает повторно
+
+**Проси уточнения, а не угадывай.** Застрял — зафиксируй блокер в памяти (`wolf add --type blocker`) и поднимись к владельцу.
+
+## Когда вернуться к ранним шагам
+
+**Вернись к ревью (шаг 1), когда:**
+- Владелец обновил план по твоему фидбеку
+- Фундаментальный подход требует пересмотра
+
+**Не продавливай блокеры силой** — остановись и спроси.
+
+## Помни
+
+- Сначала критически осмотрись планом
+- Следуй шагам плана точно
+- Не пропускай верификации
+- Обращайся к скиллам, когда план говорит
+- Остановился — не угадывай, спроси
+- Никогда не начинай исполнение в main без явного согласия владельца
+
+## Интеграция
+
+**Обязательные скиллы воркфлоу:**
+- **using-git-worktrees** — REQUIRED: изолированный worktree `.worktrees/<имя-задачи>` ДО старта исполнения
+- **wolf-plan** — создаёт план, который этот скилл исполняет
+- **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 |
+
+Перенесённые списки: Stop 4/4, Revisit 2/2, Remember 6/6.

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

@@ -0,0 +1,101 @@
+---
+name: wolf-handoff
+description: "Используй, когда текущая сессия перегружена контекстом, обросла ошибками, дрейфует или работу нужно продолжить в свежей сессии без потери прогресса. Экономика тёплых/холодных сессий: значимое — в память Wolf, продолжение — свежему субагенту."
+---
+
+# wolf-handoff: передача в свежую сессию
+
+## Обзор
+
+Когда контекст перегружен, сессия обросла ошибками или впереди много шагов — запиши сжатое резюме handoff и продолжи работу в свежем субагенте через {{tool.task}}.
+
+**Экономика тёплых/холодных сессий:** тёплая сессия дорожает с каждым токеном истории; холодная стартует дёшево, но не знает ничего. Память Wolf ломает этот компромисс: сначала зафиксируй значимое в памяти (`wolf add` — решения, уроки, блокеры), затем передай минимум — свежая сессия подтянет состояние сама (`wolf call` + `wolf brief` на холодном старте).
+
+## Когда использовать
+
+- Окно контекста заполняется или сессия дрейфует
+- Переключение с исследования на реализацию
+- Нужно сбросить якорь после серии неудачных попыток
+- У задачи несколько оставшихся независимых шагов
+- Ты сам запущен как субагент и тебе нужно делегировать дальше
+
+## Шаги
+
+1. **Зафиксируй значимое в памяти Wolf.** До передачи:
+   - Решения и их обоснование → `wolf add --type decision`
+   - Уроки (что сработало / что нет) → `wolf add --type lesson`
+   - Открытые блокеры → `wolf add --type blocker`
+   Преемник получит их через `wolf call` / `wolf brief` — дублировать в промпте не нужно.
+
+2. **Запиши резюме handoff.** Включи:
+   - Что сделано
+   - Что осталось
+   - Ключевые решения и их логика (ссылками на объекты памяти)
+   - Релевантные пути файлов, URL, ссылки на issues/PR
+   - Какие скиллы преемнику стоит задействовать
+   - Отметку о редактированных секретах, API-ключах, токенах, PII
+
+3. **Запусти свежий субагент через {{tool.task}}.**
+   - `description`: короткое описательное имя задачи
+   - `subagent_type`: роль преемника — исполнительская роль проекта (например, worker-implementer для реализации, worker-researcher для исследования; координация — через executor-lead)
+   - `prompt`: резюме handoff
+
+4. **Отчитайся владельцу: ID и статус задачи субагента.**
+
+## Пример
+
+Резюме handoff:
+- Решили оставить публикацию v9-сигналов в `adviser/` (решение: mem от 2026-08-30).
+- Реализован `adviser/src/publishers/signal_v9.py`.
+- Осталось: подключить в DI-контейнер `adviser/services/di.py` и добавить тесты.
+- Файлы: `adviser/src/publishers/signal_v9.py`, `adviser/services/di.py`.
+- Скиллы преемнику: test-driven-development, verification-before-completion.
+
+Затем диспетчеризация:
+```
+{{tool.task}}
+  description: Подключить v9-паблишер в DI и тесты
+  subagent_type: worker-implementer
+  prompt: <резюме handoff>
+```
+
+## Что включить
+
+- Конкретные пути файлов и имена символов
+- Принятые решения и почему (или ссылки на них в памяти)
+- Открытые вопросы и блокеры
+- Релевантные тесты, команды, шаги верификации
+
+## Что исключить
+
+- Длинные транскрипты и полные листинги кода
+- Секреты, учётные данные, персональные данные
+- Контент, уже зафиксированный в артефактах (планы, спеки, коммиты, диффы, память Wolf)
+
+## Red Flags
+
+- Передача без письменного резюме
+- Копирование всей беседы в промпт субагента
+- Включение API-ключей или токенов
+- «Кажется» и размытые следующие шаги вместо исполнимых задач
+
+---
+
+## Трассировка адаптации
+
+> Источник: `~/.config/opencode/superpowers/skills/opencode-handoff/SKILL.md`, upstream 6efe32c (2026-04-23)
+
+| Пункт источника | Судьба | Почему |
+|---|---|---|
+| Обзор (перегрузка → свежий субагент) | сохранено + экономика тёплых/холодных сессий | Спека §5.2 |
+| Тула `task` с `subagent_type` | заменено → `{{tool.task}}` (subagent_type сохранён как параметр) | Research §1: opencode-тул; плейсхолдер |
+| When to Use (5) | сохранено полностью (5/5) | H7 |
+| Шаги (3) | сохранено; + шаг 0 «зафиксируй в памяти Wolf» (`wolf add`) | Wolf-переплетение |
+| `subagent_type: general/explore` | заменено → роли проекта (worker-implementer / worker-researcher / executor-lead) | Generic-типы не переносимы |
+| Пример | адаптировано (тип → worker-implementer, ссылка на объект памяти) | Иллюстрация |
+| What to Include (4) | сохранено полностью (4/4); + память как артефакт | H7 |
+| What to Exclude (3) | сохранено полностью (3/3); + «память Wolf» | H7 |
+| Red Flags (4) | сохранено полностью (4/4) | H7 |
+| — | добавлено: холодный старт преемника — `wolf call` + `wolf brief` | Протокол проекта |
+
+Перенесённые списки: red flags 4/4, include 4/4, exclude 3/3, when-to-use 5/5.