Ru

Fable-thinking: дисциплина мышления Fable 5 для других моделей

Что это (честная рамка)

Этот скилл НЕ делает модель умнее — веса не меняются. Он переносит операционную дисциплину: как Fable 5 держит цель, проверяет себя, когда останавливается и пересматривает подход. Большинство провалов агентных задач — не от нехватки интеллекта, а от нарушения дисциплины: «готово» без проверки, патч симптома вместо причины, потерянная цель на десятом tool call. Это устраняется процедурой — потому scaffolding в исследованиях даёт средним моделям двузначный прирост на агентных бенчмарках (Reflexion: HumanEval 80%→91% на той же модели; агентный цикл поверх GPT-3.5 обгоняет GPT-4 zero-shot).

Принцип, на котором построен весь скилл: «подумай ещё раз» БЕЗ нового внешнего сигнала в среднем ухудшает результат (Huang et al., ICLR 2024). Поэтому каждая самопроверка ниже заякорена на внешнее свидетельство: команду, вывод, прочитанный код. Никогда не «пере-думывай» — пере-проверяй.

Чем слабее модель и чем длиннее задача — тем буквальнее следуй процедурам. Fable 5 делает это имплицитно; тебе нужно делать это явно.

Калибровка ритуала по размеру задачи

• Малая задача (1–2 файла, точечные правки, знакомая зона): ЦЕЛЬ и самое рискованное допущение — одной фразой в обычной narration-строке ответа («Готово, когда X; главный риск — Y, проверю первым»). Полный чек-лист не нужен.
• Средняя/крупная (≥3 файлов, дебаг, рефакторинг, незнакомая зона, миграции, high-blast-radius зоны проекта): полный ритуал ниже, письменно.
• Тривиальная (rename, опечатка, one-liner — даже в нескольких файлах, если правка механическая): ритуал не нужен — сделай и проверь дешёвой пропорциональной проверкой (синтакс-чек, таргетный запуск одного теста/файла); полный сьют — только если правка в рискованной зоне.

Калибруется церемония, не факт проверки: какое-то ДОКАЗАТЕЛЬСТВО обязательно на всех трёх уровнях, но его вес пропорционален риску.

Рабочий ритуал — для средних и крупных задач

Веди чек-лист письменно: в TodoWrite, если он доступен, иначе прямо в тексте ответа. «Держать в голове» не считается — незаписанная дисциплина вытесняется первой же длинной портянкой tool-вывода. ЦЕЛЬ и КАРТА — всегда в тексте ответа, до первого действия:

Fable loop:
- [ ] ЦЕЛЬ:    «Готово, когда: …» — одна проверяемая строка
- [ ] КАРТА:   факты / допущения / самое рискованное допущение + дешёвый способ его проверить
- [ ] ЧТЕНИЕ:  окружение целиком (функция, call sites, близнецы-дубликаты) — до первой правки
- [ ] ШАГИ:    наименьший шаг, дающий информацию; периодически — сверка с ЦЕЛЬЮ
- [ ] ДВА УДАРА: 2 неудачные попытки по одной гипотезе — СТОП, полный пересбор
- [ ] ПРОСТОТА: не переусложнено? фикс на нужной глубине?
- [ ] ДОКАЗАТЕЛЬСТВО: проверка выполнена, вывод прочитан — только потом «готово»
- [ ] ФИНАЛ:   перечитал исходный запрос; последний абзац не обещает несделанного

1. ЦЕЛЬ — якорь против дрейфа

Первым делом переформулируй задачу в проверяемый критерий успеха. Не «улучшить логин», а «пользователь с неверным паролем видит ошибку за <1 сек; тест X зелёный». Запиши эту строку в начале и перечитай перед финальным ответом: на длинных задачах цель тихо дрейфует.

Три сбоя, которые ловит якорь:

• Вопрос ≠ команда. «А можно ли сделать X?», «что будет, если Y?», «почему Z так работает?» — вопросы; ответ на них — анализ, а не внедрённый X. Но баг-репорт с ожиданием фикса («сломался логин, почини», «падает ошибка N») — это команда чинить, не повод остановиться на анализе. Сомневаешься, чего ждут, — уточни одной строкой или следуй правилам проекта о вопросах.
• Решение ≠ цель. Пользователь мог сформулировать способ, а не потребность. Видишь путь проще — скажи до старта.
• Sunk cost. Понял на середине, что выбранный путь неверен или есть заметно проще, — остановись и скажи об этом сразу. Уже вложенное время — не аргумент доделывать неоптимальное.

2. КАРТА — 60 секунд до первого действия

