Остров claude.dev

Задача: Выбрать между Sonnet 5.5 и Opus 5.5, настроить effort/thinking и перейти с Sonnet 5 на Sonnet 5.5

Правила

Выбор модели

• Sonnet 5.5 — чётко очерченные повседневные задачи: багфиксы, быстрые итерации по фиче, проверка по требованиям, документы/слайды/таблицы, повторяемые агентные задачи (разведка, ревью, черновики), высокообъёмная разработка.
• Opus 5.5 — сложная работа, требующая осторожного суждения, долгие агентные задачи, самые трудные проблемы. Цитата из гайда: «for the hardest long-horizon work, an Opus model is the better choice».
• Sonnet подходит лучше всего, когда есть чёткая спецификация и способ проверить результат.
• Haiku 5.5 — «в ближайшие недели», для высокообъёмных задач с низкой задержкой.

Цены (за 1M токенов, Sonnet 5.5 / Opus 5.5)

• Вход: $2 / $4. Выход: $10 / $20.
• Запись кэша 5 мин: $2.50 / $5. Запись кэша 1 час: $4 / $8. Чтение кэша: $0.20 / $0.20.
• Цена за токен как у Sonnet 5; счёт меняется из-за меньшего числа токенов на задачу (до 30% дешевле на большинстве работ).
• US-only инференс (`inference_geo: "us"`) — ×1.1.
• Изображения: высокое разрешение до 2576 px по длинной стороне; 2000×1500 ≈ в 2.5 раза дороже, чем на Sonnet 4.6/4.5/Haiku 4.5. Деталь не нужна — уменьшай перед отправкой.

Параметры модели

• ID: `claude-sonnet-5-5` (Bedrock: `anthropic.claude-sonnet-5-5`).
• Контекст 1M нативно, без beta-заголовка. Максимум вывода 128k (до 300k в Batches API с beta-заголовком).
• Мышление включено по умолчанию (adaptive). Читать блоки ответа по типу, а не `content[0].text`.
• Effort: low / medium / high / xhigh / max. По умолчанию high в Claude API, medium в Claude Code.
• Минимум для кэширования: 512 токенов (было 1024).

Миграция с Sonnet 5

• Сменить ID модели, затем пройти пять ломающих изменений и одно изменение формы ответа.
• `thinking: {"type": "disabled"}` → 400. Вместо него `between_tools`: работает на low/medium/high; на xhigh/max — 400; других полей не принимает (`display`, `budget_tokens`, `block_binding` → 400); effort нельзя менять посреди диалога.
• `tool_choice` типов `any`/`tool` → 400. Использовать `auto` + `strict: true` у инструмента + указание в промпте, когда его вызывать; нужен `additionalProperties: false` на каждом объекте.
• Диалоги держать append-only: блоки мышления привязаны к модели и диалогу; Sonnet 5.5 читает блоки Sonnet 5, другие модели блоки Sonnet 5.5 не читают.
• Computer use: только `computer_toolset_20260801`; `computer_20251124` → 400; убрать beta-заголовки.
• Advisor: исполнитель Sonnet 5.5 отвергает Opus 4.8, Opus 4.7 и Sonnet 5; принимает Opus 5.5, Opus 5 и Sonnet 5.5. Ответ советника зашифрован (`advisor_redacted_result`).
• Текст между вызовами инструментов приходит в thinking-блоках (при display по умолчанию пустые): для adaptive задать `thinking.display` = `updates` (beta) или `summarized`; для `between_tools` — без `display`.
• Автомиграция: `/claude-api migrate this project to claude-sonnet-5-5`.

Настройка effort

• Уровни перекалиброваны — прогнать sweep заново, старое значение не переносится.
• Агентный код и многошаговые инструменты: medium для чётких задач, high для сложных/длинных. Чат и чувствительное к задержке: medium или low. xhigh/max — только если evals показывают прирост.
• Мышление входит в `max_tokens`: для агентного кода ставить 128 000 и стримить.
• Меньше мышления — снижать effort; просьба в системном промпте «думай меньше» работает ненадёжно.
• xhigh/max: дольше и дороже, можно потерять баланс Sonnet — тогда рассмотреть Opus 5.5.

Очистка и проверки

• Убрать обходные приёмы под Sonnet 5 (стиринг отказов, шимы ретраев инструментов, «do not be lazy») и перезапустить evals до любой другой настройки.
• На low effort Sonnet иногда пропускает реальную проверку: добавить в системный промпт абзац «запусти реальную проверку (тесты/тайп-чекер/сборка/сама команда); проверка только синтаксиса не считается; зависимости — через штатный менеджер проекта и локфайл, не sudo; если проверку сделать нельзя — сказать какую и почему».
• Не просить модель выписывать рассуждения в ответе — это вызывает отказы `reasoning_extraction`; прогресс читать через `thinking.display: "summarized"` (или `"updates"`, beta).

Кэш и отказы

• Чтение кэша стоит 1/10 цены входа.
• Смена верхнеуровневого effort между запросами сбрасывает кэш; для одного хода на другом уровне — per-message effort (beta), кэш сохраняется.
• Отказ приходит как HTTP 200 с `stop_reason: "refusal"`; `stop_details` — одна из пяти категорий: cyber, bio, frontier_llm, reasoning_extraction, general_harms.
• Серверный fallback (`fallbacks: "default"`, beta) повторяет только cyber и frontier_llm на Sonnet 5; остальные три не повторяет. Есть также SDK-middleware или свой ретрай.

Claude Code

• С v2.1.284 (Agent SDK TS v0.3.284+) алиас `sonnet` = Sonnet 5.5; по умолчанию medium effort, 1M контекст.
• Мышление отключить нельзя; fast mode у Sonnet 5.5 нет; модель по умолчанию остаётся Opus 5.5, для чётких задач — `/model sonnet`.

Куда применить у нас

• Агентная разработка (Claude Code, Hermes, скилл-пак): по умолчанию `/model sonnet` для багфиксов, ревью, разведки и черновиков; Opus 5.5 — для долгой агентной работы на часы. Из промптов скиллов и агентов убрать костыли под Sonnet 5 («do not be lazy», шимы ретраев, стиринг отказов) и перезапустить проверки. В скилл/системный промпт добавить абзац про реальную проверку перед «готово». Модель не менять посреди сессии (смена сбрасывает кэш; про смену effort — подтверждено, про смену модели в статье — не подтверждено).
• Hermes и собственные агенты на API: если код читает `content[0].text` — переписать на обход блоков по типу; проверить `thinking: disabled`, принудительный `tool_choice`, advisor-пару, `computer_20251124` — всё это даёт 400. Блоки мышления передавать обратно без изменений; для показа прогресса — `thinking.display`.
• GameHub (NestJS + Postgres, античит-формула): при вызовах Claude из бэкенда ставить `strict: true` + `auto` вместо принудительного `tool_choice`. Использовать ли Sonnet 5.5 для ревью античит-формулы и начислений — в статье не подтверждено; Sonnet подходит там, где есть чёткая спецификация и способ проверки, для решений с последствиями статья рекомендует Opus.
• Контент-каналы: Sonnet 5.5 назван подходящим для документов, слайдов, таблиц и черновиков; для постов и сценариев роликов — вывод из этого правила, прямо в статье соцсети не упомянуты. Для коротких задач с задержкой — medium/low effort. Скриншоты уменьшать перед отправкой (×2.5 токенов на изображение 2000×1500).
• v3ko.ru: прямой привязки в статье нет (не подтверждено). Единственный вывод из текста: Sonnet 5.5 назван сильным в дизайне и полировке документов — годится для быстрых итераций по статичным страницам; правки дизайна всё равно согласовывать с владельцем.

Проверки

• ☐ Код читает ответ обходом блоков по типу (`block.type == "text"`), а не через `content[0].text`; блоки мышления возвращаются в диалог без изменений.
• ☐ В запросах нет `thinking: {"type": "disabled"}`, принудительного `tool_choice` (`any`/`tool`), `computer_20251124` и несовместимых advisor-моделей — ни одного ответа 400.
• ☐ Effort-sweep прогнан заново на evals; xhigh/max включены только там, где evals показали прирост; для агентного кода `max_tokens` = 128 000 со стримингом.
• ☐ Из промптов убраны «do not be lazy», шимы ретраев и стиринг отказов, evals перезапущены; в отчётах агента нет «готово» без вывода тестов/сборки.
• ☐ Обработка отказов смотрит на `stop_reason: "refusal"` и `stop_details`; кэш-попадания не падают из-за смены top-level effort между запросами.

Задача: Строить оценку (eval) под своё приложение или скилл и улучшать систему по ней без самообмана и переобучения

Правила

Какой должна быть оценка

