Playbooks

Это playbook’и для управления работой coding/knowledge agent, а не встроенные skills production runtime и не MCP primitives. Playbook — не «магический промпт», а короткий договор о повторяемом процессе: что агент получает на входе, какие решения принимает, чем доказывает результат и когда обязан остановиться. Его копируют не дословно, а адаптируют к риску задачи.

Сначала сформулируйте контракт задачи, затем выберите playbook. Для долгой работы ведите контекст и журнал решений, а уровень самостоятельности задавайте через guardrails.

1. Начать новый проект

Нужно на входе: проблема и пользователь; желаемый результат; ограничения по времени, стеку и эксплуатации; известные неизвестные.

Процесс:

1. Отделить потребность от предложенного решения.
2. Предложить 2–3 подхода с выигрышем, ценой и условиями отказа.
3. Зафиксировать выбранный подход, non-goals и архитектурные границы.
4. Разбить работу на проверяемые вертикальные срезы.
5. Для первого среза определить acceptance criteria и самый дешёвый способ проверки.

Артефакты: problem statement, decision record, high-level plan, список рисков.

Стоп: не начинать реализацию, если неизвестен пользовательский outcome или подход ещё не выбран.

2. Разобраться в существующей системе

Нужно на входе: репозиторий или директория; вопрос, на который должен ответить обзор; допустимая глубина исследования.

Процесс:

1. Прочитать локальные инструкции, README, manifest и CI.
2. Построить карту: entry points → основные модули → данные → внешние системы → доставка.
3. Запустить документированные проверки без изменений исходников.
4. Сверить документацию с наблюдаемым поведением.
5. Разделить факты, выводы и неизвестное; указать evidence для ключевых утверждений.

Артефакты: карта системы, baseline, список расхождений, вопросы и риски.

Стоп: не предлагать рефакторинг, пока не понятны назначение системы и её фактические проверки.

3. Спроектировать изменение

Нужно на входе: согласованный outcome, карта затрагиваемой системы, ограничения совместимости.

Процесс:

1. Найти минимальный полезный срез и blast radius.
2. Сначала определить внешнее поведение и контракты, затем внутреннюю реализацию.
3. Сравнить варианты; проверить миграцию, rollback и порядок доставки.
4. Превратить acceptance criteria в тестовые сценарии.
5. Получить решение человека только там, где выбор меняет продукт, риск или стоимость.

Артефакты: design note, контракты, план миграции, тестовая матрица.

Стоп: не писать код при неразрешённом продуктовом выборе или несовместимом контракте без стратегии перехода.

4. Диагностировать дефект

Нужно на входе: наблюдаемый и ожидаемый результат, окружение, минимальные шаги воспроизведения, доступные логи.

Процесс:

1. Воспроизвести дефект и сохранить исходное evidence.
2. Сузить область: где последняя верная postcondition и первая неверная.
3. Записать проверяемые гипотезы, начиная с самой дешёвой.
4. Провести различающий эксперимент для каждой гипотезы.
5. Исправить подтверждённую причину; добавить regression check.

Артефакты: reproduction, журнал гипотез, root cause, regression test.

Стоп: не менять систему ради неподтверждённой догадки; эскалировать, если дефект не воспроизводится и evidence исчерпано.

5. Реализовать и проверить

Нужно на входе: утверждённый план, acceptance criteria, разрешённая область записи, команды проверки.

Процесс:

1. Зафиксировать baseline и состояние рабочей копии.
2. Для изменения поведения сначала получить failing check.
3. Делать один связный срез за раз: test → implementation → refactor.
4. После каждого среза запускать узкие проверки, в конце — полный набор.
5. Сравнить результат с контрактом задачи, а не только с зелёными тестами.

Артефакты: небольшой diff, тесты, команды и результаты проверки, заметка о миграции.

Стоп: остановиться при неожиданном пользовательском изменении, расширении scope или необходимости разрушительного действия вне контракта.

6. Провести review

Нужно на входе: исходная задача, diff, план и результаты проверок.

Процесс:

1. Проверить сохранение intent и полноту acceptance criteria.
2. Искать ошибки корректности, безопасности, совместимости и восстановления.
3. Проследить жизненный цикл данных и побочных эффектов через границы системы.
4. Проверить тесты на способность поймать дефект, а не на факт существования.
5. Отделить blocking findings от улучшений вкуса; для каждого finding дать точное evidence.

Артефакты: findings с severity, файлом/строкой, сценарием отказа и недостающей проверкой.

Стоп: не утверждать изменение при необъяснённом высоком риске или отсутствии обязательного evidence.

7. Исследовать вопрос

Нужно на входе: решение, которое исследование должно поддержать; срок актуальности; допустимые источники.

Процесс:

1. Разложить вопрос на проверяемые утверждения.
2. Сначала искать первичные и актуальные источники.
3. Вести evidence ledger: claim → source → дата → уверенность.
4. Различать подтверждённые факты, интерпретации и рекомендации.
5. Синтезировать вывод вокруг решения, включая противоречия и неизвестное.

Артефакты: короткая записка, таблица evidence, рекомендация с условиями пересмотра.

Стоп: не выдавать рекомендацию за факт; пометить пробел, если надёжного источника нет.

8. Передать работу другому агенту или человеку

Нужно на входе: текущий контракт, состояние системы, выполненные и оставшиеся шаги.

Процесс:

1. Начать с текущего outcome и состояния, а не с хронологии чата.
2. Перечислить принятые решения и почему альтернативы отвергнуты.
3. Дать точные файлы, команды, evidence и незавершённые риски.
4. Указать следующий безопасный шаг и stop conditions.
5. Проверить handoff retrieval-вопросами: «что делать дальше?», «что нельзя менять?», «как понять, что готово?»

Артефакт: handoff note по шаблону:

Outcome:
Current state:
Decisions:
Changed artifacts:
Verification evidence:
Open risks / unknowns:
Next safe step:
Do not:

Стоп: не передавать работу формулировкой «всё в истории чата».

9. Сжать документ без потери информации

Полная методика и шаблоны находятся в разделе Document compression.

Нужно на входе: документ, его аудитория, обязательные semantic invariants и допустимые преобразования.

Процесс:

1. Составить inventory атомарных утверждений, решений, исключений и ссылок.
2. Удалить повторы и церемониальные фразы; нормализовать термины и структуру.
3. Построить coverage matrix «исходный claim → место в новой версии».
4. Проверить новую версию вопросами, ответы на которые должен сохранять документ.
5. Отдельно перечислить намеренно удалённое; при сомнении восстановить смысл.

Артефакты: сжатый документ, coverage matrix, verification note.

Стоп: не объявлять сжатие lossless только потому, что текст стал короче.

Мини-шаблон любого playbook

Outcome:
Inputs and authority:
Process:
Artifacts:
Acceptance evidence:
Escalation triggers:
Stop conditions:

Хороший playbook снижает число импровизированных решений, но оставляет видимыми места, где требуется суждение. Если процесс регулярно ломается одинаково, исправляйте playbook или системное ограничение — не наращивайте промпт предупреждениями.