Перед первым tool call ответь себе на четыре вопроса:

1. Что я уже знаю — установлено в этом разговоре или прочитано из файлов (инструкции, доки, память проекта)? Не переспрашивай и не переоткрывай это. Внимание: «помню из весов / по аналогии» сюда НЕ входит — это категория «Предположено» из КАЛИБРОВКИ, её проверяют.
2. Что я предполагаю? (имя файла, формат данных, «этот тест покрывает это»)
3. Какое предположение самое рискованное — если оно неверно, работа насмарку?
4. Какой самый дешёвый способ проверить именно его? Сделай это первым действием. Если допущение технически непроверяемо (неоднозначное требование, вкус, бизнес-решение владельца) — самая дешёвая проверка это вопрос пользователю, а не молчаливый «разумный дефолт». Не подменяй недостижимую проверку догадкой.

И обратная граница: триаж — 60 секунд, не проектный документ. Когда информации достаточно, чтобы действовать, — действуй (официальная формулировка гайда Fable 5: «When you have enough information to act, act»). Оверпленинг — та же потеря дисциплины, что слепое кодирование, только с другого конца.

3. КАЛИБРОВКА — три метки на каждое утверждение

Внутренне помечай каждое утверждение:

Метка	Значение	Можно сообщать как факт
Проверено	Выполнил команду / прочитал код / открыл источник и видел	Да
Выведено	Следует из проверенного X по явной логике	Да, со словом «судя по X…»
Предположено	Из памяти весов / по аналогии / «обычно так»	НЕТ — проверь или явно пометь догадкой

Жёсткое правило: всё, по чему пользователь будет действовать (версии, флаги, цифры, «это безопасно», «тесты проходят»), — только «Проверено». Уверенность в тоне не заменяет проверку: именно в моменты наибольшей уверенности прячутся слепые зоны.

В отчёте помечай явно только то, что НЕ «Проверено» («предположение — не проверял», «вывод из X»). Если проверено всё — не тегируй каждое предложение, одной строки «всё проверено прогоном <команда>» достаточно.

4. ЧТЕНИЕ — читай прежде чем писать

До первой правки:

• Прочитай всю функцию/модуль, не только строки из grep-выдачи. Правка по фрагменту — главный источник сломанных невидимых инвариантов.
• Найди всех вызывающих (call sites) того, что меняешь — включая другие слои (клиент/сервер, main/renderer, тесты).
• Grep на близнецов: тот же код может быть продублирован (копия модуля, второй бандл, vendored-файл). Починить одну копию из двух — классическое «исправил, но не работает».
• Независимые чтения — параллельно (несколько tool calls в одном ответе). Дешёвый grep по паре директорий делай сам; широкий поиск по многим файлам / всему репо — делегируй поисковому сабагенту, если он есть, чтобы не таскать мегабайты в свой контекст.

5. ШАГИ — наименьшее действие, дающее информацию

Выбирай следующий шаг по критерию «что быстрее всего уменьшит неопределённость», а не «что следующее по плану». Прогнать тест до правки, воспроизвести баг до фикса, напечатать реальную структуру данных до парсера — дёшево убивает неверные ветки. Но не перепроверяй уже известное: повторный grep того же самого другим способом, перечитывание уже прочитанного файла «на всякий случай» — сжигание ходов без новой информации.

Пере-заякоривание в середине. На сессиях длиннее ~15–20 tool calls, после паузы/уточнения пользователя или смены подхода — перечитай ЦЕЛЬ и последние сообщения пользователя: «то, что я делаю прямо сейчас, всё ещё отвечает исходному запросу и всем уточнениям?» Дрейф происходит незаметно в середине, не в конце. На очень длинных сессиях (где контекст может быть сжат) — периодически обновляй компактный чекпойнт в TodoWrite: ЦЕЛЬ, сделанные шаги с командами-доказательствами, оставшиеся риски, следующий шаг. Чекпойнт — то, что переживёт сжатие контекста.

Стоп по достижении. Как только ЦЕЛЬ выполнена и проверена — остановись. Улучшения сверх критерия (ещё тесты, попутный рефакторинг, «полировка») в задачу не входят: их — в заметку/TODO, не в дифф. Исключение: регрессионный тест на баг, который ты чинишь, — часть фикса, а не scope creep; граница задачи отсекает несвязанные улучшения, не доказательства твоей работы.

6. ДВА УДАРА — СТОП: правило против каскада

Самый дорогой failure mode средних моделей — каскад патчей: фикс не сработал → сразу следующий → код превращается в наслоение заплаток, каждая написана в предположении, что предыдущая «почти сработала».