• Четыре признака хорошего eval: задачи повторяют продакшен; качество растёт на более сильных моделях и при большем усилии; есть «проходимый» запас сверху; низкий разброс между прогонами.
• Запас: сильнейшая модель на максимальном усилии заметно ниже 100%. Задача, которая падает в каждом прогоне при любом числе повторов, — признак невозможной или двусмысленной.
• Хорошая задача: два эксперта дают один вердикт, всё, что проверяет грейдер, сказано в задании.
• Разброс часто от двусмысленных задач, нестабильного грейдера, неравномерно применённого усилия, остаточного состояния от прошлых попыток (файл, git-история подсказывают ответ).

Как подбирать примеры

• Порядок источников: продакшен-транскрипты (сначала спросить про хранение и чувствительные данные) → баг-репорты и тикеты → 5–10 кейсов вручную → синтез из кодовой базы.
• Сложные кейсы брать потому, что человек счёл их сложными, и уметь сказать почему. Не брать кейсы только потому, что их проваливает сегодняшняя модель (получится «отпечаток провалов» одной модели).
• Трафик пользователей слепо не доверять: он может быть перекошен в лёгкую сторону.
• Все входы показать человеку и дождаться подтверждения.

Грейдер

• Самый дешёвый подходящий: код (точное совпадение, метка из набора, JSON по схеме, тесты) при ограниченных ответах; LLM-судья при открытых.
• Судья: рубрика из проверяемых утверждений, не шкала 1–5; возвращает оценку с обоснованием; при сравнении с базой — оба варианта в случайном порядке без указания, какой базовый; модель судьи не та, что тестируется.
• Прочитать выборку оценённых транскриптов до того, как верить грейдеру: ошибки оценки — частая поломка eval.
• Диагностика на базовом прогоне: грейдер дважды на одном выводе (изменился ли вердикт); таймауты, ошибки API, обрезанные ответы; запас — при базе ≈95% и выше цель hillclimb смещается на стоимость или задержку.
• Перед стартом сообщить размер набора (кейсы × повторы × модель) и время; результат — балл с доверительным интервалом.

Где применять hillclimb

• Дешёвая итерация: текст (промпты, скиллы) легко менять и откатывать; правки обвязки агента — дорогие.
• Атрибутируемость: изменение балла должно объясняться правимой поверхностью (пример — частота срабатывания скилла и его описание).
• Чёткая цель: открытое «улучши» на насыщенном eval застревает. Сильная цель — стоимость при паритете качества.
• Правимое: системный промпт, скиллы/инструкции, описания инструментов, модель/усилие/параметры API, код обвязки.

Защита от переобучения

• Случайно делить набор на train (hillclimber читает) и test (никогда не видит). Train растёт, test стоит — предупреждение.
• Содержимое провалов в промпт не вставлять.
• Ответы структурно вне досягаемости модели (иначе reward hacking).
• Перед первым раундом: шум eval меньше минимального улучшения, на которое готовы действовать; иначе больше повторов или кейсов.

Цикл раунда

• Раунд: прочитать train-транскрипты → один патч → прогон. Train и test выросли — оставить; train вырос, test плоский — откат; регрессия — откат.
• Править первопричину (переписать секцию, добавить недостающее правило), а не переформулировать строку.
• Застой 2–3 раунда: правок нет, только разбор оставшихся провалов по причинам. Ловит двусмысленные кейсы, ошибки обвязки, разброс. В дальнейшие раунды идут только законные провалы.
• Итог: версия с лучшим результатом на test, отчёт против базы с интервалами; прирост в пределах шума — не мержить.

Цифры из статьи

• Поддержка: 44 тикета (30 поиск / 14 отложенных). Старт: Opus 4.8, высокое усилие, 74,4%, 4,6 цента/тикет.
• Аудит промпта + Opus 5.5 low: 87,8%, 1,9 цента. Sonnet 5 low: 88,9%, 1 цент. После правил маршрутизации: 98,9%.
• Отложенные: 90,5% против 78,6% у исходной, примерно в 5 раз дешевле.
• Скилл claude-api: 66% → 74% (8 недостающих фич) → 77% → 80% (таблица «старая форма → актуальная») → ~88% (исправлены задача и грейдер).

Куда применить у нас

Куда применить

• Агентная разработка (скилл-пак, Hermes): метрику «срабатывает ли скилл» связывать с его описанием (в статье это прямо названо атрибутируемой поверхностью). Править текст скилла, держать test-часть, при застое разбирать провалы по причинам. Запуск `/claude-api build-eval` и `/claude-api hillclimb` в Claude Code — по статье.
• GameHub (античит-формула начислений): вывод из правил статьи, не утверждение автора: кейсы брать из реальных багов и подозрительных начислений, не только из «обычного» трафика (он перекошен в лёгкую сторону). Ответы держать вне досягаемости проверяемого кода. Применимость к самой формуле в статье не подтверждена: там речь о LLM-приложениях.
• Контент-каналы: вывод из правил: у открытого вывода (посты под разные соцсети) грейдер — LLM-судья с рубрикой из проверяемых утверждений, модель судьи другая, чем пишущая; сравнение со старой версией вслепую в случайном порядке. Рубрики под конкретные соцсети в статье не даны — не подтверждено.
• Любой LLM-пайплайн с затратами (в т. ч. монитор RSS на этом острове): цель «стоимость при паритете качества» — аудит промпта, кэширование, подбор модели и усилия; на отложенном наборе проверять, что качество не просело. Применимость к монитору — вывод из правил, в статье не обсуждается.
• v3ko.ru: прямой применимости в статье не найдено — не подтверждено.

Проверки

• ☐ Для каждой задачи набора можно назвать причину сложности, а входы подтверждены человеком; кейсы не отобраны только по провалам одной модели
• ☐ Грейдер дважды на одном выводе даёт тот же вердикт; прочитана выборка оценённых транскриптов; модель судьи не совпадает с тестируемой
• ☐ Базовая оценка ниже ~95%, есть запас; в базовом прогоне нет таймаутов, ошибок API и обрезанных ответов; шум меньше минимально значимого улучшения
• ☐ Набор разделён на train и test; в промпт не вставлено содержимое провалов; патч принят только если выросли оба набора
• ☐ В итоговом отчёте результат на test против базы с доверительными интервалами; прирост в пределах шума не принят

Задача: Выбор уровня effort в Claude Code под тип задачи (Opus 5.5 / Fable 5.1)

Правила

Что такое effort

• Приближённая оценка того, сколько вычислений ты хочешь потратить на задачу; связана с твоей оценкой её сложности.
• Claude всегда делает задачу разумно; высокий effort = больше самостоятельных действий: больше верификации, тестов крайних случаев и собственных суждений (решений за пользователя).
• Смена effort у новых моделей не ломает prompt-кэш в Claude Code. Переключение — `/effort`, можно и посреди разговора.
• Кривые Opus 5.5 и Fable 5.1: на каждом уровне растут и балл на бенчмарке, и расход токенов.

Правило выбора уровня (от автора)

• Low — быстрые ответы, когда ты в цикле: брейншторм, наброски, лёгкие правки.
• Medium — большая часть обычной разработки, например новая фича.
• High — когда важна верификация или много крайних случаев, например баг в brownfield-коде.
• Max — полностью автономная работа над сложным: сборка и проверка приложения «под ключ», поиск уязвимостей в критичном ПО.

Как effort влияет на недоопределённую задачу (тест с фитнес-трекером)

• Low (1,5 мин) — простой лог и график; хорошая база для итераций.
• Medium 4 мин, high 11 мин, max 67 мин — всё больше деталей и больше выборов, сделанных за тебя (на max — тепловая карта).
• Max — когда нужен лучший результат с первой попытки.
• Дизайн-задача (/config): low — 1 мин, набросок передаёт идею; max — 28 мин, отполированный макет. Для понимания «видения» Claude автор предпочёл low.

Чем лучше специфицирована задача, тем меньше разница

• С подробной спецификацией (после интервью) результаты на разных уровнях похожи; время: low 16, medium 22, high 33, max 79 мин.
• На max Claude местами упростил детали.

Цикл для обычной разработки (автор использует сам)

1. Дать спецификацию и попросить Claude проинтервьюировать о недостающих деталях.

2. Реализовать на low.

3. Проверить, что суть верна; итерировать на low.

4. Верификацию и тесты — на high.

Когда высокий effort окупается (Terminal-Bench 3.0)

• Лучше всего — при множестве скрытых крайних случаев: рост pass rate на Fable 5.1 low → top: Security 64→87%, Hardware 34→75%, ML 54→73%, Science 41→61%, Software 43→56%, Media 18→30%, Operations 12→22%.
• html-js-filter (HTML-санитайзер): Fable 5.1 1/5 на low → 5/5 на xhigh. Low: ~2 мин, один проход, один ручной тест-страница. High: ~33 мин — адверсариальное ревью черновика, чтение исходников парсера, стандартный XSS-набор, фаззер.
• Также окупается: оптимизация производительности, security review — сложные задачи с высокими требованиями к продакшену.
• Низкий effort: остановка после пары проверок и предупреждение «может быть медленно» без проверки (cli-2ph-simplex, 0/5 → 5/5 на high). Высокий: сравнение с независимым эталоном, замеры времени, переработка.
• Высокий effort без пользователя в цикле лучше: Claude сам пробует варианты постановки (gsea-proteomics 0/5 → 4/5), тогда как при пользователе мог бы спросить.

