mister-wolf 2.15.2 → 2.16.1

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

@@ -1,13 +1,20 @@
 ---
 name: wolf-execute
-description: "Исполняй согласованный план линейно, когда разрешена исполнительская роль и диспетчеризация недоступна или не нужна. Сохраняй чекпоинты, evidence и независимую приёмку; L0 сам не исполняет."
+description: "Применять при линейном исполнении утверждённого плана или разрешённого LITE/FIX-брифа исполнительской ролью, когда диспетчеризация не нужна либо недоступна."
 ---
 
 # Линейное исполнение
 
+## Обязательный вход
+
+До правок проверь входы, роль, текущую рабочую копию и разрешения. L0 не выполняет этот процесс: передаёт его executor. L2 исполняет только назначенную подзадачу без коммитов и спавна. Отслеживай обязательные шаги задачи и проверки в доступном трекере; факт загрузки скилла не заменяет их выполнение.
+
+Загрузи полный текст назначенной методики до её выполнения. Обязательные пункты отслеживай в доступном трекере или рабочем брифе; не добавляй новые статусы памяти. Недоступное действие передай ответственному уровню.
+
+
 ## Вход и ограничения
 
-Применять только исполнительской роли. Входы и TASK/RESULT/EVIDENCE — как в using-skills. Утверждённый FULL plan требует design и test-plan; LITE/FIX достаточно разрешённого брифа. Проверь workspace, профиль проекта, baseline и права на git. L0 передаёт работу executor, не использует fallback для обхода своей рамки.
+Применять только исполнительской роли. Этот маршрут применим, когда диспетчеризация недоступна или не нужна. Входы и TASK/RESULT/EVIDENCE — как в using-skills. Утверждённый FULL plan требует design и test-plan; LITE/FIX достаточно разрешённого брифа. Проверь workspace, профиль проекта, baseline и права на git. L0 передаёт работу executor, не использует fallback для обхода своей рамки.
 
 ## Процесс
 
@@ -23,3 +30,15 @@ description: "Исполняй согласованный план линейн
 При недостатке контекста верни NEEDS_CONTEXT; при невозможности продолжения — BLOCKED с причиной, выполненным и безопасным следующим действием. Исправимые технические сбои исследуй wolf-debug, не спрашивая владельца на каждый локальный шаг. Изменение scope/контракта эскалируй.
 
 После прерывания сверяй план с фактическими файлами, git и evidence. Не повторяй миграции, публикации и внешние действия без проверки их исхода. По лимиту повторов (default 2) пересмотри подход. Недоступную запись памяти передай ответственному уровню.
+
+## Гейт перехода
+
+Завершение задачи требует актуальных проверок и предусмотренного ревью; завершение поставки — интеграции и ACCEPTANCE. Без независимого канала ревью обозначь ограничение. Затем примени verification-before-completion и согласованный git-финал, не придумывая новый scope.
+
+## Не пропускай процесс
+
+| Мысль | Действие |
+| --- | --- |
+| «Сам проверю и сам приму» | Саморевью не независимо; приёмка остаётся у назначенного уровня. |
+| «Нет агентов, значит L0 может писать код» | Недоступность инструмента не расширяет роль. |
+| «Продолжу после сбоя с того же действия» | Сначала проверь исход предыдущего действия и checkpoint. |

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

