mister-wolf 2.15.0 → 2.15.2

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

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

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

@@ -1,39 +1,23 @@
 ---
 name: receiving-code-review
-description: 'Фидбек владельца и ревью-линз: высший приоритет лестницы, но не слепое внедрение — техническая строгость, проверка возражений, протокол несогласия.'
+description: "Разбирай замечания пользователя или ревьюера: проверь основание, ответь на каждый пункт, исправь подтверждённый дефект и повтори затронутые проверки. Не принимай и не отвергай фидбек без evidence."
 ---
 
-# receiving-code-review: приём фидбека
-
-## Обзор
-
-Фидбек владельца = высший приоритет лестницы приоритетов. Но «внедри совет» — не
-поведение по умолчанию: ревью может быть технически неверным.
+# Обработка ревью
 
 ## Процесс
 
-1. Прочитать фидбек целиком; классифицировать каждый пункт: факт-исправление /
-   вопрос / возражение.
-2. Согласен → внедрить + коммит + строка «что исправлено» в отчёт.
-3. Сомневаешься → проверить по коду/документу ДО ответа; возражение обосновать
-   пруфом (file:line), не мнением.
-4. Фидбек противоречит памяти Wolf/рамке → по лестнице приоритетов (память выше
-   скиллов); расхождение правил → жалоба по протоколу жалоб, не самовольная
-   правка правила.
-5. Уроки фидбека (воспроизводимый паттерн ошибки) → `wolf add --type lesson`.
+1. Прочитай весь набор; различи исправление факта, вопрос, дефект, предпочтение и изменение требований. Свяжи с finding_id; если его нет, создай локальный идентификатор ответа.
+2. Проверь воспроизводимость по исходным требованиям, коду и evidence. Ответ на каждый пункт: ACCEPTED, REFUTED, DEFERRED или NEEDS_CLARIFICATION; добавь основание и действие. Эти метки — отчёт, не типы памяти.
+3. Подтверждённый Critical/Major исправь до приёмки; Minor назначь или отложи с причиной. Пользовательское указание о цели имеет приоритет; техническую неверность рекомендации объясни и предложи способ достичь цели.
+4. Изменение AC/scope проведи через CR и L0; не переписывай контракт, чтобы обойти находку. Конфликт действующих методик передай жалобным контуром, но не останавливай независимую полезную работу без необходимости.
+5. Правь минимально; проверки выбери по влиянию. Коммиты делает роль с действующим разрешением. Зафиксируй revision исправления, evidence и незакрытые риски.
+6. Запроси повторное ревью affected mandates. Отсутствие ответа ревьюера не означает одобрения; лимит циклов заканчивается явной эскалацией.
 
-## Запреты
+## Память
 
-- Перформативное согласие без проверки.
-- Внедрение совета вслепую при явном техническом возражении.
-- Тихое игнорирование пункта фидбека.
+Наблюдение о конкретной незавершённой работе фиксируй задачей/заметкой; обобщаемый повторяемый паттерн — lesson с областью применимости и evidence. Не создавай правило из каждого комментария. Недоступную запись передай L1; не обходи permissions.
 
-## Трассировка адаптации
+## Запреты
 
-| Пункт источника (superpowers receiving-code-review) | Судьба                                           | Почему            |
-| --------------------------------------------------- | ------------------------------------------------ | ----------------- |
-| Техническая строгость, не перформативное согласие   | сохранено                                        | ядро              |
-| Проверка перед внедрением                           | сохранено                                        | ядро              |
-| «Совет может быть неверным»                         | сохранено                                        | ядро              |
-| —                                                   | добавлено: лестница приоритетов + протокол жалоб | Wolf-переплетение |
-| —                                                   | добавлено: уроки фидбека → память Wolf           | самообучение      |
+Не изображай согласие без проверки, не игнорируй пункт молча, не превращай ревью в бесконечный косметический цикл. Техническое возражение подкрепи проверяемым основанием, а не уверенностью.

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

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