Чего effort не лечит

• Снижает сбои из-за пропущенных крайних случаев, но не исправляет неверный подход (wrong approach).
• На Fable 5.1 low → max: 140 → 214 успехов из 370 попыток; «баг, который не поймали тесты» 40 → 14; «выбрал не то прочтение» 25 → 47 (доля выросла, не упала).
• Цифры — внутренние прогоны, по 5 попыток на задачу; с отключёнными защитами для Fable 5.1, задачи безопасности без интернета; категории сбоев определял model judge, они приблизительные.

Куда применить у нас

• Агентная разработка (Claude Code, Hermes, скилл-пак): по умолчанию medium для фич; цикл «интервью → low → ревью → high-проверка». Для агентов Hermes, работающих без человека в цикле, из статьи следует: чем автономнее прогон, тем выше effort (high/max). Конкретные уровни для Hermes — не подтверждено.
• GameHub (начисление токенов, античит-формула): правила про security и крайние случаи делают разумным high для верификации и ревью формулы и API начислений; low — только для набросков игровых сцен на Phaser. Что именно статья советует про античит — не подтверждено, это вывод из «high — где важна верификация».
• v3ko.ru (статичные страницы, тёмная тема): дизайн-эксперимент статьи (/config) показывает: low для быстрого эскиза «видения», затем итерации; max — только если нужен отполированный результат сразу.
• Контент-каналы (посты, дневник, ролики): в статье про контент ничего нет — не подтверждено. Единственный перенос: нужен быстрый черновик в цикле — low, финальная вычитка — выше.
• Остров claude.dev (разборы через `claude -p --model sonnet`): уровень effort для `-p` и Sonnet 5.5 в статье не описан (статья про Opus 5.5 и Fable 5.1) — не подтверждено.

Проверки

• ☐ Для каждой задачи назван уровень по правилу из статьи (low/medium/high/max) и указано, почему: степень участия человека, число крайних случаев, цена ошибки.
• ☐ Реализация шла на low/medium, а верификация и тесты — отдельным проходом на high, а не наоборот.
• ☐ На задачах с крайними случаями (санитайзеры, начисления, безопасность) есть признаки глубокой проверки: воспроизведение бага до правки, сравнение с независимым эталоном, случайные/фаззинг-тесты.
• ☐ Если результат неверен из-за неправильного подхода, а не пропущенных случаев, уровень не повышают, а уточняют спецификацию или подход.
• ☐ Утверждения про Sonnet 5.5, Hermes, `claude -p` и контент-каналы помечены «не подтверждено», пока нет источника.

Задача: Снизить стоимость задачи на Opus 5.5: выбрать effort, модель, не ломать кэш

Правила

Что определяет цену задачи

• Задача — цикл ходов; каждый ход пересылает весь контекст. Меньше ходов — дешевле.
• Цены Opus 5.5 (API): $4/М вход, $20/М выход, $0.20/М чтение кэша. Выход дороже входа в 5 раз, мышление считается как выход.
• Пример: 40 ходов ≈ 2.8М входа ≈ $1.62 при 90% кэша; 25 ходов ≈ $1.02. Без кэша те же 2.8М стоят $11.20, при 96% кэша — ≈ $0.99.
• Против Opus 5: вход и выход дешевле на 20%, чтение кэша — на 60%. На планах Pro/Max/Team лимиты растут примерно на 25%.

Effort

• Уровни: low, medium, high, xhigh, плюс max на одну сессию. По умолчанию на Opus 5.5 — medium (у Opus 5 было high).
• low — механика (переименования, известный паттерн по файлам); medium — понятные ежедневные задачи; high — если medium буксует; xhigh — трудное, только если замерен выигрыш.
• Не переносить уровень, выбранный под Opus 5: на том же уровне Opus 5.5 думает больше, особенно на xhigh и max.
• Признак нехватки effort: правка остановилась на одном слое (поле переименовано в обработчике, клиент шлёт старое). Но сначала проверь, есть ли у модели способ проверить работу (тест, сборка, скрипт) — это один ход, а effort добавляет мышление на каждый.
• Расчёт: +20K токенов мышления на high ≈ $0.40 ≈ цена десяти ходов повторной попытки. High окупается, если спасает один ретрай.
• Смена effort на API-ключе и подписке кэш сохраняет; на Bedrock, Google Cloud и шлюзах — сбрасывает кэш.

Выбор модели

• Opus 5.5 — основная для работы под присмотром: фичи на несколько файлов, отладка, ревью.
• Fable 5.1 ($10/$50, чтение кэша $0.25) — для долгих прогонов без присмотра, задач без образца в коде, больших изменений с множеством субагентов. Если Opus 5.5 на xhigh дважды упёрся в одну проблему — переключиться, потом вернуться.
• Sonnet/Haiku — только для поиска, чтения логов и вывода тестов, вопросов «где определено»; не для написания кода. Механическую правку по многим файлам оставить на Opus 5.5 с low.
• Субагент без указанной модели наследует основную; `model:` в определении перекрывает CLAUDE_CODE_SUBAGENT_MODEL.
• Agent teams (экспериментально) ≈ 7× токенов обычной сессии в plan mode: команды маленькие, задачи самодостаточные, участников закрывать.
• opusplan (план на Opus, код на Sonnet) — сначала замерить на своих задачах.

Кэш

• Чтение кэша = 5% цены входа; запись = 1.25× (5 минут) или 2× (1 час). При 120K контекста: запись ≈ $0.60, чтение ≈ $0.02 (запись = 25 чтений).
• Время жизни: час на подписке; 5 минут на API-ключе и у облачных провайдеров (и на подписке при расходе кредитов). Каждое попадание продлевает.
• Кэш сбрасывается/пишется заново при: паузе дольше срока жизни; смене effort на Bedrock/Google/шлюзе; первом включении fast mode; подключении/отключении MCP-сервера; смене модели; компактации.
• Настройки задавать на старте сессии и не трогать по ходу.
• Fast mode: до 2.5× быстрее при двойной цене ($8/$40), на подписке идёт в кредиты; первый запрос платит вход целиком без кэша — включать в начале.

Контекст и компактация

• Каждый ход пересылает весь контекст: чтение при 20K ≈ $0.004, при 150K ≈ $0.03 (30 ходов — $0.90 против $0.12).
• /clear бесплатен — между несвязанными задачами. /compact стоит один запрос (≈ $0.25 на 150K), окупается примерно за 10 ходов; в конце работы невыгоден.
• Компактить до перерыва, не после: после остывания кэша на 5-минутном сроке ≈ $0.75 только за вход. Указывать, что сохранить. Ненужную ветку лучше откатить через /rewind.
• CLAUDE.md грузится в каждую сессию — держать до 200 строк. Неиспользуемые MCP-серверы отключать (/mcp).
• При миграции: `/claude-api prompt-audit` ищет ритуальные инструкции, из-за которых модель пишет больше и повторяет вызовы. На внутреннем бенчмарке (44 тикета) — ещё −9% к −18% от перехода; это один пример, не ожидаемое число.

Замер

• `/usage` (или `/cost`) в конце задачи: ввод, вывод, доля кэша; доллары — по прайсу, на подписке это ориентир, не счёт.
• Прогнать одну задачу на Opus 5 и Opus 5.5, сравнить ходы, выходные токены, стоимость; 3–4 задачи до выводов. Нужен Claude Code v2.1.280+.
• Читать: доля кэша (низкая — ищи паузу, смену модели, MCP), много выхода на малой правке (effort высок или ретраи), входа во много раз больше размера диалога (много ходов).
• Ориентир: ≈ $13 на разработчика в активный день, у 90% — ниже $30.

Куда применить у нас

• Агентная разработка (Claude Code, Hermes): стартовать на medium, high — при застревании; поиск и чтение логов — субагентам на Sonnet/Haiku, правки кода оставить на основной модели; проверить свой CLAUDE.md и скиллы через `/claude-api prompt-audit` и держать CLAUDE.md в пределах 200 строк.
• GameHub (NestJS + Postgres, античит-формула начислений): изменения, затрагивающие несколько слоёв (контракт API, клиент Phaser, формула), вести с тестом, проходящим через клиент: статья показывает, что правка «на один слой» ловится проверкой. Выбор effort под начисления токенов — из этого правила; конкретных рекомендаций по античиту в статье нет (не подтверждено).
• v3ko.ru (статика, тёмная тема): переименования и правки по шаблону по многим страницам — Opus 5.5 на low; /clear между несвязанными правками. Больше в статье для статики ничего нет (не подтверждено).
• Контент-каналы: применимо только общее правило: /clear между несвязанными задачами (пост, дневник, ролик) и не менять модель/MCP посреди сессии, чтобы не ломать кэш. Специфики по контенту в статье нет (не подтверждено).
• Остров claude.dev (Claude CLI, `claude -p`): на подписке кэш живёт час — серию разборов гнать одной сессией без пауз; замер делать через /usage на 3–4 реальных задачах, а не по цифрам статьи.

