Рабочий сетап Claude Code — главная сессия работает на модели Fable 5, собран вокруг трёх идей:
Edit/Write в главном потоке./clear на границе задач.В репозитории — переиспользуемые куски этого сетапа: скиллы, агенты, хуки и скрипты. Ничего специфичного для конкретной компании или инфраструктуры здесь нет — это методология и тулинг, конфиги подставляются под свой проект.
Рассчитано на опытных разработчиков, которые уже работают с Claude Code и хотят собрать похожий контур себе.
Живая версия страницы: claude.zardes.dev.
Главная модель сессии (Fable 5) отвечает за три вещи: ставит задачу, выбирает исполнителя, ревьюит результат. Она не читает код файлами и не правит его сама — за это отвечает хук decider-gate.
Как это работает: decider-gate висит на PreToolUse для Edit/Write/MultiEdit/NotebookEdit. Если вызов идёт из главного потока — хук возвращает deny с сообщением «делегируй субагенту»; если вызов идёт из субагента (в hook-input есть agent_id) — пропускает без вопросов. Отключить на сессию, когда нужно поправить руками: переменная окружения перед запуском.
Субагентов запускают с моделью, минимально достаточной для задачи — не «на всякий случай мощнее».
| Модель | Сложность | Примеры задач |
|---|---|---|
| haiku | Простые | Поиск файлов, чтение конфигов, grep, короткие вопросы |
| sonnet | Средние | Написание кода, фиксы багов, рефакторинг, тесты |
| opus | Сложные | Архитектура, планирование, сложная отладка, ревью критичного кода |
Правила выбора: по умолчанию — sonnet, если не уверен; haiku — если задача закрывается за 1-2 вызова инструментов; opus — только когда нужен глубокий анализ или планирование; Explore-агент всегда на haiku (он для быстрого поиска); Plan-агент предпочтительно на opus (качество планирования критично для последующих фаз).
Дешёвый агент, упёршийся в критичную развилку, не обязан гадать или молча эскалировать себя до дорогой модели. Два пути:
consult-opus.sh — headless second opinion: read-only вызов Claude в print-режиме (claude -p --model opus --max-turns 6 --allowedTools "Read,Grep,Glob"), лимит 6 ходов, модель переопределяется переменной окружения. Возвращает вердикт одной строкой + обоснование в 2-5 предложениях + на что обратить внимание.ESCALATE: <вопрос> в отчёте субагента — main решает сам или адресует точечный вопрос opus-агенту. Эскалируется вопрос, а не вся задача — не нужно перезапускать работу целиком на дорогой модели.Лимит — 1-2 эскалации на задачу.
Рутинные атомарные задачи (саммари, парсинг, конвертации, boilerplate, кодовые правки по точному брифу) можно вынести за пределы подписки на внешние модели через OpenRouter — это дешевле любого тира Claude на порядок.
or-task.sh [-m flash|pro|qwen] [-o max_tokens] [-t timeout_s] "бриф" [файл ...]
| Алиас | Класс модели | Для чего |
|---|---|---|
flash (дефолт) |
компактная модель общего назначения | саммари, парсинг, конвертации, boilerplate, черновики |
pro |
модель среднего класса | тяжёлые черновики и планы |
qwen |
code-специализированная модель | кодовые правки по точному брифу — самая буквальная из трёх |
Встроенные ограничители: cap на max_tokens (по умолчанию 4096), таймаут на весь вызов (по умолчанию 180 с), cap на объём входа (~300k символов — больше делить задачу, не заливать целиком). Ключ читается из локального env-файла, никогда не коммитится.
Фоллбэки — тихая замена исполнителя запрещена, всё проговаривается в чате:
Результат внешнего воркера всегда ревьюит main сам (diff или вывод читает, а не верит отчёту) — скоупинг чужой работы дороже самой экономии, если его пропустить.
Скилл pm — оркестрация нетривиальных задач: main не делает работу сам, а решает, распределяет по субагентам и сводит результат. Работает как для кода, так и для не-кодовых продуктовых задач.
Три вопроса без запуска агентов:
Размер задачи:
| Size | Триггер | Воркеры | Роль main |
|---|---|---|---|
| S | <50 строк / 1-2 файла / понятный фикс | 1× haiku | супервизия + ревью |
| M (дефолт) | 50-500 строк, 1 модуль | 2-3× sonnet | план + сведение |
| L | 500+ строк, много модулей | 4-6 разных моделей | полный конвейер |
| XL | архитектура / больше пары дней / auth-payments-данные | 6-10 разных моделей, effort max | полный конвейер + аудит безопасности |
Когда /pm не нужен: 1-2-строчная правка в файле, который уже открыт; прямой ответ на вопрос; чистая документация или опечатка — если main сделает быстрее сам, чем брифовать агента, не оркеструет.
Пять шагов, если ответ на вопрос 3 — «да»:
| Для задачи с нуля, без референса в текущем репозитории, один агент-архитектор (sonnet) предлагает 2-3 паттерна реализации в формате «паттерн | плюсы | минусы | для чего лучше подходит | риск» и финальную рекомендацию. Очевидный выбор фиксируется в plan.md под отдельным разделом; близкие по весу варианты выносятся на явный выбор пользователя, а не решаются молча. Дальше конвейер не идёт без зафиксированного паттерна — это самая дешёвая точка для смены архитектурного решения, дальше цена ошибки растёт. |
plan.md с разделами Goal / Non-goals / Assumptions / Success criteria / Pattern / Steps (каждый шаг — с verify:, командой или тестом, а не словом «работает») / Risks / Outcome. Пути в шагах — точные (file:line, где известно), чтобы следующая сессия могла продолжить без повторного ресёрча._active.md — построчный индекс активных задач (slug | status | next action | дата обновления), который автоматически подтягивается в каждую новую сессию через SessionStart-хук. Одна строка — одна сессия-владелец; чужой slug не перехватывается.name, конкретные trigger-фразы в description — от них зависит авто-делегация, tools по минимуму, модель по матрице). Одноразовый домен — обычный general-purpose с подробным брифом, агента не плодим.Обязателен для: фиксов багов (тест, воспроизводящий именно сценарий из репорта, пишется до фикса), контрактов API, бизнес-логики, критичного кода. Пропускается для UI-правок, конфигов, чистого рефакторинга при существующих тестах, спайков, документации.
Цикл: Red (агент-автор теста подтверждает, что тест падает) → main читает диф теста (нет ли подгонки под ответ, пустых assertion’ов) → Green (агент-разработчик доводит до зелёного минимальными правками) → опционально Refactor.
Каждый бриф разработчику включает обязательный блок «Правила кода»: минимум кода без фич сверх брифа; трогать только заявленные файлы, не улучшать соседнее; каждая изменённая строка должна прямо следовать из брифа; критерий успеха прогоняется перед отчётом, вывод прикладывается. Без этого блока в брифе агент по умолчанию «улучшит» половину файла заодно.
Ключевое правило фазы верификации: собственная машина — почти всегда точка с гарантированно рабочим внешним путём, поэтому проверка с неё даёт ложный зелёный (классическая ловушка: запрос снаружи отвечает 200, а потребитель во внутренней сети лежит). Каждый потребитель проверяется с его собственного хоста и его собственного реального пути аутентификации — подстановка своего или пустого креда вместо того, что реально использует потребитель, даёт ложный FAIL (401/403 на рабочем сервисе). При «connection refused» от потребителя сначала проверяется, слушает ли сервис на его реальном адресе — в большинстве случаев дело в адресе или маршруте, а не в самом сервисе.
Verify возвращает вердикт PASS/FAIL/WARN с issues, размеченными по severity, где каждый issue мапится на конкретную непройденную букву CLEAR. FAIL уводит обратно в фазу разработки с точным диффом и списком issues; WARN — на обсуждение; PASS — в фазу сведения.
| Роль | Модель |
|---|---|
| PM (main) | Fable 5, effort high |
Архитектор / аналитик / разработчик / тестировщик / code-reviewer / git-workflow-manager |
sonnet |
| Explore / точечный lookup / haiku-специалисты | haiku |
security-auditor / критичное ревью / планировщик архитектуры |
opus |
Ориентир по итогу задачи — минимум 60% воркеров на sonnet/haiku, не больше 40% на opus. Дорогая модель — это выбор для конкретной развилки, а не тир по умолчанию.
Main читает артефакты задачи, заполняет Outcome в plan.md (что сделано, что нет и почему, какие решения принял пользователь), закрывает или обновляет строку в _active.md, предлагает /clear. Планы не удаляются — это журнал аудита.
Жёсткие ограничения конвейера: не больше 3 параллельных research-агентов; 1 dev-агент на файл; не больше 10 параллельных агентов в одной волне; крупные артефакты уходят в файлы задачи, в чат — только ссылка и короткое summary.
Список составлен по фактическим повторяющимся ошибкам, а не гипотетически:
verify: — «сделано» без доказательства, которое можно перепроверить.general-purpose с подробным брифом.description у нового агента («помогает с кодом») — авто-делегация не сработает, триггер-фразы должны быть конкретными.Четыре поведенческих правила против типичных ошибок LLM при написании кода:
Перед тем как выдать нетривиальный результат — код, план, ресёрч, фактическое утверждение — он молча прогоняется по пяти буквам. Пункт не проходит — чинится; пункт нельзя проверить — это помечается явно, а не выдаётся как факт.
Karpathy-правила задают критерий до работы, CLEAR проверяет результат после — они дополняют друг друга, а не дублируют.
Ручной toggle экономии выходных токенов: режет преамбулы, пересказ вопроса, вежливые концовки и hedging, оставляя код, команды, пути, конфиги, ошибки и числа байт-в-байт. Не применяется к текстам, которые явно попросили развёрнуто, и к текстам для внешних адресатов (commit message, PR description, письма) — там обычный стиль. Выключается словами «caveman off» / «verbose».
Прогоняется через любой текст перед тем, как он уйдёт наружу — в тикет-трекер, рабочие чаты, коммиты, PR, командную документацию. Вычищает: прямые упоминания AI/модели/ассистента; мета-ссылки на внутреннюю кухню ресёрча; характерные буззворды (delve, leverage, comprehensive, robust, seamless, streamline, consolidate, modernize, enhanced, utilize, facilitate, ensure, foster, unlock, empower — и их русские аналоги вроде «обеспечивает бесшовную интеграцию»); обращение к себе в третьем лице; сводочный тон («вот краткая сводка», «в заключение»); оверэксплейн там, где хватит строки; симметричные списки-ради-списков и эмодзи-заголовки. На выходе — только чистый текст, готовый к отправке.
Отдельное жёсткое правило, действующее всегда и без исключений: никаких упоминаний AI/Claude/GPT/нейросетей в коммитах, PR, комментариях к коду и Co-Authored-By. Весь код и все коммиты должны выглядеть как обычная работа разработчика.
На диске — 78 директорий скиллов. Активны (участвуют в авто-триггере) — 28; ещё 50 припаркованы через skillOverrides в settings.json, чтобы не платить контекстом за скиллы, которые нужны редко (в основном маркетинг-пак: реклама, SEO, копирайтинг, пришлось выключить целиком — 8 августа 2026 они съедали заметную часть контекста каждой сессии просто на листинг).
Механика самообслуживания: если задача пахнет доменом припаркованного скилла — не нужно ждать, пока кто-то включит его насовсем. Каталог skills-parked.md держит список имён и однострочных описаний; текущая сессия читает нужный SKILL.md напрямую и следует ему без активации харнесса. Если домен всплывает регулярно — имя скилла убирается из skillOverrides, и со следующей сессии он снова в общем листинге.
Ключевые активные скиллы:
| Скилл | Что делает |
|---|---|
pm |
Оркестрация нетривиальных задач — декомпозиция, подбор агентов, TDD-цикл, сведение результата (см. раздел выше) |
sec |
Хардкорный security-аудит — секреты, SAST, CVE зависимостей, контейнеры, сеть, TLS, авторизация; шире встроенного diff-only ревью |
karpathy-guidelines |
Четыре поведенческих правила против типичных ошибок LLM в коде (см. раздел выше) |
caveman |
Терсе-режим вывода, ручной toggle (см. раздел выше) |
stop-slop |
Вычистка AI-следов и буззвордов из любого текста перед отправкой наружу |
systematic-debugging |
Систематический разбор бага или неожиданного поведения перед тем, как предлагать фикс |
test-driven-development |
TDD-цикл при реализации любой фичи или бага — тест до кода |
verification-before-completion |
Обязательный прогон верификационных команд с подтверждённым выводом перед заявлением «готово» |
code-quality |
Envelope качества вокруг нетривиального кода — типы тестов, покрытие, мутационное тестирование, quality gates |
grilling |
Стресс-тест плана или решения через серию въедливых вопросов |
handoff |
Файл передачи сессии — состояние задачи для следующего окна или коллеги |
time-report |
Отчёт «работа / ожидание» по использованию Claude Code |
13 постоянных агентов, каждый — под конкретный домен, а не универсальный general-purpose. Принцип из description: конкретные триггер-фразы, а не общие формулировки — от этого зависит, сработает ли авто-делегация.
| Агент | Модель | Назначение |
|---|---|---|
ansible-devops |
sonnet | Playbooks, роли, inventories, vault, CI/CD, docker-compose оркестрация |
code-reviewer |
sonnet | Ревью диффов, MR/PR — корректность, безопасность, производительность, соответствие конвенциям проекта |
database-administrator |
sonnet | PostgreSQL и Redis — репликация, тюнинг запросов, индексы, connection pooling, бэкапы |
debugger |
sonnet | Баги в коде — стектрейсы, исключения, логические ошибки, гонки, утечки памяти (не инфраструктура) |
dependency-manager |
haiku | Аудит зависимостей — CVE, версии, lockfile-гигиена, лицензии |
docker-expert |
sonnet | Dockerfile, multi-stage сборки, размер образа, сканирование CVE/SBOM |
fable-deep |
Fable 5, 1M контекст, effort xhigh | Архитектурные решения по всему репозиторию, cross-cutting рефакторинг, сложная отладка, требующая всего кодбейса в одном окне — только по явному разрешению на конкретный вызов, никогда не авто-триггерится |
git-workflow-manager |
sonnet | Ветвление, релизная автоматизация, changelog, pre-commit хуки, conventional commits |
infra-debugger |
sonnet | Диагностика инфраструктуры и сервисов по строгому циклу S0-S6, факты прежде фиксов |
network-engineer |
sonnet | Проектирование и хардненинг сети — VPN, файрвол, DNS, роутинг, NAT/hairpin, TLS |
performance-engineer |
sonnet | Профилирование, поиск узких мест, нагрузочное тестирование, кэширование |
security-auditor |
sonnet, effort high | Глубокий анализ безопасности — auth-флоу, сессии, секреты, PII, доступы, криптография |
terraform-engineer |
sonnet | Terraform — модули, ревью plan/apply, state backend, workspaces, дрифт |
| Событие | Скрипт | Зачем |
|---|---|---|
UserPromptSubmit |
track-time.sh |
Логирует работу/ожидание в JSONL для отчёта по времени |
UserPromptSubmit |
warn-session-length.sh |
Предупреждает о разросшейся сессии (ориентир — около 1500 запросов без смены задачи) |
PreToolUse (Bash) |
secret-scan-precommit.sh |
Перед git commit сканит staged-изменения на секреты; блокирует коммит, если найден токен внутри разрешённого пути |
PreToolUse (Bash) |
guard-destructive.sh |
Запрашивает подтверждение на потенциально деструктивные команды |
PreToolUse (Edit/Write/MultiEdit/NotebookEdit) |
decider-gate.sh |
Блокирует правки из главного потока — печатают только субагенты (см. «Архитектура сессии») |
PreToolUse (Read/Edit/Write) |
guard-sensitive-files.sh |
Запрашивает подтверждение на доступ к секретам, приватным ключам, vault-файлам |
PostToolUse (Edit/Write) |
format-on-write.sh |
Best-effort автоформат только что записанного файла, если форматтер установлен; никогда не блокирует |
PreCompact |
compact-mark.sh |
Оставляет ровно одну метку в _active.md — после сжатия контекста главный поток видит, что контекст обрезан, и перечитывает plan.md, а не полагается на summary |
SessionStart |
инжект _active.md |
Подтягивает индекс активных задач в начало новой сессии без ручного поиска |
Stop |
checkpoint-on-stop.sh, notify.sh, track-time.sh |
Атомарный git-checkpoint через stash create/stash store (без касания рабочего дерева и индекса), звуковое уведомление, лог времени |
SessionEnd |
track-time.sh |
Закрывает запись времени сессии |
Семантический поиск по коду — MCP-сервер поверх локального Milvus (векторная БД в Docker) и Ollama с моделью nomic-embed-text. Полностью локально, без внешнего API — стоимость поиска нулевая. Индекс персистентный и обновляется инкрементально; при первой работе над проектом кодовая база индексируется один раз, дальше поиск идёт по готовому индексу.
Правило разделения инструментов: точный текст или известное имя символа — обычный grep/аналог с regex; поиск по смыслу («где у нас обрабатывается retry-логика для внешних вызовов») — semantic search.
Вторичный инструмент — CLI с построением графа вызовов (trace: кто вызывает функцию и что вызывает она), полезен для трассировки зависимостей, которые векторный поиск не покажет напрямую. Фоновый демон-наблюдатель за изменениями файлов сознательно не держится постоянно запущенным — он молча умирал без уведомления; вместо этого перед использованием проверяется, жив ли он, и поднимается по необходимости.
Каждый слой хранит свой тип информации, факт не дублируется между слоями — только ссылка.
| Слой | Что хранит | Кто пишет |
|---|---|---|
pm/<slug>/plan.md + _active.md |
Состояние задач: шаги, следующее действие, решения по конкретной задаче | PM-конвейер по ходу работы |
Auto-memory (MEMORY.md + файлы) |
Долгоживущие факты проекта: доступы, особенности, контракты, «как тут устроено» | Модель, когда факт переживёт задачу |
| Плагин памяти сессий | Хроника сессий для recall — пишется автоматически | Сам плагин, руками не трогается |
docs/ репозитория |
Командное знание: гайды, разбор инцидентов, инвентарь | По правилам конкретного репозитория |
Правило записи: решение принято или факт установлен (где лежит доступ, от чего ломается сервис, что выбрали и почему) — строка уходит на диск в тот же ход, не «в конце сессии». Компактизация контекста может случиться в любой момент и ничего сама на диск не пишет; хук на PreCompact только оставляет метку — увидев её после сжатия, читается plan.md, а не summary модели.
Факт, который уже есть в одном слое, в остальных живёт как ссылка, а не копия. Протух — чинится в источнике.
Метрики использования (запросы, токены, стоимость по сессиям и проектам) собираются через OTLP-телеметрию Claude Code в self-hosted Grafana — без передачи данных куда-либо ещё, инструмент личный.
Выводы из аудита, которые определили архитектуру сетапа:
fable-deep)./clear на границе логических задач и ориентир: сессия перевалила за ~1500 запросов без смены типа работы — это уже не работа, а перечитывание истории.| Плагин | Назначение |
|---|---|
claude-mem |
Хроника сессий (memory) — автоматически пишет наблюдения по ходу работы, отдельный слой от plan.md/_active.md, см. раздел «Память» |
claude-hud |
Кастомный statusline — темп расхода 5-часового и недельного лимита, модель, время работы прямо в строке статуса |
codex |
Второе мнение другой моделью — делегирование ресёрча, диагностики или отдельной подзадачи через отдельный CLI прямо из сессии Claude Code |
security-guidance |
Встроенные подсказки по безопасности поверх стандартного diff-only ревью |
frontend-design |
Гайдлайны визуального дизайна — типографика, композиция, отход от шаблонных дефолтов при работе над UI |
i-have-adhd |
Альтернативный формат структурирования ответов — короче, с явной структурой, меньше когнитивной нагрузки на чтение |
Публичные репозитории автора:
Отдельным паттерном, без прямой ссылки: приватный бэкап-репозиторий всего ~/.claude с redaction-скриптами, вычищающими секреты и корп-контекст перед коммитом, и rolling-release веткой для тяжёлых бинарных данных (индексы, кэши). Такой репозиторий имеет смысл держать отдельно от публичного — он хранит личную конфигурацию целиком, а не только переиспользуемые куски.
skills/, agents/, hooks/, scripts/) в ~/.claude/ — глобально, или в <project>/.claude/ — под конкретный репозиторий.settings.json — структура и матчеры показаны в settings.example.json; путь к скриптам поправить под свою систему.CLAUDE.global.example.md, дальше редактируется под свой стиль работы.chmod +x) и наличие зависимостей, которые они вызывают (git, опционально gitleaks для сканирования секретов).