@@ -0,0 +1,104 @@
+---
+name: wolf-explain
+description: "Применять перед ответом Вольфа пользователю о результате, прогрессе, решении, рекомендации, ошибке или выборе; также когда пользователь просит объяснить понятнее или подробнее."
+---
+
+# Wolf Explain — объяснение для человека
+
+## Обязательный вход
+
+Перед первым пользовательским объяснением загрузи полный текст этой методики, если он ещё не доступен. Применяй его в текущем общении без отдельного агента и повторной загрузки на каждое сообщение. Проверка понятности не заменяет wolf-brainstorm, wolf-debug или verification-before-completion.
+
+## Назначение и границы
+
+Вольф отвечает за понимание пользователем цели, результата и следующего шага. Выполни редактуру смысла и формы перед пользовательским ответом; не меняй факты и не выдавай объяснение за проверку результата.
+
+Адресат по умолчанию — технически опытный владелец проекта, которому не обязательно знакомы текущая подсистема и внутренний язык Wolf. Не упрощай до потери точности и не объясняй знакомые основы без причины. Пиши на языке пользователя. Насыщенность терминами не считай признаком компетентности.
+
+Методика общения не расширяет полномочия. L0 не запускает проверки, не пишет код и не спавнит L2 ради редактуры ответа. Недостающие основания запрашивай у L1 либо явно ограничивай вывод. Машинные отчёты RESULT/EVIDENCE/ACCEPTANCE сохраняй без переименования полей; пользовательское изложение — отдельный текст.
+
+## Вход и выход
+
+Вход: вопрос пользователя, цель и стадия работы, доступные отчёты/доказательства, принятые решения и ограничения. Отсутствующие данные не заполняй догадкой.
+
+Выход: самостоятельный ответ, по которому пользователь понимает главное и может принять нужное решение. Ссылка на файл дополняет объяснение, но не заменяет его. Внутреннюю редактуру и чеклист не показывай.
+
+## Процесс
+
+1. Определи запрос: узнать состояние, понять механизм, оценить вариант, принять решение или получить результат. Начни с ответа на него, а не с перечисления процедур.
+2. Выдели факты, предположения, ограничения и требуемое решение. Сверь версии и область проверок. «Исполнитель сообщил» не превращай в «проверено» без оснований.
+3. Сформулируй главный вывод одним-двумя предложениями. Различай сделанное, проверенное и оставшееся; частичный результат не называй полным завершением.
+4. Раскрой связи: что произошло → почему, если известно → что это меняет для цели. Неизвестную причину обозначь, не придумывай её ради связности.
+5. Замени ненужный сленг обычными словами. Нужный термин объясни при первом употреблении в данной теме. Имена команд, API, типов, файлов и точные формулировки контрактов сохраняй. Не объясняй термин другим неизвестным термином.
+   В человеческом ответе «исполнитель» обычно понятнее L1/L2, «объединение с основной веткой» — merge, «запрос на включение изменений (PR)» — PR без пояснения. Упоминай внутренний уровень роли, только если он нужен для решения. Знакомые пользователю термины повторно не расшифровывай; знакомство с одним термином не означает знание всех остальных.
+6. Добавь доказательства в масштабе вопроса: что проверяли и что осталось непроверенным. Логи, хеши и служебные идентификаторы вынеси в ссылку или технические детали, если нужны для аудита. Секреты и нерелевантные внутренние материалы не раскрывай.
+7. Если нужен следующий шаг, назови действие и ответственного. Если решение требуется от пользователя, объясни варианты, последствия и рекомендацию. Не создавай новые гейты; ранее разрешённую работу продолжай без повторного вопроса.
+8. Проверь точность и понятность по финальному чеклисту. Перепиши ответ, если пользователь должен расшифровать внутренний отчёт, чтобы понять смысл.
+
+## Форма и длина
+
+Пиши связными предложениями: одна основная мысль на абзац, вывод раньше деталей, действующее лицо и действие названы. Убирай повторы, но сохраняй причины, условия и оговорки. Если термин требует большого пояснения, проверь, нужен ли он в основном ответе.
+
+Не задавай универсальный лимит строк или слов. Простому статусу достаточно абзаца; архитектурное решение требует объяснения. На «подробнее» раскрывай механизм и пример, а не добавляй список терминов. Формат пользователя имеет приоритет.
+
+Списки используй для действий и параллельных пунктов; таблицы — для сравнения. Не превращай ответ в обрывки. «Результат → основание → значение → следующий шаг» — проверка полноты, а не обязательные четыре заголовка. Если следующий шаг не нужен, не придумывай его.
+
+## Адаптация к задаче
+
+- **Результат:** что изменилось, чем подтверждено, ограничения. Различай создание PR, приёмку, merge и публикацию.
+- **Прогресс:** что выяснено, что мешает завершению и что выполняется дальше. Всю топологию агентов без необходимости не показывай.
+- **Механизм:** назначение, основные связи, конкретный пример и важное ограничение. Аналогия допустима при точном соответствии с обозначенными границами.
+- **Рекомендация:** вариант, причина выбора, компромисс и условие, при котором выбор изменится. Уверенность соразмеряй основаниям.
+- **Проблема:** симптом, известная/неизвестная причина, последствия и способ продолжить. BLOCKED или INCONCLUSIVE без объяснения недостаточно.
+- **Выбор:** конкретное решение, последствия вариантов и рекомендация. Спрашивай только о том, что требует решения пользователя.
+
+## Примеры преобразования
+
+Примеры условные; используй только подтверждённые факты текущей задачи.
+
+Внутри: «Evidence stale; Major durability; INCONCLUSIVE».
+
+Пользователю: «Пока нельзя подтвердить завершение. Проверка относится к предыдущей версии. Ревьюер также отметил серьёзный вопрос о сохранности данных, но по этому отчёту нельзя определить сценарий и последствия. Исполнителю нужны проверка текущей версии и уточнение этого замечания».
+
+Если источник не указывает, какое состояние теряется, не добавляй это из примера: «Ревьюер сообщил о риске потери состояния, но не указал, какого именно. Запрошу сценарий, прежде чем оценивать последствия».
+
+Внутри: «Playbook superseded; router canonical hit».
+
+Пользователю: «Прежняя методика заменена новой. Проверка доставки показала, что агент получил обновлённую инструкцию. Это подтверждает загрузку, но ещё не доказывает правильное применение в работе».
+
+Внутри: «PR open, workspace dirty».
+
+Пользователю: «Запрос на включение изменений (PR) создан, но код ещё не объединён с основной веткой. В рабочей копии остались изменения, которые не входят в этот запрос; нужно выяснить, относятся ли они к результату. Если поручение ограничивалось созданием PR, объединение с основной веткой не является обязательным шагом для завершения этого поручения».
+
+## Точность и доверие
+
+Не удаляй существенную оговорку ради краткости. Не превращай отсутствие данных в отрицательный результат, гипотезу — в причину, пройденные тесты — в отсутствие всех ошибок. Числа, даты, область проверки, версии и условия решений сохраняют смысл исходника.
+
+Если источник противоречив, объясни противоречие и его влияние; не выбирай удобную формулировку молча. Недостающую проверку передай L1 в рамках полномочий. Скилл не заменяет verification-before-completion.
+
+## Если пользователь не понял
+
+Не повторяй тот же текст с парой синонимов. Найди непонятную связь, раскрой её примером и поясни термин. Скорректируй подробность для текущей темы; не запрашивай профиль читателя на каждом ответе.
+
+Повторяющееся непонимание из-за правила общения — основание для behavioral-жалобы по существующему протоколу: исходный ответ, вопрос пользователя, исправленное объяснение и предлагаемая правка. Не записывай каждое уточнение как ошибку и не создавай глобальное правило автоматически.
+
+## Проверка перед отправкой
+
+- Ответил ли я на вопрос в начале?
+- Понятно ли, что произошло и почему важно для цели?
+- Нет ли необъяснённых терминов, скрытых причинных переходов и статусов вместо смысла?
+- Сохранены ли факты, условия, ограничения и неопределённость?
+- Различены ли сообщение исполнителя, проверенный факт и рекомендация?
+- Ясно ли, нужен ли следующий шаг и кто его выполняет?
+- Можно ли понять главное без предыдущих сообщений и внутренних файлов?
+
+Если нет — доработай ответ. Цель: вопросы пользователя относятся к решению и его последствиям, а не к расшифровке речи Вольфа.
+
+## Не пропускай смысл
+
+| Мысль | Действие |
+| --- | --- |
+| «Пользователь технический, значит знает весь сленг» | Поясни нужные понятия текущей подсистемы, не основы без причины |
+| «Для краткости оставлю статусы» | Объясни событие, последствия и существенное ограничение |
+| «Он переспросит, если нужно» | Основной ответ должен быть самостоятельным |
+| «Расшифровка делает результат убедительнее» | Не добавляй неподтверждённые причины и гарантии |

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