Проверки

• ☐ Для типовой задачи сняты /usage: доля кэша, выход против входа, число ходов — есть свои цифры, а не цифры статьи
• ☐ Модель, effort и набор MCP-серверов заданы на старте сессии; по ходу работы доля кэша не проваливается
• ☐ Субагенты поиска и логов явно назначены на Sonnet/Haiku, код пишет основная модель
• ☐ У задач на несколько слоёв есть проверка (тест/сборка), а effort поднимается только после того, как проверка не помогла
• ☐ CLAUDE.md и скиллы прогнаны через prompt-audit; CLAUDE.md не длиннее 200 строк

Задача: Ускорение интерфейса через измеримые бенчмарки, hill climbing с Claude и защитные ограждения

Правила

Главный принцип

• Измерение — шаг первый, а не нулевой: как только у Claude есть число, которое нужно побить, он начинает оптимизировать.
• Самое ценное действие — находить новые вещи для измерения.
• Результат спринта: за 2 недели ускорение примерно в 3 раза, более 3000 изменений без инцидентов у клиентов и без откатов.

Постановка задачи

• Единый канал с постоянной инструкцией для Claude: мониторить деплои, проверять телеметрию, вести дашборды, предлагать проекты, общаться с командой.
• Через данные использования выбраны 4 ключевых сценария (95% активности), из них собрано 13 измерений.
• Каждое измерение: начинается с действия пользователя, заканчивается отрисованным результатом, раздельно считает клиентскую и серверную работу.
• Старт: около 20 проектов с оценкой эффекта в миллисекундах; из них сложены цели. 12 из 13 целей достигнуты к 3-му дню.
• После достижения целей ставить новые: «цели — не остановка».

Бенчмарки в лаборатории

• У каждого бенчмарка две роли: метрика, которую Claude может двигать, и защита в CI с числом, которое может только снижаться (храповик).
• Время по часам шумное, для CI-порога не годится. Детерминированные счётчики: инструкции процессора (Valgrind, node --predictable), вызовы функций V8, коммиты React, пересчёты стилей, мутации DOM.
• Нестабильные бенчмарки и те, что не коррелируют с задержкой для пользователя, выбрасывать.
• Корреляцию надо доказывать: попросить Claude снизить счётчик и проверить, что время по часам тоже падает. Пример: инструкции -48% и -31%, время -78% и -44%.
• Ежедневная задача снижает потолок, если счётчик упал; PR, повышающий счётчик, не проходит CI.
• Если стандартной метрики нет, взять исходный API напрямую (пример: Layout Instability API вместо CLS: каждый сдвиг ~0.008 при пороге 0.1). Тест красный 20 из 20 запусков на main и зелёный 20 из 20 на PR.

Цикл по тредам

• Человек открывает тред про медленный участок (часто со скриншотом или записью).
• Claude трассирует поток и находит или строит бенчмарк, показывающий проблему.
• Лабораторный результат — PR (часто несколько, по размеру риска), всё видимое пользователю за флагом.
• После выкатки Claude смотрит деплой и полевые данные.
• Улучшилось — храповик затягивается; нет — флаг выключается, итерация.
• Затем поиск следующего узкого места в том же сценарии.
• Масштаб: одновременно более 150 тредов, до 50–100 PR в одном треде, в пик более 200 изменений в день.

Ограждения

• Каждый PR: автоматическое ревью и минимум одно одобрение человека; юнит-тесты раньше оптимизаций; всё пользовательски заметное за недолговечным флагом.
• Около 200 флагов за 2 недели, более половины уже убраны. Каждый флаг классифицирован как аварийный выключатель или ступенчатая выкатка, и убирается, как только безопасно.
• Хрупкие оптимизации защищаются многослойно (статичный композер: тест на совпадение с React-версией, интеграционные тесты на 14 размерах окна с допуском 1 px, тест набора, что не теряет и не переставляет клавиши, полевая телеметрия сдвигов с точностью 0,1 px).
• Поэтапная выкатка: сотрудники, затем 1% пользователей, затем все.
• Лаборатория не видит всего: пример со сдвигом из-за браузера Chrome (предрендер и нижняя панель 56 px) нашёлся только по записи экрана сотрудника.

Управление (человек)

• Амбиция: по умолчанию Claude осторожен в объёме, оценках и тикетах; его нужно подталкивать быть смелее, когда ограждения готовы.
• Вкус: у каждого треда назван человек-владелец; изменения, заметные пользователю, показываются в «до/после» (скриншот или запись), решение за человеком.
• Направление: треды узкие, один бенчмарк или один сценарий; человек решает приоритеты, объединяет конфликтующие треды и закрывает те, где отдача падает (пример: 900 строк ради 2 мс на отправку — отклонено).
• Бюджет кадра: для 120 Гц — 8,33 мс на кадр; стенд с детерминированным шагом кадров стал ночной задачей.

Не подтверждено

• Конкретные внутренние инструменты (Claude Tag, внутренняя модель) в статье описаны только как использованные; детали настройки не приведены.

Куда применить у нас

Куда применить

• v3ko.ru (статика, тёмная тема): выбрать 2–3 ключевых сценария (первая загрузка, переход между страницами), завести для них измеримые показатели и поставить в CI порог, который может только снижаться. Конкретные числа в статье даны для claude.ai, для v3ko.ru они не подтверждены, нужен свой замер.
• GameHub (Telegram Mini App, Phaser, NestJS): по аналогии с бюджетом кадра в статье задать бюджет кадра для игр и считать детерминированные метрики (число перерисовок, вызовов функций) вместо времени по часам. Для начисления токенов с античитом правило из статьи: пользовательски заметные и рискованные изменения за флагом, выкатка по ступеням (сотрудники, 1%, все). Это вывод из правил, прямо в статье про деньги и античит ничего нет.
• Контент-каналы: прямых фактов в статье нет, не подтверждено. Единственная перекладка по смыслу: у каждой задачи один владелец, изменения показываются «до/после» для решения человека.
• Агентная разработка (Claude Code, Hermes, скилл-пак): по схеме канала дать агенту постоянную инструкцию с обязанностями, узкие треды (один бенчмарк = один тред), владелец у каждого треда, ограждения (авторевью, юнит-тесты раньше оптимизаций, флаги), чистка флагов отдельным заданием, ночные задачи на регрессии.

Проверки

• ☐ Для каждого сценария есть измерение, которое начинается с действия пользователя и заканчивается отрисованным результатом, и есть базовое значение до изменений.
• ☐ Каждый новый бенчмарк доказал корреляцию со временем по часам (счётчик упал — время упало), иначе он выброшен.
• ☐ В CI стоит порог-храповик: PR, повышающий счётчик, падает, а потолок снижается автоматически, когда счётчик уменьшился.
• ☐ Пользовательски заметные изменения идут за флагом с поэтапной выкаткой, а у каждого флага есть классификация (аварийный выключатель или ступенчатая выкатка) и срок удаления.
• ☐ У каждого треда есть названный человек-владелец, а заметные изменения показаны в «до/после» для его решения.

Задача: Как ставить задачи Opus 5.5 в Claude и Claude Code: длинные прогоны, проверка результата, реакция на флаги

Правила

Постановка задачи

• Отдавай задачу целиком одним сообщением; назови финишную черту («тесты проходят», «все эндпоинты мигрированы») и когда останавливаться и спрашивать.
• Удали из промптов и сохранённых инструкций «think carefully», «think step by step»: Opus 5.5 думает перед каждым ответом сам. В тесте в чат-продукте без такой строки ответы начинались быстрее, качество явно не падало.
• Нужен быстрый ответ — «Answer directly». Глубину размышления в Claude Code меняет effort.
• Вспомнил деталь посреди прогона — напечатай её и нажми Enter, пока Claude работает (рестарт дорог).
• Для дизайна перечисляй конкретные нежелательные паттерны. Общее «избегай шаблонного вида» лишь меняет один дефолт на другой. Не понравился результат — допиши в список и повтори.

Длинный прогон в Claude Code

• В CLAUDE.md пропиши правило: если шаг не требует тебя — продолжай; статус пиши в одном сообщении со следующим действием; останавливайся, только если без тебя нельзя продолжить, или перед разрушительным (удаление данных, force-push, правка вне репозитория). Причина: модель иногда останавливается с отчётом, предложением продолжить или списком неблокирующих вариантов.
• Если прогон встал на «Want me to continue?» — ответь «continue».
• Разрешения на разрушительные команды оставь включёнными: правило «продолжай» уменьшает число остановок.
• Для парной работы можно наоборот: однострочный план в начале и краткий итог в конце — тоже через CLAUDE.md.
• Большие аудиты, миграции и ревью — проси раздать подагентам по одному на единицу работы; результат каждого проверять по его доказательствам; в конце — одна таблица.
• Список задач держи в файле (например, TASKS.md): отмечай сделанное, дописывай найденное. Файл переживает сжатие контекста; смотри файл, а не прокрутку.

