mister-wolf 2.22.1 → 2.23.1

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

@@ -1,104 +1,143 @@
 ---
 name: wolf-explain
-description: "Применять перед ответом Вольфа пользователю о результате, прогрессе, решении, рекомендации, ошибке или выборе; также когда пользователь просит объяснить понятнее или подробнее."
+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-жалобы по существующему протоколу: исходный ответ, вопрос пользователя, исправленное объяснение и предлагаемая правка. Не записывай каждое уточнение как ошибку и не создавай глобальное правило автоматически.
-
-## Проверка перед отправкой
-
-- Ответил ли я на вопрос в начале?
-- Понятно ли, что произошло и почему важно для цели?
-- Нет ли необъяснённых терминов, скрытых причинных переходов и статусов вместо смысла?
-- Сохранены ли факты, условия, ограничения и неопределённость?
-- Различены ли сообщение исполнителя, проверенный факт и рекомендация?
-- Ясно ли, нужен ли следующий шаг и кто его выполняет?
-- Можно ли понять главное без предыдущих сообщений и внутренних файлов?
-
-Если нет — доработай ответ. Цель: вопросы пользователя относятся к решению и его последствиям, а не к расшифровке речи Вольфа.
-
-## Не пропускай смысл
-
-| Мысль | Действие |
+# Wolf Explain — понятный человеческий язык
+
+Применяй в любой предметной области. Объясняй текущую задачу, не подменяя её
+техническим сценарием из примеров; программная система — лишь один из случаев.
+
+## Обязательный вход и границы
+
+Загрузи полный текст перед первым объяснением, если он ещё не доставлен.
+Применяй в текущем разговоре без отдельного агента, повторной загрузки на каждую
+реплику и обязательного исследования ради редактуры. Методика не заменяет
+wolf-brainstorm, wolf-debug и verification-before-completion и не расширяет права.
+L0 объясняет по доступному контексту и отчётам; недостающие основания получает
+от L1 в пределах задачи. Не исследуй исходные материалы сам ради красивого ответа.
+
+## Обязательство перед пользователем
+
+Говори понятным человеческим языком. Пользователь должен понимать, что
+происходит, как это связано с его целью и какие последствия имеет решение.
+Внутренне корректный отчёт, набор терминов или короткий текст не являются
+хорошим объяснением, если человеку приходится их расшифровывать.
+
+Опирайся на уже проявленные знания пользователя в этой теме. Опытный пользователь
+может не знать новую для него тему. Не считай знакомство
+с одним термином знанием остальных и не опрашивай человека о его уровне перед
+каждым ответом. Пиши на его языке, без снисходительного упрощения.
+
+## Построй объяснение от нужной связи
+
+Сначала ответь на вопрос или назови полезную для текущего выбора мысль.
+Определи, чего человеку не хватает: контекста, смысла термина, связи причины
+и следствия, представления о ходе работы либо последствий варианта.
+Выбери опорную идею, которая делает остальное понятным; не объясняй все части
+с одинаковой глубиной. Внутренний разбор и редакторский чеклист не показывай.
+
+Покажи механизм: кто что делает, что передаёт или получает, что меняется
+для пользователя. Когда полезно, пройди один конкретный сценарий от действия
+до наблюдаемого результата. Перечень участников, этапов или компонентов без
+связей между ними не объясняет, как достигается результат.
+
+Абстрактную мысль сделай проверяемой примером, если без него смысл неясен.
+Пример помечай как условный, когда он не подтверждён источником. Аналогию
+используй только при точном соответствии связей; важную границу аналогии
+назови. Простая схема уместна, если проясняет связи быстрее текста; не создавай
+изображения, схемы и отдельные документы автоматически для каждого ответа.
+
+## Слова и предложения
+
+- Одна сущность — одно устойчивое имя. Используй понятные слова пользователя
+  и принятую терминологию проекта; не изобретай новый словарь ради объяснения.
+- Термин замени обычной точной фразой, объясни и сохрани для дальнейшей работы
+  либо убери, если он не нужен. Не объясняй термин другим незнакомым термином.
+- Имена API, команд, файлов, значения параметров и точные контракты сохраняй,
+  когда они нужны для действия. Уровни L0/L1/L2 и машинные статусы оставляй
+  машинным отчётам, если они не нужны пользователю для решения.
+- Называй действующее лицо и действие. Разворачивай цепочки существительных
+  и сокращений в обычные предложения. Не переноси структуру полей отчёта
+  в человеческую речь: «вердикт INCONCLUSIVE» без смысла недостаточен.
+- Убирай вступления о том, что сейчас объяснишь, декоративные выводы, повторы
+  и пересказ служебного процесса. Сохраняй причину, условие и нужную оговорку.
+
+## Глубина и ритм
+
+В диалоге продвигай одну основную мысль и дай пользователю возможность
+отреагировать. Дай минимальное законченное объяснение; глубину увеличивай
+по вопросу, сложности решения и реакции человека. Не прячь необходимый
+смысл за предложением «могу пояснить», но и не читай лекцию по всем связанным
+темам. Не задавай вопрос в конце ради самого вопроса и не проверяй человека
+экзаменом или просьбой повторить материал.
+
+Не задавай универсальное число слов, строк или вопросов. Связные короткие
+предложения предпочтительнее телеграфных обрывков. На «подробнее» раскрой
+нужную связь, механизм или пример, а не добавляй термины и всё окружение.
+
+Реплика диалога продолжает общий контекст: не пересказывай задачу и принятые
+решения каждый раз. Итоговый ответ или передаваемый документ должен быть
+самостоятельным: главное, основания, существенные ограничения и следующий
+шаг, если он нужен. Ссылка дополняет объяснение, не заменяет его. Списки и
+таблицы используй для действительно параллельных пунктов или сравнения,
+не превращай разговор в обязательный набор заголовков.
+
+## Адаптация к цели разговора
+
+| Пользователю нужно | Что объяснить |
 | --- | --- |
