refactor(skill): плейбук возвращён к оптике тонкого мастера

- Зачем:
  - субагенты должны сохранять внимание мастера и помогать результату, а не обслуживать обязательный конвейер.
- Что:
  - семиступенчатый процесс заменён эвристиками выбора исполнителя, проверяющего и независимого ревьюера.
  - права агентов отделены от канала результата, а полная полезная нагрузка выведена из контекста мастера.
  - добавлены авторитетные договоры промптов, полевые заметки и handoff следующей сессии.
- Проверка:
  - git diff --cached --check.
  - свежий обзор через writing-great-skills, все принятые находки закрыты.

agents/.agents/skills/codex-subagent-playbook/SKILL.md

@@ -1,169 +1,132 @@
 ---
 name: codex-subagent-playbook
-description: Координация одной нетривиальной инженерной задачи через субагентов с сохранением чистого контекста мастера.
+description: Оптика тонкого мастера для одной нетривиальной задачи: субагенты сохраняют контекст и приносят нужную независимость.
 ---
 
 # Тонкий мастер
 
-Ты — координатор. Держи в своём контексте цель, ограничения, решения и
-индекс находок. Исследование, реализацию, проверки, журналы и полный diff
-отдавай субагентам. Внешний агент полезен как дополнительная независимая
-линия, но процесс не должен от него зависеть.
+Это оптика работы, а не обязательный конвейер. Цель — решить одну
+нетривиальную задачу, сохранив внимание мастера для цели, ограничений,
+решений и рисков. Субагенты нужны результату, а не процессу.
 
-Применяй конвейер к одной нетривиальной задаче. Если работа локальна, вывод
-короток и ошибка дёшева, сообщи о лишних накладных расходах и сделай её сам.
+Тонкий мастер не пустой мастер. Он сам принимает решения, делает дешёвые
+точечные проверки и смотрит ключевые артефакты. Исследование, реализацию или
+проверку он отдаёт только тогда, когда отдельный контекст даст задаче
+конкретное преимущество.
 
-## Договор делегирования
+## Основная оптика
 
-- Запускай свежих исполнителей без истории мастера (`fork_turns="none"`).
-  Если схема `spawn_agent` открывает `agent_type`, `model` и
-  `reasoning_effort`, выбери один источник истины: для TOML-роли передай
-  только `agent_type`; для разового выбора передай `model` и
-  `reasoning_effort` без роли с закреплённой моделью. Полный fork `all`
-  несовместим с этими переопределениями; плейбук использует `none` ради
-  чистого контекста. Передавай путь к самодостаточному файлу-задаче, а не
-  пересказ разговора.
-- Давай каждому субагенту одну роль и проверяемый результат. Выбирай самый
-  дешёвый уровень, который надёжно справится с этой ролью. Если хост скрыл
-  параметры модели, пометь стоимость как незакреплённую.
-- В начале прогона создай один обменный каталог во временном каталоге ОС с
-  непредсказуемым именем (`mktemp -d` или аналог) и передай агентам его
-  абсолютный путь. Индекс держи у мастера; длинные отчёты, журналы и
-  повторно используемые промпты — файлами. Прочитай полезную нагрузку один
-  раз, дальше передавай путь: аргументы `spawn_agent`, `send_message` и
-  `followup_task` остаются в истории мастера.
-- Проси вернуть только итог, доказательства, вопросы-решения и следующий
-  шаг. Полные журналы оставляй в обменном каталоге. В репозиторий клади
-  только долговечные артефакты, предусмотренные его правилами.
-- Продолжай того же исполнителя для починки его кода. Для независимого
-  ревью запускай свежий тред.
-- Держи одного владельца рабочего дерева. Пока он пишет, другие агенты не
-  читают это дерево. Параллель разрешай только для неизменяемых входов или
-  отдельных worktree.
-- До писателя сохрани в `/tmp` машинно читаемую точку отсчёта: статус,
-  полный staged/unstaged diff, а также перечень и хэши неотслеживаемых
-  файлов. После него сравни новое состояние с точкой отсчёта и отчётом. Не
-  удаляй и не откатывай чужие изменения.
-- Сообщай пользователю короткий статус на границах этапов.
+- Перед каждым запуском ответь: что этот агент добавит — защиту контекста,
+  свежий взгляд, специализацию, параллельность или отдельную среду проверки?
+  Если ничего, работай сам или продолжи существующий тред.
+- Держи у мастера короткий индекс: цель, ограничения, принятые решения,
+  риски, вердикты и доказательства, влияющие на следующий шаг. Полные diff,
+  журналы и нарративы ему не нужны.
+- Исследование с неизвестным или шумным объёмом делегируй до погружения.
+  Одну узкую гипотезу с предсказуемо короткой командой мастер может проверить
+  сам; если ответа нет, продолжение уходит агенту.
+- Свежий тред даёт независимость от исполнителя, но не разнообразие ошибок.
+  Другое семейство моделей даёт отдельную линию; второй агент того же
+  семейства оправдан только высоким риском или действительно иным фокусом.
+- Выбирай самый дешёвый надёжный уровень для выбранной работы. Если хост не
+  показывает модель и глубину, считай стоимость незакреплённой и не умножай
+  совместимые роли без явной пользы.
+- Один исполнитель владеет изменениями исходников. Его же продолжай для
+  исправлений; независимую оценку отдавай свежему треду. Права
+  `workspace-write` сами по себе не делают агента владельцем исходников.
 