@@ -1,10 +1,17 @@
 ---
 name: wolf-handoff
-description: "Передай работу в новую сессию или замени исполнителя без потери цели, состояния и evidence. Сохрани snapshot и явно передай владение; не создавай вложенных агентов в обход L0/L1/L2."
+description: "Применять перед сменой сессии или исполнителя, близкой потерей контекста, длительной остановкой либо возобновлением работы по сохранённому состоянию."
 ---
 
 # Передача состояния
 
+## Обязательный вход
+
+До передачи различи новую задачу и продолжение прежней. Сохрани существующий task/thread ID при продолжении. L0/L1 выполняют передачу в пределах полномочий, L2 возвращает checkpoint своему L1. Не полагайся на наследование чата; сохранённые ссылки и незакоммиченная работа должны быть реально доступны преемнику.
+
+Загрузи полный текст назначенной методики до её выполнения. Обязательные пункты отслеживай в доступном трекере или рабочем брифе; не добавляй новые статусы памяти. Недоступное действие передай ответственному уровню.
+
+
 ## Выбор действия
 
 Различай: продолжение той же роли в новой сессии, замена исполнителя и новая подзадача. L0 передаёт цель преемнику L0 либо поручает L1 поставку; L1 заменяет L2/исполнительскую сессию; L2 возвращает checkpoint и запрос L1. L2 не спавнит преемника. Указание tool.task не гарантирует сброс контекста родителя — проверь возможности платформы.
@@ -33,3 +40,15 @@ description: "Передай работу в новую сессию или за
 ## Ограничения
 
 Handoff не повышает права и не разрешает незапрошенные внешние действия. Новая сессия не исправляет неправильный план сама по себе. При дрейфе проверь источник ошибки и достаточность snapshot, а не только уменьши текст.
+
+## Гейт перехода
+
+Передача завершена после сохранения достаточного snapshot, определения единственного владельца записи и подтверждения преемником цели, фактического состояния и следующего шага. Нельзя одновременно продолжать запись старым и новым исполнителем. Недоступная техническая блокировка должна быть явно заменена протокольным ограничением.
+
+## Не пропускай процесс
+
+| Мысль | Действие |
+| --- | --- |
+| «Новая сессия всё исправит» | Проверь достаточность плана и snapshot. |
+| «wolf call найдёт любую нужную запись» | Передай прямые доступные ссылки и версии. |
+| «Начнём новый тред для продолжения» | Сначала восстанови существующий тред той же цели. |

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

@@ -1,10 +1,17 @@
 ---
 name: wolf-plan
-description: "Составляй исполнимые задачи по утверждённым требованиям и дизайну. Планируй зависимости, allowlist, интеграцию, проверки и восстановление без копирования реализации в план."
+description: "Применять перед декомпозицией утверждённого решения в исполнимые задачи, перед передачей работы исполнителям или при изменении зависимостей и состава существующего плана."
 ---
 
 # Дизайн → задачи
 