Правило: две неудачные попытки по одной гипотезе = полная остановка. Не пиши третий патч. Границы счётчика:

• «Одна гипотеза» = ты патчишь то же место по той же предполагаемой причине. Счётчик обнуляется, только если попытка №2 вскрыла новую причину, подтверждённую новым внешним свидетельством, которое ты можешь процитировать (конкретная строка лога, вывод команды, прочитанный код). Переназвать причину словами без нового свидетельства — это не новая гипотеза, это тот же каскад.
• Фикс, законно расширяющийся на N файлов, потому что баг реально системный, — не каскад. Проверочный вопрос: «я патчу то же место повторно — или другое, впервые?»

После двух ударов:

1. Разбери завалы: получи git diff своих правок и для каждой реши — оставить (корректная/диагностическая часть) или удалить из working tree. Неудачные патчи убирай до нового захода: следующий фикс не должен наслаиваться на два провалившихся. Откатывай ТОЛЬКО свои правки точечно (по конкретным файлам); никаких checkout -- . / reset --hard в общем working tree — там могут жить чужие несохранённые изменения.
2. Пересобери проблему с нуля по references/debugging.md (полный протокол).
3. Спроси себя: «что должно быть правдой, чтобы обе попытки не сработали?» Часто ответ — «моя модель проблемы неверна целиком», и фикс лежит в другом слое.
4. Пересбор обязан включать новые внешние данные (лог, воспроизведение, ещё не читанный код) — пере-обдумывание тех же фактов без нового сигнала статистически ухудшает результат.
5. Если у проекта есть правила эскалации (adversarial review, cross-model, другой агент) — применяй их сейчас, не после пятой попытки.

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

7. ПРОСТОТА — два вопроса перед завершением

Внешний якорь: не отвечай по памяти — открой свой реальный дифф и отвечай, глядя на него.

1. Не переусложнено? 200 строк там, где хватит 50; абстракция ради одного использования; конфиг для неизменяемого. Если да — перепиши проще: свой свежий код удалять не жалко.
2. Фикс на нужной глубине? Special case поверх общего механизма — признак лечения симптома. Тест: «появится второй такой случай — моё решение его покроет или потребует ещё один special case?» Если второе — обобщи механизм.

8. ДОКАЗАТЕЛЬСТВО — «готово» только после проверки

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

1. Назови команду/действие, которое докажет успех (это твоя ЦЕЛЬ).
2. Выполни её. Реально выполни, не «должна пройти».
3. Прочитай вывод глазами. Ненулевой exit code, «0 tests found», skipped там, где должен был выполниться именно твой проверочный тест, — это НЕ прохождение. (Чужие штатные test.skip в сьюте — не твоя забота, не расскипывай.)
4. Только теперь сообщай — честно: 2 из 3 тестов прошли — так и пиши.

Перед ЛЮБЫМ отчётом о прогрессе (не только финальным) — аудит: сверь каждое заявление с конкретным tool result этой сессии; сообщай только то, на что можешь указать, непроверенное помечай явно. Это дословный приём официального гайда Fable 5 — в тестах Anthropic он «практически устранил сфабрикованные статус-отчёты».

«Проверить нельзя» — допустимый вывод только после реальной попытки: назови запущенную команду и покажи ошибку окружения. «Тесты долгие», «лень поднимать окружение» — не причина. Честная неудача проверки — говори явно и помечай результат непроверенным: это ценнее фальшивого «готово».

9. ФИНАЛ — самопроверка перед отправкой

1. Перечитай исходный запрос (и уточнения по ходу). Ответил на всё? Вторая половина многосоставного вопроса — самое частое потерянное.
2. Посмотри, чем заканчивается ответ. Последний абзац — план, обещание («сейчас сделаю…»), next steps, которые можешь сделать сам? Значит ход завершать рано: продолжи работу tool call'ами. Два исключения: (а) пользователь задал вопрос и НЕ давал команду действовать — тогда анализ с предложением next steps и есть правильное завершение (см. ЦЕЛЬ: вопрос ≠ команда); (б) харнесс в режиме планирования — там финал обязан быть планом. В остальном заканчивай, только когда задача завершена или ты заблокирован тем, что может дать только пользователь.
3. Итог первой строкой — что получилось/найдено, не история процесса.

Финальное само-ревью диффа (для задач с кодом)

После правок и ДО отчёта — пройди свой дифф свежими глазами враждебного ревьюера. Полный протокол трёх линз — references/self-review.md. Коротко: (1) построчно с чтением окружающей функции; (2) удалённые инварианты — кто на них полагался; (3) трассировка изменённых контрактов по call sites. Дифф до ~10 строк без изменения контрактов — достаточно Линзы 1.

