Claude code auditor

Claude Code Auditor

Аудит кода, созданного Claude Code, силами другой LLM — чтобы найти то, что Claude Code пропустил: галлюцинации, логические ошибки, неучтённые edge cases, архитектурные проблемы. Claude не аудирует сам себя — он делегирует проверку не-Claude модели через CLI Hermes и представляет её отчёт пользователю.

Зачем

Claude Code мощный, но: галлюцинирует несуществующие API/методы; склонен к over-engineering; иногда пропускает импорты и граничные случаи; работает в изолированном контексте и может не видеть общей картины. Другая модель смотрит на тот же код свежим взглядом — это code review от второго разработчика, но быстро и без соц-нагрузки на команду.

Механизм: второе мнение через CLI Hermes

В Claude Code нет встроенного инструмента делегирования другой LLM. Мост — hermes как CLI в режиме one-shot (-z печатает только ответ модели):

# Дефолтная модель-аудитор (берётся из конфига Hermes; сейчас deepseek/deepseek-v4-pro @ openrouter)
hermes -z "ПРОМТ_АУДИТА_С_КОДОМ"

# Явный выбор модели/провайдера под задачу:
hermes -z "ПРОМТ_АУДИТА" -m deepseek/deepseek-v4-pro --provider openrouter   # глубокий анализ, большой объём
hermes -z "ПРОМТ_АУДИТА" -m z-ai/glm-5.2          --provider openrouter      # быстрый чекап diff/файла

Правила:

• Модель-аудитор ≠ модель, писавшая код. Код писал Claude → аудируй не-Claude (DeepSeek / GLM / Kimi). Свежий взгляд нужен именно от другого семейства моделей.
• Не хардкодь версии моделей — они устаревают. Текущие ID смотри через hermes model (или каталог моделей Hermes). В тексте — лишь актуальные на момент написания примеры.
• Сообщи пользователю, какой моделью аудируешь: «Аудирую DeepSeek 4 Pro. Хочешь другую (GLM 5.2 / Kimi) — скажи».
• Большой вход (>~500 строк) дроби по файлам/модулям, чтобы аудитор не терял контекст; на больших объёмах бери модель с большим окном (DeepSeek Pro, Kimi).
• Сам код собирай инструментами Claude Code: git diff/git log через Bash, Read для файлов, Grep/Glob для проверки существования API и поиска паттернов проекта.

Готовые промты аудитора (базовый + по режимам) — в references/audit-prompts.md.

Линзы аудита

Линза — роль, с которой модель-аудитор смотрит на код; разные линзы ловят разные классы проблем. По умолчанию (если пользователь просто просит «аудит») — Скептик. Можно применить одну линзу или несколько последовательно.

Линза	Фокус
Скептик	Всё под вопросом, каждая строка — потенциальная проблема. Самая жёсткая.
Безопасность	Инъекции, утечки, права доступа, exposed secrets.
Надёжность	Обработка ошибок, edge cases, fallback'и, таймауты.
Производительность	N+1, лишние аллокации, блокировки, неоптимальные структуры.
Поддерживаемость	Читаемость, DRY, именование, документация, избыточная сложность.

Подробные описания, когда какая линза полезна, промт-добавки на каждую линзу и правила комбинирования — в references/lenses.md.

Режимы аудита

Режим	Когда	Вход
Diff	Claude Code только что внёс изменения	git diff — коммит, N коммитов или working tree
Файловый	Проверить конкретные файлы/модули	список путей
Архитектурный	Claude Code спроектировал фичу/модуль	описание архитектуры + ключевые файлы

Глубина diff (если не указана — спроси):

git diff HEAD~1..HEAD        # последний коммит
git diff HEAD~10..HEAD       # N последних коммитов
git diff                     # незакоммиченные изменения (working tree)
git log --oneline -10        # найти границы коммитов

При аудите >3 коммитов предупреди об объёме и предложи разбить на порции или взять модель с большим контекстом.

Процесс

1. Шаг 0 (обязательно): загрузи контекст проекта. Прочитай CLAUDE.md полностью, релевантные секции ARCHITECTURE.md, при наличии — AGENTS.md / .cursorrules. Особое внимание: запреты («никогда не делай X»), правила сохранения моделей, соглашения по коду, предупреждения о race conditions. Если проект на harness-engineering — эти документы каноничны: любая рекомендация аудита, им противоречащая, ошибочна. Если их нет — отметь в начале отчёта: «Проект без harness-документации; рекомендации могут не учитывать неявные соглашения».
2. Собери вход под режим: git diff / Read файлов / описание архитектуры.
3. Выбери линзу (по умолчанию Скептик) и модель (сообщи пользователю).
4. Сформируй промт (references/audit-prompts.md) и вызови hermes -z "..." через Bash. Большой вход — по частям.
5. Представь результаты по формату references/output-format.md: проблемы, сгруппированные по severity, + что предложить после.

Когда аудит полезен / избыточен

Полезен: после крупных изменений Claude Code (>100 строк или >3 файлов); в незнакомой кодовой базе (выше риск галлюцинаций); перед коммитом/деплоем; когда «работает, но странно». Избыточен: правки в 1–2 строки, фикс опечатки, конфиги; знакомый фреймворк и <50 строк.

Связанные навыки

• techlead-ai — глубокое code review силами самого Claude. Этот навык отличается принципиально: проверку делает другая модель. Используй claude-code-auditor, когда важен независимый взгляд не-Claude модели.
• harness-engineering — задаёт CLAUDE.md/ARCHITECTURE.md как канон. Шаг 0 обязателен; если аудит вскрыл системные проблемы — стоит проверить и сами эти документы.
• django-audit / python-project-audit — для более глубокого фреймворк-специфичного или инструментального аудита Python/Django.
• clarify-prompt — если запрос на аудит размыт, переформулируй перед отправкой модели-аудитору.

Уроки (pitfalls)

• Тяжёлый save(). Не предлагай obj.save() без update_fields там, где у модели «тяжёлый» save() (дёргает пересчёт полей, санитайз HTML и т.п.) — CLAUDE.md проекта может явно это запрещать. Без контекста проекта легко посоветовать анти-паттерн → всегда выполняй Шаг 0.
• Не смешивай scope коммитов. При аудите N коммитов не относи проблемы из старых коммитов к текущему. Проверяй git log/git blame изменённых строк, чтобы понять, какой коммит привнёс конкретную строку.
• Alias/совместимость без проверки использования. Не предлагай удалить «временный» alias или старый путь, не проверив через Grep/rg, используется ли он ещё где-то в проекте.