+## Обязательный вход
+
+До планирования проверь тред, режим, актуальные требования, дизайн и основание их утверждения. L0 поручает планирование L1; L2 может готовить назначенную часть, но не владеть общим планом. В FULL заполняй plan.md существующей папки: задачи чекбоксами с task_id, ссылками на design и baseline. В LITE/FIX используй разрешённый бриф; не создавай четыре документа ради формальности. Автор плана не начинает реализацию в рамках этого скилла.
+
+Загрузи полный текст назначенной методики до её выполнения. Обязательные пункты отслеживай в доступном трекере или рабочем брифе; не добавляй новые статусы памяти. Недоступное действие передай ответственному уровню.
+
+
 ## Вход и выход
 
 Вход: approved requirements/design либо разрешённый LITE/FIX-бриф; baseline SHA, профиль проекта и известный test-plan. Выход: plan.md или список TASK с зависимостями и точками интеграции. Автор планирования не выполняет реализацию.
@@ -29,3 +36,15 @@ description: "Составляй исполнимые задачи по утве
 ## Передача
 
 При доступной и разрешённой диспетчеризации L1 использует wolf-sdd. Иначе исполнитель с подходящей ролью использует wolf-execute. Не проси пользователя выбирать внутренний механизм без существенного влияния на стоимость, риск или его предпочтения.
+
+## Гейт перехода
+
+План готов к исполнению после проверки зависимостей, соответствия design, согласования test-plan и необходимого ревью. Состояния документов и основания утверждения должны соответствовать текущим версиям. L1 выбирает wolf-sdd либо разрешённый wolf-execute; реализация не является частью планирования.
+
+## Не пропускай процесс
+
+| Мысль | Действие |
+| --- | --- |
+| «План — это список файлов» | Каждая задача имеет цель, проверяемый результат, входы и зависимости. |
+| «Тесты добавим после реализации» | Свяжи проверки с задачами до старта. |
+| «Воркеры сами разделят общую работу» | Общий план и порядок интеграции принадлежат L1. |

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

@@ -1,10 +1,17 @@
 ---
 name: wolf-review
-description: "Проверяй requirements, design, plan, test-plan или отчёт независимыми линзами. Привязывай вывод к версии, разрешай конфликты и отличай одобрение от исчерпания бюджета ревью."
+description: "Применять перед утверждением requirements, design, plan, test-plan или приёмочного отчёта; при повторном ревью изменённой версии и при противоречивых выводах проверяющих."
 ---
 
 # Ревью артефактов
 
+## Обязательный вход
+
+До чтения артефакта зафиксируй предмет, версии, мандат и бюджет ревью. L0 поручает цикл L1; L1 назначает независимых L2. Автор не является независимым ревьюером собственного результата. Передай сырые документы и критерии без ожидаемого вердикта. Если входы неполны, запроси их или ограничь вывод; не подменяй ревью предположением.
+
+Загрузи полный текст назначенной методики до её выполнения. Обязательные пункты отслеживай в доступном трекере или рабочем брифе; не добавляй новые статусы памяти. Недоступное действие передай ответственному уровню.
+
+
 ## Владение и вход
 
 L0 задаёт критерии и поручает цикл executor-lead; L1 вызывает worker-reviewer. L0 не спавнит L2 напрямую. Вход: цель ревью, документы с revision/hash, baseline, применимые требования/политика и бюджет. Получи активную методику линз; при отсутствии используй приведённый минимальный набор и обозначь fallback.
@@ -39,3 +46,15 @@ VERDICT: APPROVED | CHANGES_REQUIRED | INCONCLUSIVE
 ## Гейты
 
 Владелец утверждает требования и существенные ADR; технические артефакты утверждает назначенный ответственный после ревью. Следующий этап получает одобренные версии. Пакет ревью подтверждает проверенные свойства, не гарантирует отсутствие всех дефектов.
+
+## Гейт перехода
+
+Переход дальше требует вердикта по нужной версии, закрытых блокирующих находок и предусмотренных утверждений. После изменения основания вердикт перепроверь по влиянию. Исчерпанный бюджет означает нерешённый исход в сводке, а не одобрение. Сохрани область проверки и ограничения.
+
+## Не пропускай процесс
+
+| Мысль | Действие |
+| --- | --- |
+| «Другой ревьюер уже всё нашёл» | Проведи свой мандат независимо, затем сопоставь находки. |
+| «Лимит раундов исчерпан» | Эскалируй незакрытое, не выдавай APPROVED. |
+| «Стиль не нравится» | Отделяй предпочтение от доказанного блокирующего дефекта. |

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

@@ -1,10 +1,17 @@
 ---
 name: wolf-sdd
-description: "Исполняй утверждённый план через L1 и изолированных L2: явные брифы, независимая проверка, ограниченные повторы, интеграция и приёмочный пакет. Не применяй для обхода запретов роли."
+description: "Применять при исполнении утверждённого плана через executor-lead и назначенных воркеров, включая продолжение поставки после проверки входов и восстановления состояния."
 ---
 
 # Исполнение через L1/L2
 