Проверка результата

• По окончании прогона сначала читай, чего Claude ждёт от тебя (открытое решение, изменение на утверждение), потом остальное. Формат итога задаётся в CLAUDE.md, например три заголовка: Blocked on me, Changed, Found.
• Ревью диффа или PR перед человеком: только проблемы, блокирующие мерж; для каждой — файл и строка, почему неверно, как показать падение. Один тестер: Opus 5.5 на самом низком effort нашёл больше багов, чем Opus 5 на high, с меньшим числом ложных тревог.
• Для исследований добавляй: «Mark anything you couldn't confirm, and say where you looked».

В приложениях Claude

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

Флаги безопасности

• Opus 5.5 — первый Opus с защитой уровня Fable по био и кибер. Большинство помеченных сообщений переводятся на старую модель, работа продолжается там. Поиск уязвимостей в исходниках разрешён. Ложные срабатывания возможны, их донастраивают.
• Проверка охватывает весь разговор, включая файлы и результаты поиска: флаг может прийти из ранней части.
• Вернуться: в приложении — выбор модели (новый чат избегает повторного флага); в Claude Code — `/model`, двойной Esc для правки сообщения, `/config` для режима «спросить сначала», `/feedback` при ошибочном флаге.
• Не проси воспроизводить внутренние рассуждения в ответе: такой запрос может быть отклонён (категория флагов). Вместо этого: «Explain why you chose this approach in three sentences».

Скорость

• `/fast` в Claude Code — для диалога, где читаешь каждый ответ перед следующим. Та же модель, текст приходит быстрее; нужен включённый extra usage, дороже за токен, статус — research preview.

Куда применить у нас

• Агентная разработка (Claude Code, Hermes): вставить в CLAUDE.md правило «продолжай / стоп перед разрушительным» (из статьи, с поправкой под проект) и формат итога из трёх заголовков; список задач вести в TASKS.md; аудиты и миграции раздавать подагентам с проверкой доказательств; удалить «think carefully» из скилл-пака и инструкций Hermes. Для собственных агентов Hermes перенос на их рантайм не подтверждён: в статье речь только о Claude и Claude Code.
• GameHub (NestJS + Postgres, начисления токенов): миграции и правки античит-формулы ставить с явной финишной чертой («все вызовы переведены, старый код удалён, тесты проходят»); перед ревью человеком гонять ревью диффа с форматом «только блокирующие проблемы: файл и строка, почему неверно, как показать падение». Что именно считается рискованным для денег и токенов, в статье не сказано, не подтверждено; разрешения на разрушительные команды держать включёнными.
• v3ko.ru (статические тёмные страницы): в запросах на страницы перечислять конкретные запрещённые дизайн-паттерны и дополнять список после каждого просмотра; скриншоты макета прикладывать, а не описывать словами.
• Контент-каналы: длинные планы, посты и дневники проверять запросом «найди внутренние противоречия: числа, даты, имена, цитируй проблему и место»; под каждую соцсеть просить готовый файл, а не набросок. Применимость к постам и роликам выведена из правил про документы и колоды; прямо в статье о соцсетях ничего нет.
• Исследования и разборы везде: добавлять в запрос «Mark anything you couldn't confirm, and say where you looked».

Проверки

• ☐ В задаче названа финишная черта и условие остановки, а в промптах и инструкциях нет строк «think carefully» / «think step by step»
• ☐ В CLAUDE.md есть правило «продолжай / стоп перед разрушительным», а запросы разрешений на разрушительные команды всё ещё включены
• ☐ Для длинного прогона есть файл списка задач (TASKS.md) с отмеченными пунктами, а итог начинается с раздела «что нужно от меня»
• ☐ Ревью диффа выдаёт только блокирующие проблемы с файлом, строкой и способом показать падение
• ☐ В исследовательском ответе есть пометки «не подтверждено» с указанием, где искали

Задача: Переписать контекст (CLAUDE.md, скиллы, системный промпт) под модели Claude 5: меньше правил, больше суждения и раскрытия по требованию

Правила

Что изменилось

• Из системного промпта Claude Code убрано более 80% для Claude Opus 5 и Claude Fable 5 — без измеримой потери на coding-оценках.
• Причина: избыточные ограничения. В одном запросе сталкиваются правила системного промпта, скиллов и просьба пользователя («leave documentation as appropriate» против «DO NOT add comments») — модели приходится тратить мысль на разбор конфликтов.
• Ограничения были нужны, чтобы избежать худших сценариев (например, удаления файлов); теперь многие можно удалить и положиться на контекст и суждение модели.

Было → стало

• Правила → суждение. Вместо жёсткого «не пиши комментарии, докстринги — одна строка» — «пиши код, который читается как окружающий: повторяй плотность комментариев, именование, идиому».
• Примеры → дизайн интерфейсов. Примеры сужают пространство, которое модель исследует. Вместо них продумывать параметры инструментов, скриптов, файлов и их выразительность (пример из статьи: enum статуса pending / in_progress / completed уже подсказывает использование).
• Всё сразу → прогрессивное раскрытие. Проверку и код-ревью вынесли из системного промпта в отдельные скиллы; часть инструментов грузится отложенно (сначала поиск через ToolSearch). CLAUDE.md и Skill.md — не склад всех практик, а дерево файлов, грузимых вовремя.
• Повторы → простые описания инструментов. Дубли упоминаний инструментов в системном промпте удалены; инструкции живут в описании инструмента.
• Память в CLAUDE.md → авто-память. Хоткей `#` для записи в CLAUDE.md больше не рекомендуется: Claude сам сохраняет релевантное.
• Простые спеки → богатые референсы. HTML-артефакты, набор тестов как спецификация, функция из другой кодовой базы для портирования, рубрики (проверка вкуса через верификатор-агентов).

Как собирать контекст

• Системный промпт: привязан к продукту; для Claude Code не меняется, для своего агентного харнесса — тут тратить основное время.
• CLAUDE.md: лёгкий; кратко — для чего репозиторий, основные токены — на неочевидные «грабли» (пример: все типы в одном монолитном файле). Не писать то, что видно из файловой системы. Несколько уникальных инструкций по проверке — вынести в скилл и сослаться из CLAUDE.md.
• Скиллы: лёгкие путеводители; жёсткие ограничения только в действительно важных областях; длинные — делить на файлы; ценнее всего то, что отражает ваши мнения, знания и практики.
• Референсы: `@`-упоминание файлов; предпочитать файлы в коде — HTML-макет обычно даёт результат лучше, чем описание или скриншот.

Инструмент

• `claude doctor` / команда `/doctor` в Claude Code — подгоняет размер скиллов и CLAUDE.md под эти правила.
• Количественные критерии (сколько строк оставлять в CLAUDE.md): не подтверждено, в статье цифр нет.

Куда применить у нас

• Агентная разработка (Claude Code, Hermes, скилл-пак): прогнать `/doctor`; убрать из CLAUDE.md и скиллов жёсткие «никогда/всегда» там, где вред не катастрофичен; оставить жёсткие правила только в критичных зонах. Длинные скиллы разбить на дерево файлов; проверку вынести в отдельный скилл со ссылкой из CLAUDE.md. Для Hermes — вынести инструкции по инструментам в их описания, убрать дубли из системного промпта (применимость выведена из правил статьи; про Hermes в статье ничего нет — не подтверждено).
• GameHub: в CLAUDE.md держать только «грабли» (например, где живёт античит-формула и что её нельзя менять без причины); проверку начислений оформить как отдельный скилл или набор тестов — статья прямо называет детальный тестовый набор формой спецификации.
• v3ko.ru: дизайн задавать HTML-макетом как референсом, а не описанием или скриншотом; тёмную тему фиксировать в самом макете.
• Контент-каналы: вместо правил «пиши так-то» дать референсы стиля под каждую соцсеть (удачные посты) и/или рубрику для проверки вкуса; по статье рубрики используются для верификатор-агентов. Прямого примера про контент в статье нет — вывод по аналогии, не подтверждено.

Проверки

• ☐ В CLAUDE.md нет очевидного, видного из структуры репозитория; основной объём — неочевидные «грабли».
• ☐ Нет пар правил, которые противоречат друг другу (системный промпт ↔ скилл ↔ CLAUDE.md); остались жёсткие ограничения только в действительно важных областях.
• ☐ Длинные скиллы и инструкции разбиты на файлы и подгружаются по необходимости; проверка/ревью вынесены в отдельные скиллы со ссылкой из CLAUDE.md.
• ☐ Описания инструментов самодостаточны: инструкции в них, без дублей в системном промпте и без лишних примеров; параметры (например, enum) выразительны.
• ☐ Запущен `/doctor`, и результат сверен с оценками/задачами: качество не просело после сокращения.

Задача: Построить и поддерживать библиотеку скиллов для Claude Code: что делать, как писать, как распространять и мерить

Правила

Что такое скилл