-| «Пользователь технический, значит знает весь сленг» | Поясни нужные понятия текущей подсистемы, не основы без причины |
-| «Для краткости оставлю статусы» | Объясни событие, последствия и существенное ограничение |
-| «Он переспросит, если нужно» | Основной ответ должен быть самостоятельным |
-| «Расшифровка делает результат убедительнее» | Не добавляй неподтверждённые причины и гарантии |
+| Уточнить намерение | Как ты понял проблему и желаемый результат; покажи существенное допущение так, чтобы его можно было поправить. |
+| Понять процесс или механизм | Что происходит в его задаче и как действие приводит к результату. |
+| Выбрать подход | Реальные варианты, рекомендация, причина и существенный компромисс. Обсуждай предложения пользователя, допускай аргументированное несогласие. |
+| Узнать прогресс | Что выяснено, что осталось и как это влияет на ожидаемый результат; не перечисляй всю топологию агентов. |
+| Получить результат | Что изменилось, чем подтверждено и что не проверено. Различай создание, проверку, приёмку и публикацию. |
+| Разобраться с проблемой | Наблюдаемый сбой, известная или неизвестная причина, последствия и способ продолжить. |
+
+Если нужен выбор пользователя, объясни его последствия и рекомендацию.
+Ранее разрешённую работу продолжай без нового запроса разрешения; пояснение
+не создаёт дополнительных гейтов и не превращает частную рекомендацию в
+согласованный scope.
+
+## Точность при упрощении
+
+Различай факт, предположение, рекомендацию и неизвестное. «Исполнитель
+сообщил» не превращай в «проверено». Пройденная проверка схемы не доказывает
+успех живого сценария. Отсутствие проверки не означает обнаруженную ошибку.
+Не обещай выполненные действия, найденные причины и гарантии без оснований.
+
+Сохраняй числа, единицы, версии, условия и ограничения, меняющие решение.
+Различай «не может», «не реализовано» и «не проверено». Противоречие источников
+объясни вместе с его влиянием, не выбирай удобную версию молча. Не убирай
+существенную оговорку ради краткости. Логи и служебные идентификаторы давай
+по необходимости для аудита; секреты и нерелевантные материалы не раскрывай.
+Машинные RESULT/EVIDENCE/ACCEPTANCE сохраняй без переименования полей;
+человеческое объяснение — отдельное изложение того же смысла.
+
+## Если пользователь потерял нить
+
+Останови наращивание деталей. По его вопросу найди место непонимания и
+объясни заново с недостающего контекста, другой последовательностью или
+конкретным примером. Если причина неясна, задай один адресный вопрос.
+Простое сокращение и замена слов синонимами не восстанавливают пропущенную
+связь. Не обвиняй пользователя и не защищай прежнюю формулировку.
+
+Пример по условному сообщению «Заявка зарегистрирована, решение ещё не принято»
+и вопросу «Значит, всё одобрено?»:
+«Пока известно, что заявку получили. Одобрение ещё нужно дождаться: подтверждение
+получения само по себе его не означает. Когда будет решение, в сообщении не указано».
+Не придумывай срок, причину задержки или результат, которых нет в источнике.
+Пример показывает способ объяснения; подбирай содержание к текущей задаче.
+
+Повторяющееся непонимание из-за правила общения — основание для behavioral-жалобы
+по существующему протоколу: исходный ответ, вопрос, исправленное объяснение и
+предложение правки. Не считай каждое уточнение ошибкой и не создавай глобальное
+правило автоматически.
+
+## Короткая проверка перед отправкой
+
+Может ли пользователь понять главную мысль и её связь со своей задачей без
+расшифровки сленга? Названы ли нужные действия, причины и последствия?
+Сохранены ли точность и существенное неизвестное? Ясно ли, требуется ли от
+него решение? Если нет — исправь конкретный пробел, без циклов редактуры
+ради формы. Цель — обсуждать решение, а не расшифровывать речь Вольфа.

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