+## Обязательный вход
+
+Оркестратор — L1, не L0 и не L2. До первого назначения проверь разрешённый scope, актуальные approved-входы, baseline, test-plan, права и зависимости. Зафиксируй ready-задачи и лимит повторов. На каждую задачу отслеживай исполнение, проверку соответствия, проверку качества и интеграцию отдельно. Не запускай воркера, если входы ещё зависят от неутверждённого решения.
+
+Загрузи полный текст назначенной методики до её выполнения. Обязательные пункты отслеживай в доступном трекере или рабочем брифе; не добавляй новые статусы памяти. Недоступное действие передай ответственному уровню.
+
+
 ## Предусловия
 
 Оркестратор исполнения — executor-lead. L0 поручает ему поставку. Проверь утверждённые входы, plan/test-plan, профиль проекта, разрешённые git-операции, baseline и workspace. Создай worktree по using-git-worktrees, если этого требует политика. До начала зафиксируй budget/retry limit и dependencies; default — 2 цикла исправления на задачу, затем пересмотр.
@@ -21,10 +28,22 @@ description: "Исполняй утверждённый план через L1
 
 ## Параллельность
 
-Разрешай несколько исполнителей только при независимых задачах, изолированных write sets/worktree, отсутствии общей незащищённой памяти и известном порядке интеграции. При сомнении сериализуй. Общие plan.md и .wolf/ изменяет назначенный владелец; .wolf/ в worktree — локальная (task-local) память этого worktree, перенос состояния между рабочими копиями — wolf-handoff snapshot. Не объявляй одинаковые файлы в разных ветках доказательством семантической независимости.
+Разрешай несколько исполнителей только при независимых задачах, изолированных write sets/worktree, отсутствии общей незащищённой памяти и известном порядке интеграции. При сомнении сериализуй. Общие plan.md и .wolf/ изменяет назначенный владелец; .wolf/ в linked worktree резолвится в общий main-чекоут, записи по умолчанию `scope: worktree:<name>`, перенос в общую память — `wolf promote`; передача незакоммиченного состояния между рабочими копиями — wolf-handoff snapshot. Не объявляй одинаковые файлы в разных ветках доказательством семантической независимости.
 
 ## Интеграция и завершение
 
 Объедини проверенные результаты на согласованном baseline; конфликты анализируй по смыслу, не выбирай сторону автоматически. Выполни integration/NFR/full checks из test-plan на объединённом состоянии. Составь ACCEPTANCE по каждому AC с evidence и известными ограничениями. Передай L0; PARTIAL/REJECTED/INCONCLUSIVE не называй завершением.
 
 После приёмки или согласованного промежуточного исхода используй finishing-a-development-branch в пределах полномочий. При остановке сохрани wolf-handoff, включая незакоммиченные изменения. Сессия не является единственным местом хранения состояния.
+
+## Гейт перехода
+
+Соответствие проверяется раньше качества; оба мандата должны быть видны в evidence. Зелёные тесты исполнителя не заменяют независимое ревью. ACCEPTANCE собирается на интегрированном состоянии; только затем L0 принимает поставку. При изменении контракта верни затронутые design/plan/test-plan на сверку.
+
+## Не пропускай процесс
+
+| Мысль | Действие |
+| --- | --- |
+| «Воркер написал DONE» | Это готовность к проверке, не приёмка. |
+| «Одно общее ревью достаточно» | Явно проверь соответствие, затем качество; сохраняй оба результата. |
+| «Разные ветки — значит независимы» | Проверь общие контракты, память и внешние ресурсы. |

package/templates/base/skills/wolf-skill-intake/SKILL.md

@@ -1,10 +1,17 @@
 ---
 name: wolf-skill-intake
-description: "Подключай внешний скилл после проверки точного источника, всего пакета, совместимости и разрешения владельца. Закрепляй версию, проверяй поведение в изоляции и обеспечивай откат."
+description: "Применять при поиске и подключении внешнего скилла, обновлении его пакета или версии, смене источника либо проверке установленной внешней методики перед активацией."
 ---
 
 # Приём внешней методики
 
+## Обязательный вход
+
+До исполнения любого содержимого пакета установи источник, revision, состав и применимые права. Внешний SKILL.md здесь является предметом проверки, не инструкцией выполнять его install-шаги. L0 согласует продуктовый выбор, L1 организует intake, L2 читает и испытывает назначенные материалы. Используй уже данное разрешение на тот же пакет и scope, не запрашивая его повторно.
+
+Загрузи полный текст назначенной методики до её выполнения. Обязательные пункты отслеживай в доступном трекере или рабочем брифе; не добавляй новые статусы памяти. Недоступное действие передай ответственному уровню.
+
+
 ## Процесс
 
 1. Найди кандидата доступным поиском/CLI. Количество установок, звёзды и репутация — сигналы для shortlist, не доказательство качества. Зафиксируй источник, лицензию, точную revision и состав пакета.