-Если нужные роли ещё не настроены или надо выбрать модели, прочитай
-[уровни и роли](references/roles.md). Не загружай этот справочник в обычном
-прогоне с уже настроенными ролями.
+Внешняя модель полезна как дополнительная линия, когда её родословная и цена
+оправданы риском. Процесс не должен от неё зависеть.
+
+## Контекст и обмен
+
+- Если результат понадобится следующему агенту, полный отчёт запиши в
+  уникальный файл временного обменного каталога. Мастеру верни только итог,
+  счётчики, вопросы-решения и путь. Короткий конечный результат можно вернуть
+  одним сообщением.
+- Канал результата не связан с правами агента. Ревьюеру можно дать рабочие
+  права для тестов, кэшей, поиска и документации, а запрет менять исходники и
+  постоянное окружение удерживать мандатом и сверкой Git до и после.
+- Не возвращай один полный отчёт одновременно файлом и сообщением. Не
+  переписывай находки между файлами: передавай исходный путь или собирай новый
+  промпт механической конкатенацией.
+- Не выводи в контекст мастера полную точку отсчёта, diff, перечень хэшей или
+  сырой журнал. Если дерево грязное или возможны пересечения, порученный
+  агент либо готовый скрипт сохраняет подробности во временный файл и сообщает
+  только состояние, счётчики, пересечение с разрешённым объёмом и путь.
+- Временные обменные файлы веди на английском. Долговечные документы и текст
+  для пользователя пиши на языке проекта.
+- Сообщай пользователю короткий статус на действительно значимых границах, а
+  не на каждом служебном переходе. Тайм-аут и `idle` не являются результатом.
+
+## Когда какой приём полезен
+
+- **Самодостаточная постановка** нужна, когда исполнитель начинает без истории
+  разговора или проекту важен долговечный след. Для локальной ясной правки
+  достаточно короткого мандата.
+- **Исследователь** нужен для неизвестного объёма, внешних фактов или шумного
+  обхода репозитория. Его результат — факты и вопросы, не реализация.
+- **Ревью постановки** окупается при скрытых проектных решениях, дорогой ошибке
+  или критериях, которые можно выполнить формально без нужного результата.
+- **Исполнитель** нужен, когда отдельный контекст реализации ценнее прямой
+  работы мастера. Он не коммитит и не расширяет объём без решения мастера.
+- **Проверяющий** нужен для шумных журналов, специальной среды, стенда или
+  независимого подтверждения команд. Не создавай отдельную роль, если те же
+  проверки дёшево и надёжно выполняет исполнитель либо ревьюер.
+- **Свежий ревьюер** нужен, когда цена пропущенного дефекта выше стоимости
+  обзора. По умолчанию достаточно одного. Вторую линию добавляй ради другого
+  семейства моделей или отдельного класса риска, а не ради числа два.
+
+## Типичный ход задачи
+
+Часто полезно уточнить постановку, дать одному исполнителю реализовать её,
+проверить обязательные свойства и при заметном риске получить свежий обзор.
+Пропускай, объединяй и меняй порядок этих действий, если так надёжнее и
+дешевле достигается результат.
+
+- Перед реализацией разреши продуктовые, архитектурные и относящиеся к
+  границам решения вне мандата исполнителя. Технический способ внутри мандата
+  оставь ему.
+- Пока исполнитель меняет исходники, не запускай другого владельца тех же
+  файлов. Параллель разрешай для независимых неизменяемых входов, отдельных
+  worktree или команд без общего изменяемого состояния.
+- Обязательные и доступные сквозные проверки должны пройти до финальной
+  приёмки. Недоступную или падающую проверку нельзя молча превратить в зелёную:
+  риск принимает пользователь либо полномочие, заранее записанное в задаче.
+- Ревьюеру дай задачу, изменённый объём, проверки и один выбранный фокус. Он
+  исследует и проверяет гипотезы, но не исправляет исходники. Вердикт без
+  находок должен назвать просмотренный объём и выполненные проверки либо
+  проверенные гипотезы.
+- Находки возвращай тому же исполнителю. Он исправляет или аргументированно
+  отклоняет их через контракт и проверку. Исходный ревьюер при необходимости
+  узко проверяет свои находки; новый соседний дефект не скрывает.
+- На финале мастер смотрит только решения, остаточные риски, итоговые счётчики
+  и действительно ключевые артефакты. Полный diff и отчёты читают агенты,
+  которым поручена их проверка. Коммит делай только по просьбе пользователя.
+
+## Нативные договоры
+
+Если нужны готовые роли или выбор моделей, прочитай
+[уровни и роли](references/roles.md). Если роли не настроены, не имитируй
+экономию названиями: честно отметь незакреплённую стоимость.
+
+Когда выбран конкретный приём, возьми только его договор из
+[сборки нативных промптов](references/prompt-templates.md). Не загружай все
+шаблоны заранее и не переписывай их текст в вызов агента.
 
 При развитии скилла или первом прогоне в новой среде прочитай