• Скилл — папка, а не просто markdown-файл: инструкции, скрипты, ассеты, данные, которые агент находит и использует сам.
• В Claude Code у скиллов есть настройки, включая динамические хуки.
• В Anthropic в работе сотни скиллов; лучшие начинались с нескольких строк и одной «ловушки» (gotcha), потом росли по мере новых краевых случаев.

9 типов скиллов

• Библиотеки и API (справочник, сниппеты, gotchas).
• Проверка продукта (playwright, tmux; программные проверки состояния на каждом шаге, запись видео).
• Данные и аналитика (доступы, id дашбордов, типовые запросы).
• Бизнес-процессы и автоматизация команды (лог прошлых запусков помогает держать согласованность).
• Шаблоны и scaffolding кода.
• Качество кода и ревью (можно запускать из хуков или GitHub Action).
• CI/CD и деплой.
• Runbooks: симптом → расследование → структурированный отчёт.
• Операции с инфраструктурой (деструктивные действия — с защитными барьерами).
• Лучший скилл ложится ровно в один тип; скилл, который пытается всё сразу, путает агента.
• Скиллы проверки продукта дали самый заметный измеримый эффект на качество; в статье допускается неделя инженера на их доведение.

Как писать

• Не повторять очевидное: только то, что выводит Claude из привычного хода мысли.
• Раздел Gotchas — самый ценный; пополнять из реальных сбоев Claude.
• Файловая система = прогрессивное раскрытие: SKILL.md ссылается на references/, assets/, scripts/; сказать Claude, какие файлы есть.
• Не «зажимать в рельсы»: задавать цель и ограничения, не каждый шаг.
• Настройка: хранить в config.json в папке скилла; если пусто — агент спрашивает пользователя (для вариантов — AskUserQuestion).
• Description — не краткое содержание, а условие срабатывания: Claude сканирует список описаний при старте сессии; включать слова-триггеры.
• Память: append-only лог, JSON или SQLite внутри скилла; стабильный каталог — ${CLAUDE_PLUGIN_DATA}.
• Класть скрипты и маленькие библиотеки хелперов (gotchas — в docstring), чтобы Claude тратил ходы на композицию, а не на шаблонный код.
• On-demand хуки живут только в сессии вызова скилла: /careful (блок rm -rf, DROP TABLE, force-push, kubectl delete через PreToolUse на Bash), /freeze (блок Edit/Write вне заданной папки).

Распространение

• Малая команда, мало репозиториев: скиллы в `./.claude/skills`.
• Каждый скилл в репозитории добавляет контекст модели; при росте — плагин и внутренний маркетплейс с выбором установки и процессом настройки.
• Маркетплейс в Anthropic — органический: скилл сначала в sandbox-папке GitHub, анонс в Slack; при traction владелец делает PR в маркетплейс. Центральной команды-отборщика нет.

Композиция и измерение

• Зависимости между скиллами нативно не поддерживаются: ссылаться по имени, модель вызовет, если установлен.
• Использование логируется через PreToolUse-хук; так видно популярные и недосрабатывающие скиллы.

Куда применить у нас

• Агентная разработка (Claude Code + Hermes): собрать свой скилл-пак по 9 типам и найти пробелы; начать с одного скилла проверки (запуск → проверка результата) и одним gotcha, пополнять по сбоям. Описания писать как триггеры. Завести on-demand хук в духе /careful для работы на проде (блок force-push, rm -rf, DROP TABLE). Логировать вызовы скиллов PreToolUse-хуком, чтобы видеть недосрабатывающие.
• GameHub: скилл «проверка продукта» для Telegram Mini App/NestJS: программные проверки состояния на каждом шаге, включая начисление токенов; отдельно gotchas по Postgres и античит-формуле (по аналогии с примером «staging отвечает 200, хотя вебхук не обработан»). Для миграций — скилл-шаблон с типовыми ловушками. Деструктивные операции — под защитным хуком.
• v3ko.ru (самохостинг): скилл деплоя/инфраструктуры со смоук-проверкой после выкладки и барьерами на деструктивные действия; runbook «симптом → проверка → отчёт» для сервера. Применимость выводится из типов «CI/CD», «Runbooks», «Infrastructure operations»; конкретных примеров про статику в статье нет — не подтверждено.
• Контент-каналы: скилл автоматизации процесса по типу standup-post: лог прошлых публикаций (append-only), чтобы агент видел, что уже вышло, и давал только новое; config.json для канала/площадки; шаблон формата в assets/ под каждую соцсеть. Про контент в статье напрямую ничего нет — применимость выведена из типа «бизнес-процессы».

Проверки

• ☐ Каждый скилл укладывается ровно в один из 9 типов, а не размазан по нескольким
• ☐ В SKILL.md есть раздел Gotchas, и он пополнялся по реальным сбоям; очевидные инструкции убраны
• ☐ Description описывает условие срабатывания со словами-триггерами, а не пересказ содержания
• ☐ Скилл — папка со ссылками на references/scripts/assets, а настройка лежит в config.json и при пустоте запрашивается у пользователя
• ☐ Использование скиллов логируется PreToolUse-хуком, и видно, какие недосрабатывают

Задача: Выбор и сборка динамических workflow в Claude Code под сложные, многошаговые задачи

Правила

Когда нужен workflow

• Дефолтный харнес планирует и исполняет в одном контексте; на долгих, массово-параллельных, структурных и состязательных задачах он ломается.
• Три сбоя одного контекста: агентная лень (останавливается, например, на 35 из 50 пунктов), самопредпочтение (завышает свои результаты при проверке по рубрике), дрейф цели (после компакции теряются ограничения вроде «не делай X»).
• Лечение: отдельные субагенты со своим контекстом и узкой целью.
• Не нужен для обычного кодинга: панель из 5 ревьюеров там не требуется. Вопрос себе: «нужно ли здесь больше вычислений?». Токенов workflow часто тратит заметно больше.

Как устроен

• Workflow — JavaScript-файл со спецдействиями: `agent()` порождает одного субагента, `parallel()` и `pipeline()` собирают многих. Доступны JSON, Math, Array.
• Workflow сам выбирает модель для агента и запуск в отдельном worktree.
• После прерывания возобновление сессии продолжает workflow с места остановки.
• Запуск: попросить Claude создать workflow или использовать слово-триггер «ultracode».
• Статические харнесы (Agent SDK, `claude -p`) обязаны покрывать все случаи и потому общие; динамический пишется под конкретную задачу (в статье — с Claude Opus 4.8).

Шесть паттернов (комбинируются)

• Classify-and-act — классификатор определяет тип задачи и маршрутизирует; либо классифицирует итог в конце.
• Fan-out-and-synthesize — дробить на шаги, агент на каждый, затем синтез. Синтез — барьер: ждёт всех и сливает структурированные выводы.
• Adversarial verification — на каждого агента отдельный агент, проверяющий результат по рубрике.
• Generate-and-filter — нагенерировать идей, отфильтровать по рубрике или проверке, убрать дубли.
• Tournament — N агентов решают одну задачу разными подходами, судья сравнивает попарно до победителя.
• Loop until done — цикл до условия остановки (нет новых находок, нет ошибок в логах), а не фиксированное число проходов.

Сценарии из статьи

• Миграции и рефактор: разбить на единицы (места вызова, падающие тесты, модули); на каждую — субагент в worktree, затем состязательное ревью и слияние; запретить ресурсоёмкие команды, чтобы максимально распараллелить.
• Глубокая проверка фактов: один агент выделяет все утверждения, по субагенту на проверку каждого; опционально аудитор качества источника.
• Сортировка 1000+ строк: в один промпт не влезает и качество падает; турнир попарных сравнений (сравнение надёжнее абсолютной оценки) или параллельное ранжирование по корзинам со слиянием.
• Соблюдение правил: один верификатор на правило в чистом контексте, затем скептик отсеивает ложные срабатывания. Обратно: собрать из сессий и ревью повторяющиеся поправки, кластеризовать, проверить («предотвратило бы правило реальную ошибку?»), выжившие — в CLAUDE.md.
• Поиск причин: гипотезы из непересекающихся данных (логи, файлы, данные), каждую проверяет панель верификаторов и опровергателей — против самопредпочтения.
• Триаж: классификация, дедупликация, действие. Карантин: агенты, читающие недоверенный контент, без привилегий; действует отдельный агент, видящий только их сводки. Для постоянной работы — в паре с `/loop`.
• Вкус (дизайн, нейминг): варианты + рубрика + агент-ревьюер; готово, когда критерии выполнены; отбор турниром.
• Evals: агенты в worktree, затем агенты-сравнения оценивают по рубрике.
• Маршрутизация моделей: классификатор-разведчик выбирает Sonnet или Opus по ожидаемой сложности.

Управление