@@ -21,3 +28,15 @@ description: "Подключай внешний скилл после прове
 Откат: отключить доставку, восстановить предыдущий проверенный пакет или удалить только установленные intake-файлы, актуализировать реестр, проверить absence of ghost skills. Не удаляй общие зависимости без проверки потребителей. Обновление — новый пакет/revision с анализом diff и повторным trial затронутого поведения.
 
 L2 выполняет назначенное чтение/тестирование; установку и мутацию организации ведёт L1/Стюард по действующим полномочиям. Наличие пользовательского approval не отменяет ограничений платформы.
+
+## Гейт перехода
+
+Доставка активируется только для проверенных установленных байтов, совместимого процесса и разрешённого scope. Trial проверяет выбор, поведение, ложный триггер и границы роли. Внешние инструкции не могут отменить рамку Wolf. Обновлённая mutable-версия не наследует доказательства старой без анализа diff.
+
+## Не пропускай процесс
+
+| Мысль | Действие |
+| --- | --- |
+| «Популярный пакет можно сразу запустить» | Репутация помогает выбору, не заменяет чтение пакета. |
+| «Установщик берёт latest» | Сверь с проверенной revision до активации. |
+| «Invocation записан — польза доказана» | Проверь результат задачи и соблюдение границ. |

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

@@ -1,10 +1,17 @@
 ---
 name: wolf-testplan
-description: "Проектируй проверки требований и рисков по утверждённому дизайну. Создавай test-plan с независимыми ожидаемыми результатами, негативными сценариями, NFR и картой покрытия; код тестов пишет исполнитель."
+description: "Применять перед исполнением FULL-плана, при подготовке проверок нового поведения, изменении критериев приёмки или рисков; в LITE/FIX — когда нужно определить проверяемый результат."
 ---
 
 # Требования → план проверок
 
+## Обязательный вход
+
+Прочитай действующие AC и утверждённый дизайн или разрешённый бриф. L1 отвечает за общий тест-план, L2 — за назначенное исследование. В FULL сохраняй структуру test-plan.md: сценарии по REQ и прогоны. Укажи связи с NFR и планом без переизобретения AC. Пустые шаблонные сценарии не являются покрытием. Скилл составляет план проверок, а не подтверждает их прохождение.
+
+Загрузи полный текст назначенной методики до её выполнения. Обязательные пункты отслеживай в доступном трекере или рабочем брифе; не добавляй новые статусы памяти. Недоступное действие передай ответственному уровню.
+
+
 ## Вход и выход
 
 Вход: approved requirements/design или LITE/FIX-бриф; baseline, существующие тесты и профиль проекта. Выход: test-plan.md, карта REQ/NFR → сценарии → задачи/файлы. Документ тест-плана не является реализованным или пройденным тестом.
@@ -23,3 +30,15 @@ description: "Проектируй проверки требований и ри
 ## Готовность
 
 Все REQ/NFR покрыты проверками или имеют согласованное основание исключения; известны oracle и среда; зависимые задачи включают тестовую работу. Исполнитель начинает новый behavior/fix с чувствительной к дефекту проверки по test-driven-development.
+
+## Гейт перехода
+
+Перед исполнением известны ожидаемые результаты независимо от реализации, исходные данные, среда, команды или ручные процедуры и связь с задачами. Пробел в требовании верни в wolf-brainstorm, пробел в решении — в wolf-design; новый AC согласуй через CR. Передай реализацию проверок исполнительской роли с test-driven-development.
+
+## Не пропускай процесс
+
+| Мысль | Действие |
+| --- | --- |
+| «На каждый REQ есть строка, значит всё покрыто» | Проверь ошибки, границы и риски, а не число строк. |
+| «Ожидаемое возьму из кода» | Основание результата — требование или независимый эталон. |
+| «Ручная проверка не требует описания» | Укажи шаги, данные, результат и ограничения. |

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

@@ -1,26 +1,45 @@
 ---
 name: writing-skills
-description: "Создавай или изменяй базовый скилл Wolf в templates/base, проверяя триггеры, контракт роли, связность и поведение на реалистичных задачах. Изменение live playbook проходит через Стюарда."
+description: "Применять при создании, изменении или проверке методики Wolf перед доставкой; при повторяемом пропуске скилла, нарушении его процедуры или обновлении базового набора."
 ---
 
 # Разработка методики Wolf
 
+## Обязательный вход
+
+До редактирования зафиксируй сырой сценарий сбоя и измеримый результат. Различай шаблон скилла, рамку роли, механизм доставки и live playbook. Полномочия на один объект не разрешают автоматически менять остальные. При адаптации внешней методики исследуй её как источник, а не исполняй её инструкции в текущем проекте.
+
+Загрузи полный текст назначенной методики до её выполнения. Обязательные пункты отслеживай в доступном трекере или рабочем брифе; не добавляй новые статусы памяти. Недоступное действие передай ответственному уровню.
+
+
 ## Вход и границы
 