-[полевые заметки](references/field-notes.md) и проверь открытые предположения.
-
-Точные договоры заданий и результатов бери из нужного раздела
-[скелетов нативных промптов](references/prompt-templates.md). Это их
-единственный источник; не переписывай форматы в других файлах.
-
-## Формат возврата
-
-Если результат понадобится следующему агенту, полный отчёт сначала запиши в
-отдельный файл обменного каталога. Финальный ответ ограничь состоянием,
-счётчиками, коротким индексом и путём. Для параллельных агентов используй
-разные пути. Не возвращай один полный отчёт одновременно файлом и сообщением.
-До запуска выбери канал: агент с записью в обменный каталог сохраняет полный
-отчёт файлом; `read-only`-агент возвращает короткий индекс один раз
-сообщением. Для длинного переиспользуемого отчёта заранее выбери
-`workspace-write`, запрети правки исходников и сверь Git до и после.
-
-## Конвейер
-
-### 1. Зафиксировать задачу
-
-Создай или уточни принятый проектом файл-задачу: цель, критерии приёмки,
-границы, решения, что прочитать и команды проверки. Шумное исследование
-репозитория отдай быстрому исследователю. Он находит команды, но не запускает
-полный набор; узкую проверку выполняет только для подтверждения нужного
-факта. Если задача ссылается на другой скилл, продублируй его ключевые
-требования текстом: исполнитель может не подхватить скилл автоматически.
-
-Этап завершён, когда исполнитель может начать без истории разговора и без
-уточняющих вопросов.
-
-### 2. Проверить постановку
-
-Для сложной или дорогой ошибки отдай постановку свежему сильному ревьюеру.
-Попроси проверить её против реального кода: выполнимость, скрытые решения,
-пропущенные критерии и способы формально отчитаться без нужного результата.
-Для особенно дорогой ошибки используй два слепых ревью.
-
-Внеси в файл-задачу решение по каждой находке: принять, сузить или отклонить
-с доводом.
-
-Этап завершён, когда у каждой находки есть записанное решение.
-
-### 3. Реализовать
-
-Передай задачу отдельному исполнителю с правом записи. Мандат: следовать
-файлу-задаче, не делать коммит, не менять соседний объём. Исполнитель
-запускает только узкие проверки разработки; полный набор остаётся этапу 4.
-
-Этап завершён, когда отчёт исполнителя соответствует изменённому дереву и
-все критерии либо выполнены, либо явно помечены как заблокированные.
-
-### 4. Переварить проверки
-
-Отдай быстрому проверяющему тесты, линтеры, сборку и объёмные журналы. Пусть
-он вернёт команды, счётчики, короткую причину каждого сбоя и путь к полному
-журналу. Исправления возвращай исполнителю этапа 3.
-
-Этап завершён, когда полный обязательный набор прошёл после последней правки
-или каждый оставшийся сбой объяснён и принят пользователем.
-
-### 5. Провести слепое ревью
-
-Создай один канонический файл ревью на всех слепых ревьюеров. Запусти свежего
-ревьюера без контекста исполнителя; в `message` передай путь к этому файлу и
-выбранный канал результата. Для `workspace-write` добавь уникальный путь
-файла, для `read-only` запроси один короткий индекс сообщением. Для высокого
-риска запусти двух ревьюеров параллельно с разными фокусами и каналами,
-которые не конфликтуют.
-Внешнюю модель подключай дополнительной линией, если она доступна и её
-стоимость оправдана. Ревьюеры исследуют и проверяют гипотезы, но не
-исправляют код. Канал результата выбери по правилам раздела «Формат
-возврата»; точный договор — в скелете слепого ревью.
-
-Этап завершён, когда все запрошенные вердикты получены, а рабочее дерево не
-содержит неназванных правок.
-
-### 6. Закрыть находки
-
-Продолжи исполнителя этапа 3 и передай пути к исходным индексам без
-пересказа. Он исправляет находку, сужает исправление или отклоняет её через
-контракт, код и проверку. Мастер проверяет серьёзные и спорные отклонения,
-решает вопросы объёма и риска. Исполнитель сохраняет отчёт о решениях
-файлом; прежнему ревьюеру передай только путь к нему и запрос на узкую
-проверку собственных находок.
-
-Этап завершён, когда по каждой находке записано решение и принятые
-исправления перепроверены.
-
-### 7. Принять результат
-
-Используй отчёт этапа 4. Повтори только проверки, которые обесценили более
-поздние правки. Сам проверь ключевые артефакты и решения, которые нельзя
-делегировать. Обнови файл-задачу. Коммит делай только по просьбе
-пользователя. После завершения всех агентов перенеси нужные долговечные
-артефакты по правилам проекта и удали только обменный каталог этого прогона.
-
-Этап завершён, когда критерии приёмки закрыты, финальные счётчики известны,
-неназванных изменений нет, а пользователь получил краткий итог.
+[полевые заметки](references/field-notes.md) и проверь живые предположения.
 
 ## Сбои координации
 