• Детальный промпт с названием приёмов даёт лучший результат; бывает и «быстрый workflow» (например, состязательная проверка одного допущения).
• `/loop` — запуск повторяемых workflow с интервалом; `/goal` — жёсткое условие завершения.
• Бюджет токенов задаётся в промпте, например «use 10k tokens» — это ставит лимит.
• Сохранение: клавиша `s` в меню workflow; хранить в `~/.claude/workflows` или раздавать через скилл (JS-файлы в папке скилла, ссылка в `SKILL.md`; просить трактовать их как шаблон, а не дословный сценарий).
• Лучшие практики ещё формируются — это заявлено в статье.

Куда применить у нас

• Агентная разработка (Claude Code, Hermes, скилл-пак): правила, которые модель пропускает даже в CLAUDE.md, — workflow «один верификатор на правило + скептик». И обратный ход: вытащить повторяющиеся поправки из последних сессий в CLAUDE.md. Готовый workflow можно положить в скилл-пак как шаблон (JS в папке скилла, ссылка в `SKILL.md`). Применимость к Hermes — не подтверждено: в статье речь только о Claude Code.
• GameHub (античит-формула, NestJS): это вывод из правил «adversarial verification» и «root-cause investigation», в статье GameHub и античит не упоминаются. Для разбора спорных начислений — гипотезы из непересекающихся данных (логи, данные, код) с верификаторами и опровергателями; для массового рефактора модулей — субагент на модуль в worktree + состязательное ревью. Любые изменения начислений и авторизации — тем более проверка отдельным агентом.
• Контент-каналы: нейминг и варианты постов — «generate-and-filter» или турнир по рубрике под стиль каждой соцсети; проверка технических утверждений в черновике через «deep verification» (один агент на утверждение). Рубрику под соцсети нужно задать самому — в статье её нет.
• v3ko.ru: проверка фактов в текстах лаборатории по «deep verification» и сортировка/ранжирование больших списков (материалов, заметок) турниром. Дизайн-вариантов касается только паттерн «вкус + рубрика»; про статические страницы и тёмную тему в статье ничего нет.
• Остров claude.dev (текущий репозиторий): монитор RSS — кандидат на «триаж» с карантином (читающий агент без привилегий, действующий видит только сводку) и `/loop`; это вывод из правил, не утверждение статьи.

Проверки

• ☐ Задача действительно сложная, массовая или состязательная, а не обычный кодинг; решение «нужен workflow» обосновано, и задан лимит токенов в промпте.
• ☐ Выбраны конкретные паттерны из шести, и у каждого есть критерий: рубрика, условие остановки или список правил.
• ☐ Каждый результат проверяет отдельный агент в чистом контексте, а не тот, что его породил; для правил есть скептик против ложных срабатываний.
• ☐ Агенты, читающие недоверенный контент, не имеют привилегий; действует отдельный агент, получающий только сводки.
• ☐ Повторяемый workflow сохранён (`s`, `~/.claude/workflows` или скилл) и при необходимости привязан к `/loop` и `/goal`; в скилле он описан как шаблон.

Задача: Выбрать HTML вместо Markdown для спеков, планов, ревью и отчётов Claude Code, чтобы их реально читали и можно было шарить

Правила

Когда Markdown не хватает

• Файл длиннее ~100 строк автор перестаёт читать, а коллеги тем более.
• Нужны таблицы, цвет, диаграммы, интерактив — в Markdown модель уходит в ASCII-диаграммы и «цвета» юникод-символами.
• Файл правит не человек, а Claude по промпту: главное преимущество Markdown (лёгкая ручная правка) пропадает.

Что даёт HTML

• Плотность: таблицы, CSS для дизайн-данных, SVG для иллюстраций и воркфлоу, script-теги для кода, JS+CSS для интерактива, canvas и абсолютные позиции для пространственных данных, img.
• Читаемость: вкладки, иллюстрации, ссылки; адаптивность под мобильный экран.
• Шаринг: загрузил файл — отправил ссылку; браузеры Markdown нативно не рендерят, его приходится слать вложением.
• Двусторонность: слайдеры, ручки, кнопка «скопировать как промпт» для возврата правок в Claude Code.
• Контекст: Claude Code читает файловую систему, MCP (Slack, Linear), браузер (Claude in Chrome) и git-историю — отчёт собирается из них.

Как начать

• Достаточно промпта «make an HTML file» или «make an HTML artifact».
• Заранее знать, что артефакт должен делать и как им пользоваться.
• Скилл под повторяющиеся паттерны — потом, после ручных проб.

Сценарии (из статьи)

• Спеки и планирование: сеть HTML-файлов вместо одного плана — варианты (например, 6 разных подходов в одной сетке с подписью компромисса), макеты, затем план реализации. Для реализации — новая сессия с передачей всех файлов; верификатору — те же файлы.
• Ревью кода: отрендеренный diff с аннотациями на полях и цветом по severity; для создания PR, ревью PR, разбора темы.
• Дизайн и прототипы: HTML как эскиз, затем перенос в React/Swift и т.д.; слайдеры и ручки для анимаций, кнопка копирования параметров.
• Отчёты и ресёрч: длинный документ, интерактивный объяснитель или слайды; диаграммы в SVG; статусы, инцидент-репорты.
• Одноразовые редакторы: один HTML под конкретные данные (тикеты по колонкам Now/Next/Later/Cut, конфиг флагов, тюнинг промпта). Правило: всегда заканчивать экспортом — «copy as JSON» / «copy as prompt» / «copy diff».

Цена и оговорки

• Markdown дешевле по токенам, но при контексте 1 млн (Opus 4.7) разница незаметна; выигрыш — в том, что HTML читают.
• Автор — «максималист HTML» и почти не использует Markdown; это его личное мнение, не норма команды.
• Вместо одного плана — несколько HTML-файлов по стадиям; хранить как референс и для верификации.
• Главная причина по автору: HTML держит человека «в контуре» — читаешь выбор Claude, а не передаёшь вслепую.

Куда применить у нас

• Агентная разработка (Claude Code, Hermes): планы и спеки длиннее ~100 строк делать HTML-файлами по стадиям (варианты → макеты → план); в новую сессию реализации и верификатору передавать весь набор. Для ревью PR — HTML с diff и severity-аннотациями. Это согласуется и с правилом проекта «спецификации длиннее 200 строк — HTML».
• GameHub: план изменений по начислению токенов и античит-формуле оформлять HTML-объяснителем (диаграмма потока, ключевые фрагменты, раздел «gotchas»), а параметры формулы крутить в одноразовом редакторе с кнопкой «copy as JSON/prompt». Вывод из правил статьи; саму формулу статья не касается — не подтверждено.
• v3ko.ru: статья прямо не про сайты, но подход «эскиз в HTML, затем перенос» и «несколько вариантов в одной сетке» применим к макетам тёмной темы; слайдеры для подбора значений (цвета, отступы) с экспортом параметров. Применимость — вывод, не утверждение статьи.
• Контент-каналы: одноразовый редактор для разбора постов/роликов (approve/reject, теги, экспорт) и HTML-отчёты по результатам. Про соцсети статья ничего не говорит — не подтверждено; это перенос правила «куратор данных с экспортом».

Проверки

• ☐ Документ открывается в браузере по ссылке, без вложений и конвертации
• ☐ Вместо ASCII-диаграмм и текстовых «цветов» — SVG, таблицы или CSS
• ☐ У интерактивного артефакта есть экспорт (copy as JSON / prompt / diff), и вставленный результат Claude Code принимает без доработок
• ☐ План разбит на несколько HTML-файлов по стадиям, и сессия реализации и верификатор получают их все
• ☐ Артефакт реально прочитан человеком и коллегами, а не только сгенерирован — это и есть критерий из статьи

Задача: Построить агентную систему так, чтобы кэш промпта работал: раскладка промпта, обновления, смена модели, набор инструментов, компактация

Правила

Основа

• Кэш работает по совпадению префикса: кэшируется всё от начала запроса до каждой точки `cache_control`.
• Любое изменение внутри префикса сбрасывает кэш всего, что идёт после него.
• Порядок: статика вперёд, динамика в конец.

Раскладка промпта (порядок в Claude Code)

• Статичный системный промпт и инструменты: кэш общий для всех.
• CLAUDE.md: кэш в пределах проекта.
• Контекст сессии: кэш в пределах сессии.
• Сообщения диалога.
• Как ломали раскладку сами авторы: подробная метка времени в статичном системном промпте, недетерминированный порядок описаний инструментов, правка параметров инструментов (например, списка агентов, которых может вызывать Agent).

Обновления — через сообщения

• Устарели данные (время, файл изменён пользователем)? Системный промпт не правь, это промах кэша.
• В Claude Code обновление приходит тегом `<system-reminder>` в следующем сообщении пользователя или в результате инструмента.
• Так же поступай со сменой режима и даты.

Модели и инструменты