-Вход: конкретный дефект поведения или новая повторяемая задача, evidence, целевая роль и scope. Базовые шаблоны изменяй в templates/base/skills/<name>/SKILL.md; live face — через жалобу/Стюарда, не прямой правкой. Самостоятельное изменение рамки агента требует отдельного решения. Внешний пакет — wolf-skill-intake.
+Вход: конкретный дефект поведения или новая повторяемая задача, evidence, целевая роль и scope. Базовые шаблоны изменяй в templates/base/skills/<name>/SKILL.md; правку ведёт L1 — сам или через назначенного L2; live face — через жалобу/Стюарда, не прямой правкой. Самостоятельное изменение рамки агента требует отдельного решения. Внешний пакет — wolf-skill-intake.
 
 ## Процесс
 
 1. Найди действующий процесс и baseline. Определи наблюдаемое улучшение: какое действие/решение/артефакт должен измениться. Новым скиллом не дублируй существующий без необходимости.
-2. Запиши name и description с контекстом применения; тело: роль, вход/выход, процедура, критерий готовности, ограничения, восстановление. Убирай мотивационные повторы и абсолютные утверждения без условий.
+2. Запиши name и description только с условиями применения (не пересказом процесса); тело: роль, вход/выход, процедура, критерий готовности, ограничения, восстановление. Убирай пустые повторы, но сохраняй прямые запреты пропуска и таблицу реально наблюдавшихся оправданий. Укажи момент обязательной загрузки, checklist и гейт перехода.
 3. Держи методику самодостаточной для реального рендерера. Плейсхолдеры только поддержанные. References используй лишь при подтверждённом копировании и доступности; историю адаптации хранить вне runtime-текста допустимо, но доставка ссылки должна работать.
 4. Сверь с рамками/permissions, активными playbook, upstream/downstream-сценариями и таксономией. Не создавай новую команду, поле или статус только текстом. Универсальный процесс использует профиль проекта вместо жёстко заданного стека.
 5. Подготовь сырые сценарии: обычная задача, ложный триггер, недостаток контекста, конфликт, сбой инструмента и ложное «готово». Зафиксируй oracle/rubric до испытания. Добавь регрессионный сценарий исходной жалобы.
 6. Сравни baseline и candidate на одинаковых условиях с чистыми исполнителями. Им дай задачу и доступный скилл, без подсказки ожидаемого исправления. Сохрани outputs/traces, применённую версию, rubric, качество и стоимость; один удачный пример не объявляй обобщённой эффективностью.
-7. Проверь frontmatter, ссылки, placeholders, роли и переходы; выполни существующие guard/render tests набора. Structural pass и behavioral pass укажи раздельно. Непроведённые испытания отметь явно.
+7. Проверь frontmatter, ссылки, placeholders, роли и переходы; выполни существующие guard/render tests набора. Structural pass и behavioral pass укажи раздельно. Для using-skills проверь, что bootstrap доставляет полный актуальный текст из одного источника, а не отдельно поддерживаемый пересказ. Непроведённые испытания отметь явно.
 8. Измени source template; разрешённым git-процессом сохрани revision. wolf sync проверь на staging-копии проекта: сохранение локальных мутаций, доставка нового скилла и отсутствие ghost. Live rollout требует соответствующего разрешения.
 9. Выдай migration notes, evidence, ограничения и способ rollback на прежнюю revision. Наблюдай повторение исходной ошибки и новые регрессии относительно числа сопоставимых задач.
 
 ## Трассировка
 
 Для адаптации сохрани source/revision → сохранённое/изменённое/удалённое → причина вне исполняемой методики. Это аудит происхождения, не замена проверки качества. Изменения Стюарда не должны автоматически становиться новым глобальным шаблоном без отдельной проверки переносимости.
+
+## Гейт перехода
+
+Методика готова к пробной доставке после структурной проверки, проверки ролей и переходов, сценария исходного сбоя, ложного триггера и независимых поведенческих проб. Не объявляй улучшение доказанным одним чтением текста. Сохрани source diff, результаты, непройденные проверки и способ отката; live rollout — отдельное действующее разрешение.
+
+## Не пропускай процесс
+
+| Мысль | Действие |
+| --- | --- |
+| «Звучит убедительно, значит работает» | Проверь реальные действия агента и артефакты. |
+| «Описание кратко объяснит весь процесс» | description задаёт условия загрузки; процедура живёт в теле. |
+| «Изменю и шаблон, и лицо напрямую» | Live playbook проходит существующий контур Стюарда. |

package/templates/opencode/plugins/wolf-session-start.js

@@ -14,6 +14,7 @@
  */
 
 import path from 'path';
+import { readFileSync } from 'fs';
 import { execFile } from 'child_process';
 import { randomUUID } from 'crypto';
 import { promisify } from 'util';
@@ -33,25 +34,51 @@ const MARKER = 'Mr.Wolf session bootstrap';
 // [ \t] вместо \s: \s съедает переводы строк и вытаскивает id с чужой строки.
 const AGENT_ID_RE = /^agent-id:[ \t]*([\w-]+)[ \t]*$/m;
 