-- После запуска жди через `wait_agent` с реалистичным сроком только когда
-  результат блокирует следующий шаг. Тайм-аут, idle и сводка об обновлении
-  не являются результатом; не засоряй историю статусными пингами.
-- Агент завершился без отчёта: сначала проверь сохранённый файл, затем один
-  раз запроси короткий итог через `followup_task`. После повторной тишины
-  подними свежего агента с файлами задачи и уже собранного индекса.
-- При блокировке перенеси нужные для продолжения данные в долговечный
-  артефакт по правилам проекта и удали остальной обменный каталог прогона.
-- Агент вернул длинный рассказ: не тащи его дальше. Попроси повторить ответ по
-  договору возврата.
-- Два писателя пересеклись: останови их, установи владельца каждой правки и
-  продолжи одним исполнителем от проверенной точки отсчёта.
-- Находки не становятся слабее по раундам: останови цикл и вынеси пользователю
-  противоречие или неверно выбранную границу задачи.
+- Агент завершился без ожидаемого файла: один раз запроси короткий итог в том
+  же треде; после повторной тишины продолжи свежим агентом от сохранённых
+  артефактов.
+- Агент вернул длинный рассказ в сообщение: попроси повторить ответ индексом и
+  путём, не переноси рассказ дальше.
+- Два исполнителя пересеклись в исходниках: останови их, установи одного
+  владельца и продолжи от проверенного состояния, не откатывая чужие правки.
+- Находки не становятся слабее по раундам: если аргументы исчерпаны, вынеси
+  пользователю противоречие, риск или неверную границу задачи.
+- После завершения сохрани только предусмотренные проектом долговечные
+  решения и удали временные артефакты именно этого прогона.