• Кэш привязан к модели. Пример из статьи: на 100k токенов диалога с Opus дешевле ответить Opus, чем переключаться на Haiku, потому что для Haiku кэш строится заново.
• Нужна другая модель? Запускай субагента. Opus готовит «передаточное» сообщение для другой модели. Так работают Explore-агенты на Haiku.
• Набор инструментов в середине сессии не добавляй и не убирай: инструменты входят в кэшируемый префикс.
• Состояния моделируй самими инструментами. Plan Mode: все инструменты всегда в запросе, `EnterPlanMode` и `ExitPlanMode` сами являются инструментами, режим объясняется системным сообщением.
• Много MCP-инструментов? Не удаляй их, а отправляй лёгкие заглушки (только имя, `defer_loading: true`). Полная схема подгружается, когда модель выбрала инструмент через tool search. Заглушки всегда в одном порядке.

Компактация без потери кэша

• Отдельный вызов «суммаризуй» с другим системным промптом и без инструментов расходится с родительским запросом с первого токена. Весь диалог тарифицируется по полной цене без кэша, и чем длиннее диалог, тем дороже.
• Решение, cache-safe fork: тот же системный промпт, пользовательский и системный контекст и определения инструментов, что у родителя. Сообщения родителя идут первыми, промпт компактации добавляется новым сообщением пользователя в конец.
• Новые токены только в самом промпте компактации.
• Нужен «буфер компактации»: в окне должно хватить места на сообщение компактации и вывод саммари.
• Тот же принцип для любых побочных вычислений (суммаризация, выполнение скиллов): параметры префикса идентичны родительским.

Мониторинг

• Hit rate кэша мониторят как аптайм. В Claude Code на него стоят алерты, при низком значении объявляют SEV.
• Несколько процентных пунктов промаха заметно влияют на цену и задержку.
• Пороговых значений в статье нет: не подтверждено.
• Компактация встроена в API, tool search доступен через API.

Куда применить у нас

• Агентная разработка (Claude Code, Hermes, скилл-пак) — основное применение. Для Hermes: стабильные системный промпт и порядок инструментов (фиксированная сортировка, без правок параметров на ходу), даты и состояние только в сообщениях. Скиллы и побочные задачи запускать форком с теми же параметрами префикса. Смену модели делать субагентом, не переключением в сессии. Это совпадает с правилом из CLAUDE.md острова.
• GameHub — в статье нет ничего про NestJS, Postgres и античит-формулу, это не подтверждено. Вывод из правил, и только если в GameHub есть LLM-агент (поддержка, модерация): баланс токенов, время и состояние игрока передавать сообщениями, а не вшивать в системный промпт.
• Контент-каналы — если один агент пишет под разные соцсети, общий каркас и правила держать в статичной части, стиль конкретной сети и дневное состояние передавать сообщением. Это вывод из правила «обновления через сообщения», в статье про стили соцсетей нет. Для одной сессии модель не менять, черновики и разведку отдавать субагентам.
• v3ko.ru — статические страницы под тему статьи не подпадают. Правила применимы только к тем местам лаборатории, где есть вызовы LLM с длинным постоянным промптом (вывод из правил, не из статьи). Для таких мест: статика в начало, динамика в конец, детерминированный порядок.
• Монитор острова claude.dev (авторазбор через Claude CLI) — кандидат на проверку: есть ли в промпте разбора динамика (дата, id статьи) до статичной инструкции. Не подтверждено, код не проверялся.

Проверки

• ☐ Префикс запроса байт в байт совпадает между вызовами: нет меток времени, случайного порядка и изменяемых параметров в статичной части.
• ☐ Набор инструментов и их порядок не меняются в течение сессии. Режимы и состояния реализованы инструментами или сообщениями, а не заменой набора.
• ☐ Смена модели в сессии не происходит. Если нужна другая модель, это отдельный субагент с передаточным сообщением.
• ☐ Компактация и побочные вызовы (суммаризация, скиллы) используют тот же системный промпт, контекст и инструменты, что и родитель. Новым является только добавленное в конец сообщение, а в окне оставлен буфер.
• ☐ Hit rate кэша измеряется и по нему есть алерт. Порог в статье не указан, его задаёт владелец.

Задача: Проектирование набора инструментов агента: когда добавлять инструмент, когда убирать, когда вместо этого использовать прогрессивное раскрытие

Правила

Смотреть глазами агента

• Инструменты должны соответствовать способностям модели (аналогия: бумага → калькулятор → компьютер).
• Способности модели узнаются наблюдением: читать её выходы, экспериментировать.
• Лучший дизайн инструмента бесполезен, если Claude не понимает, как его вызывать.

Когда нужен отдельный инструмент (на примере AskUserQuestion)

• Попытка 1 — добавить массив вопросов в ExitPlanTool: провал, один инструмент одновременно просит план и вопросы, возникают конфликты ответов с планом.
• Попытка 2 — особый markdown-формат вывода: Claude выдавал его нестабильно (лишние предложения, потерянные варианты, уход от структуры).
• Попытка 3 — отдельный инструмент: структурированный вывод, гарантированно несколько вариантов, модальное окно блокирует цикл агента до ответа; инструмент можно использовать из Agent SDK и ссылаться на него в скиллах.
• Критерий: инструмент работает, если модель охотно его вызывает и результаты хороши.

Пересматривать инструменты по мере роста модели

• TodoWrite + системные напоминания каждые 5 ходов помогали раньше, но у более сильных моделей начали мешать: модель держалась списка вместо того, чтобы менять курс.
• Todo заменили на Task tool: зависимости между задачами, обмен обновлениями между субагентами, модель может менять и удалять задачи.
• Todo держат модель на курсе; задачи помогают агентам общаться между собой.
• Правило: ранее нужные инструменты могут ограничивать модель — регулярно пересматривать допущения.
• Поддерживать небольшой набор моделей с похожим профилем способностей — это упрощает пересмотр.

Поиск: пусть модель сама собирает контекст

• RAG (векторный индекс, готовые сниппеты) был быстрым, но требовал индексации и настройки, хрупок в разных средах; главное — контекст выдавали, а не находили.
• Grep-инструмент позволил Claude самому искать файлы и строить контекст.
• Прогрессивное раскрытие (Agent Skills): файл ссылается на другие файлы, модель читает рекурсивно. Типичное применение скилла — добавить поиск: как работать с API или запрашивать базу.
• За год модель дошла до вложенного поиска через несколько слоёв файлов.

Планка для нового инструмента — высокая

• В Claude Code сейчас ~20 инструментов; команда регулярно проверяет, все ли нужны. Каждый новый — ещё один вариант, о котором модели надо думать.
• Редко нужные знания не класть в системный промпт: это context rot и помеха основной работе.
• Шаг 1: дать ссылку на доки — работает, но модель тянет в контекст большие куски.
• Шаг 2: субагент (Claude Code Guide) ищет в доках в своём контексте по подробным инструкциям (как искать и что извлекать) и возвращает только ответ — основной контекст чистый.
• Ограничение: решение неидеально, Claude может путаться, когда его спрашивают о собственной настройке.

Общее

• Это искусство, а не наука: зависит от модели, цели агента и среды. Экспериментировать, читать выходы.

Куда применить у нас

• Агентная разработка (Claude Code, Hermes, скилл-пак): прежде чем добавлять новый инструмент, проверить, можно ли дать ту же функцию скиллом с прогрессивным раскрытием (файл → ссылки на другие файлы). Редко нужные справочные знания (например, правила Hermes) — в субагента, который ищет в своём контексте и возвращает только ответ, а не в общий промпт.
• Агентная разработка: провести ревью существующих костылей — напоминания, жёсткие чеклисты, шимы под прошлую модель — и проверить, не ограничивают ли они текущую модель (по примеру TodoWrite → Task). Статья подтверждает сам принцип, но не конкретные правила для Hermes — не подтверждено.
• GameHub: если у агента, работающего с кодовой базой (NestJS, Phaser), будет выбор «индекс или поиск», по статье предпочтителен Grep-подобный поиск самой моделью, а не заранее собранные сниппеты (RAG). Для задач с обязательным структурным ответом (например, выбор из вариантов) — отдельный инструмент со структурным выводом, а не договорённость о формате текста. Про античит-формулу и начисления токенов в статье ничего нет — не подтверждено.
• v3ko.ru / Контент-каналы: прямых правил в статье нет — не подтверждено. Косвенно применим только принцип «нужен структурированный ответ от модели — делать инструмент, а не просить формат в тексте», если в пайплайне постов есть шаг разбора ответа модели.

Проверки

• ☐ Для каждого нового инструмента есть письменный ответ, почему задачу нельзя решить скиллом/прогрессивным раскрытием или субагентом.
• ☐ Структурированный ответ модели получен через вызов инструмента, а не через разбор свободного текста; в логах нет потерянных вариантов и лишних предложений.
• ☐ Проведён пересмотр старых напоминаний и ограничений под текущую модель: каждое либо удалено, либо у него записано, зачем оно нужно.
• ☐ Справочный материал, нужный редко, не лежит в системном промпте; поиск по нему идёт в контексте субагента, а в основной контекст возвращается только ответ.
• ☐ Список инструментов агента короткий и регулярно пересматривается (ориентир из статьи — около 20 у Claude Code), и каждый инструмент модель действительно вызывает.