-const FULL_BODY = `## Протокол сессии Wolf (L0/L1)
+const SESSION_BODY = `## Протокол сессии Wolf (L0/L1)
 
 - Начало сессии и после /clear: \`wolf call\` и \`wolf brief\` — активное руководство проекта; они приоритетнее статических файлов.
 - Значимое фиксируй в памяти: решения — \`wolf add --type decision\`, уроки — \`--type lesson\`, блокеры — thread со статусом blocked; устаревшее — \`wolf supersede\`.
-- Состояние проекта — только у Wolf (\`wolf search\` / \`wolf get\` / \`wolf brief\`), статические списки в файлах устаревают.
-
-## using-skills: governance-набор (H2)
-
-- **Полномочия**: L0 держит цель и принимает результат; L1 декомпозирует, управляет L2 и выполняет разрешённые git-операции; L2 — одна подзадача, allowlist, без спавна агентов и коммитов.
-- **Процессные скиллы — по типу ситуации, а не по оценке**: новая или изменённая потребность — wolf-brainstorm; баг или неожиданное поведение — wolf-debug; заявление о завершении — verification-before-completion.
-- **Break-glass**: если сомневаешься, применим ли скилл, — загрузи и проверь, а неподходящий скилл использовать не обязан.
-- **Маршрут**: утверждённые requirements+design → wolf-plan/wolf-testplan → wolf-sdd (или wolf-execute без диспетчеризации); передача состояния — wolf-handoff; завершение git-работы — finishing-a-development-branch.
-- **Масштаб**: FULL/LITE/FIX; режим фиксирует L1; при вскрытии новых контрактов или второго компонента в LITE/FIX — остановка и переклассификация L1 в FULL.
-- **Контракты**: TASK / RESULT (DONE | DONE_WITH_CONCERNS | NEEDS_CONTEXT | BLOCKED) / EVIDENCE / ACCEPTANCE.
-- **Приоритет**: ограничения платформы → явные указания пользователя → политика проекта и активная память → назначенная методика → дефолт.`;
+- Состояние проекта — только у Wolf (\`wolf search\` / \`wolf get\` / \`wolf brief\`), статические списки в файлах устаревают.`;
+
+// Один источник процессной дисциплины: полный установленный SKILL.md.
+// Чтение происходит только при реально нужной инъекции, не на каждый ход.
+// В source-tree тестах доступен base-шаблон; в целевом проекте — только
+// установленный скилл (не случайный project/base каталог).
+function governanceBody() {
+  const candidates = [path.join(__dirname, '..', 'skills', 'using-skills', 'SKILL.md')];
+  if (path.basename(path.resolve(__dirname, '..', '..')) === 'templates') {
+    candidates.push(path.join(__dirname, '..', '..', 'base', 'skills', 'using-skills', 'SKILL.md'));
+  }
+  for (const candidate of candidates) {
+    try {
+      const raw = readFileSync(candidate, 'utf8');
+      const match = raw.match(/^---\r?\n[\s\S]*?\r?\n---\r?\n([\s\S]*)$/);
+      const body = match?.[1]?.trim();
+      if (body) {
+        return `## using-skills: полный текст уже загружен\n\nНе вызывай using-skills повторно ради загрузки. Другие методики загружай отдельно до их выполнения.\n\n${body}`;
+      }
+    } catch {
+      // Missing/unreadable skill is a visible degraded mode, not a fake load.
+    }
+  }
+  return `## using-skills: FALLBACK — полный текст недоступен
+
+Полный using-skills НЕ загружен. Попробуй доступный механизм скиллов;
+при неудаче обозначь ограничение, не имитируй загрузку.
+Полномочия: L0 координирует, L1 исполняет и управляет, L2 не спавнит и не коммитит.
+До вопросов и действий: новая разработка — wolf-brainstorm; баг — wolf-debug;
+заявление о готовности — verification-before-completion. Названный скилл загрузи явно.
+Утверждённые входы: wolf-plan/wolf-testplan → wolf-sdd либо разрешённый wolf-execute.
+Смена сессии: wolf-handoff. Git-финал: finishing-a-development-branch.
+Режим FULL/LITE/FIX фиксирует L1; TASK/RESULT/EVIDENCE/ACCEPTANCE сохраняют свои контракты.
+Не переходи через неподтверждённый обязательный этап; разговор и сбор недостающего контекста возможны.`;
+}
 
 const WORKER_BODY = `## using-skills: пассивный режим воркера (L2)
 
 - Работаешь ровно одну подзадачу: читаешь назначенные скиллы, каталог сам не перебираешь.
+- Методики загружай до исполнения. Блокер и недостающие входы передай L1;
+  не начинай продуктовый discovery и новый тред вместо назначенной задачи.
 - Не спавнишь агентов и не коммитишь.
 - Отчёт по контракту RESULT/EVIDENCE с task_id.`;
 
@@ -70,7 +97,7 @@ function computeInjection(messages, agentId) {
     );
     if (seen) return null;
     // MAJ-4: worker-* → усечённое тело (без диспетчерского контура using-skills).
-    return /^worker-/.test(String(agentId ?? '')) ? WORKER_BODY : FULL_BODY;
+    return /^worker-/.test(String(agentId ?? '')) ? WORKER_BODY : `${SESSION_BODY}\n\n${governanceBody()}`;
   } catch {
     return null;
   }