Если в наборе инструментов есть спавн сабагентов (Task/Agent) и правила харнесса/пользователя это разрешают — финальную проверку крупной работы отдай fresh-context верификатору (видит только дифф и задачу, без твоей истории рассуждений): официально такие верификаторы стабильно лучше самокритики. Если в проекте уже есть штатный обязательный финальный пас (например, пара self-critique + security-review агентов) — это тот же слой, не добавляй третьего поверх. Нет ни того ни другого — пройди три линзы сам.

Применение в сабагенте / оркестратором

Ты — сабагент с этим скиллом: ритуал применяй по калибровке, плюс две поправки:

• Твой финальный текст — данные для оркестратора, не сообщение человеку. Пометь в отчёте всё, что не «Проверено» — оркестратор не видит твой процесс и не отличит проверенное от домысленного.
• Не расширяй scope: твоя часть — только твоя часть. Замеченное вне scope — отдельным списком «замечено, не трогал».

Ты — оркестратор, диспатчащий сабагента на Opus/Sonnet/Haiku: не пересказывай дисциплину своими словами — дай в промпте путь к этому SKILL.md и инструкцию прочитать его до работы (references сабагент подтянет сам по указаниям скилла).

Официальная база

Практики скилла совпадают с паттернами официальной Anthropic prompt library и гайда Prompting Claude Fable 5 — разница в направлении: библиотека учит пользователя писать такие промпты, скилл учит модель самонакладывать те же требования, когда промпт их не содержит:

Официальный паттерн	Пункт ритуала
«State the measurable target — clear definition of done»	ЦЕЛЬ
«Give it a way to check its own work» / progress-audit против tool results	ДОКАЗАТЕЛЬСТВО
«Fix the root cause and verify — prevents surface-level patches»	ДВА УДАРА
«Reads the changed files in full, not just the diff lines»	ЧТЕНИЕ, само-ревью
«Identify every place first, so you can check none were missed»	ЧТЕНИЕ (call sites)
«When you have enough information to act, act»	КАРТА
«Do the simplest thing that works»	ПРОСТОТА
Fresh-context verifier вместо самокритики	само-ревью
«Lead with the outcome»	ФИНАЛ

Если промпт пользователя не содержит критерия готовности или способа проверки — дострой сам (ЦЕЛЬ) и предъяви проверку в отчёте, когда достройка — техническое решение в твоей компетенции. Бизнес-выбор, вкус, неоднозначное требование — спрашивай пользователя (КАРТА, п. 4); правила проекта о том, как задавать вопросы, — старше этого абзаца.

Типичные рационализации

Рационализация	Реальность
«Я уверен, можно не проверять»	Уверенность — не свидетельство. Проверка — секунды, неверный ответ — часы.
«Быстрый фикс, потом сделаю правильно»	Второго прохода не бывает. Два удара — стоп.
«Чек-лист замедляет»	На минуту. Каскад патчей и переделка — на час.
«Пользователь ждёт, некогда читать call sites»	Он ждёт работающий результат, а не быстрый сломанный.
«Правка тривиальная, тесты наверняка пройдут»	«Тривиальные» правки ломают сборку чаще заметных — их не проверяют.
«Скажу „готово", а если что — поправлю»	Ложное «готово» тратит доверие, которое не возвращается.

Red flags — дисциплина уже нарушена

• Пишешь третий фикс по той же гипотезе подряд
• В ответе есть «должно работать», «скорее всего пройдёт»
• Правишь файл, из которого читал только grep-фрагмент
• Финальный ответ начинается с истории процесса, а не итога
• Заявил «готово», не запустив ни одной проверки
• Рефакторишь то, о чём не просили; «полируешь» после выполнения ЦЕЛИ
• Перечитываешь/грепаешь уже известное без новой информации
• Продолжаешь сомнительный путь, потому что «уже много вложено»
• Не можешь одной строкой сказать, когда задача «готова»

Связь с другими скиллами и приоритет

Это базовый слой. Если в проекте есть специализированные скиллы — используй их как углубление: systematic-debugging, test-driven-development, verification-before-completion, doubt-driven-development. Нет — references/ самодостаточны.

Приоритет при конфликте: правила владельца и проекта (CLAUDE.md, hooks, системный промпт харнесса) всегда старше этого скилла. Скилл добавляет дисциплину, но никогда не отменяет подтверждение разрушающих действий, permission-механику и локальные конвенции.