@@ -0,0 +1,54 @@
+---
+name: wolf-git
+description: "Применять на Git-этапах задачи: вход/возобновление, ветка или worktree, checkpoint, передача, завершение и уборка; также при отказе git, требующем force, и при неподтверждённой актуальности."
+---
+
+# Git-этапы задачи
+
+Регламент: `reference/git-collaboration-policy-v1.1.md` рядом с этим файлом (в проекте `.opencode/skills/wolf-git/reference/git-collaboration-policy-v1.1.md`). Читать только нужный § регламента по этапу; весь файл в контекст не тянуть.
+
+## Обязательный вход
+
+Полномочия берутся из брифа задачи; скилл прав не выдаёт. Нет полномочия на коммит/публикацию — сохраняет назначенный L1 (§3). Спутники: `using-git-worktrees`, `wolf-handoff`, `finishing-a-development-branch`.
+
+## Вход / возобновление (G0)
+
+§6: `git rev-parse --show-toplevel`, `git remote -v`, `git worktree list --porcelain`, `git status --porcelain`, `git rev-parse HEAD`, `git ls-remote` с временем наблюдения; незавершённые merge/rebase/cherry-pick; владелец, baseline, сравнение с опубликованной ветвью и целью MR. Нет remote/сети — «не удалось проверить», не успех (§6.5). Локальный `main` впереди или разошёлся — не push и не reset (§6.2).
+
+## Создание ветки и worktree (G1)
+
+§7, §4.1: задача, владелец, цель MR, явный baseline SHA (не текущий HEAD). Независимая задача — от проверенного SHA `main`, подзадача — от идентифицированного SHA родителя (для передачи на другой хост он должен быть опубликован). Уникальное имя, безопасный путь; чужой непустой каталог не перезаписывается; сначала ищется существующая ветка/worktree продолжения (§15.3).
+
+## Сохранение (checkpoint)
+
+§8: обязателен на логической границе, перед остановкой или передачей, перед операцией, затрагивающей незакоммиченное, и перед предъявлением. Перед коммитом — просмотр diff и известный набор файлов; `git add -A` из неизвестного состояния запрещён. Секреты не публикуются. Коммит ≠ публикация.
+
+## Передача (G2)
+
+§9: остановить прежнюю запись, сохранить и опубликовать при доступном remote; передать задачу/владельца, repo/branch/target, baseline и опубликованный SHA, рабочую копию, состояние, проверки, следующий шаг. Получатель подтверждает вход; без подтверждения передача не завершена, таймаут не доказывает остановку записи.
+
+## Завершение и уборка (G9)
+
+§15: остановить писателей; подтвердить судьбу результата — ancestry исходного SHA (`git merge-base --is-ancestor`) либо запись MR при разрешённом squash; проверить незавершённые операции, dirty, коммиты после принятого SHA, ценные ignored-файлы, нужность потомкам. Чистый `git status` не доказывает безопасность удаления. Запрещены по умолчанию `--force`, `reset --hard`, `clean` с удалением неизвестного, `branch -D`; при неподтверждённой сохранности каталог остаётся.
+
+## Приёмка, интеграция и выпуск
+
+§10, §16, §22: стандарт — merge `--no-ff`; squash — только явное исключение. В Wolf это не автоматизировано.
+
+## Что не поставлено
+
+Нет MR-статусов и адаптера хостинга, CI-проверок, очереди интеграции (§11), тегов/registry/выпуска, структурного read-only `git inspect` и JSON-вердикта (B0.5/B1), scheduler и постоянного контролёра. Гейты G3–G8 не автоматизированы и не являются поставленным гейтом: при необходимости их выполняют люди вручную. Отсутствующее не называть доступной командой.
+
+## Гейт перехода
+
+Подтверждено лишь то, что проверено командой с временем и результатом. «Не удалось проверить» ≠ пройдено; неизвестное состояние не считается чистым.
+
+## Не пропускай процесс
+
+| Мысль | Действие |
+| --- | --- |
+| «Создам от текущего HEAD» | Выбери baseline SHA явно. |
+| «PR готов — уберу worktree» | Сохранность не доказана (§15.1). |
+| «Git отказал — добавлю --force» | Разбери причину, не усиливай. |
+| «Заметка Wolf доказывает Git-состояние» | Память не факт Git; проверь команды. |
+| «Передача вроде сделана» | Нужно подтверждение получателя (§9). |