---
name: claude-code-auditor
description: >
  Аудит кода, написанного Claude Code, через «второе мнение» другой LLM
  (DeepSeek/GLM/Kimi): вызывает CLI Hermes (`hermes -z`) — свежий взгляд
  не-Claude модели: галлюцинации API, логические ошибки, edge cases,
  over-engineering. Пять линз: Скептик, Безопасность, Надёжность,
  Производительность, Поддерживаемость; режимы — коммит(ы), файлы,
  архитектура. Используй когда пользователь просит «второе мнение», «second
  opinion», «ревью от другой модели», «проверь что написал Claude», «линза
  скептика». Требует CLI `hermes`. Для ревью силами самого Claude — techlead-ai.
metadata:
  version: 1.1.0
---

# 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` печатает **только** ответ модели):

```bash
# Дефолтная модель-аудитор (берётся из конфига 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](references/audit-prompts.md).

## Линзы аудита

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

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

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

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

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

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

```bash
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](references/audit-prompts.md))
   и вызови `hermes -z "..."` через `Bash`. Большой вход — по частям.
5. **Представь результаты** по формату
   [references/output-format.md](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`, используется
  ли он ещё где-то в проекте.