Commandments Check

---
name: commandments-check
description: Аудит текущего приложения по «Заповедям студии» — статус-таблица в PLAN.md
allowed-tools: Read, Grep, Glob, Bash, Edit, Write
disable-model-invocation: true
---

> Параметры берутся из запроса пользователя. В Claude Code маркеры `$ARGUMENTS` и `$1`…`$9` подставляются при вызове навыка.

# Аудит по заповедям студии

Проверяет текущее приложение против раздела «Заповеди студии» из приватного бизнес-плана
студии — не разовая просьба клиента, а собственный стандарт качества студии (см.
`feedback_forms_not_customer_driven` в памяти). Источники (оба в приватном submodule
`.claude/private/`, не коммитятся в публичный `letar`):

- [`WEBSTUDIO.md`](/.claude/private/WEBSTUDIO.md) — раздел «Заповеди студии» (§89 и далее) —
  текст-источник, полная формулировка каждой заповеди.
- [`COMMANDMENTS_CHECKLIST.md`](/.claude/private/COMMANDMENTS_CHECKLIST.md) — техническая
  проекция: как проверить каждую заповедь (grep-паттерны, что читать глазами), когда заповедь
  неприменима к приложению.

## Шаг 0: контекст

1. Определи целевое приложение — из `$ARGUMENTS`, иначе из текущей рабочей директории
   (`apps/<app>/`). Если не удаётся определить — спроси пользователя.
2. Если сессия ещё не зарегистрирована в Agent Mail для этого приложения — зарегистрируйся
   (`.claude/rules/agent-mail.md`, `.claude/rules/app-workflow.md`).
3. Прочитай оба источника из `.claude/private/` целиком.

## Шаг 1: пройди таблицу заповедь за заповедью

Для каждой строки `COMMANDMENTS_CHECKLIST.md`:

1. Выполни указанную проверку (grep/чтение кода) — реальную, не по памяти о похожих
   приложениях.
2. Определи статус: ✅ соблюдено / ⚠️ частично или не проверено / ❌ нарушено /
   ➖ неприменимо (с кратким обоснованием — колонка «когда неприменимо» в чек-листе как
   подсказка, не готовый ответ, применимость решай по факту приложения).
3. Если статус ❌ **и** в `WEBSTUDIO.md` у этой заповеди явно написано «не начато технически» —
   это НЕ таск на текущее приложение. Помечай `❌ (техдолг студии — см. кандидат в libs/)` и не
   предлагай точечный фикс внутри `apps/<app>`.
4. Если статус ❌ на заповеди, которая **где-то уже реализована** (см. заповеди с готовым
   механизмом в `@letar/forms`/`@letar/ui` — №8, №9, №23 и т.п.) — это обычный локальный долг,
   предлагай подключить существующий компонент/хук, не изобретать заново.

Не исправляй код в этом шаге — только собери статусы. Исправления — отдельная задача после
согласования с пользователем (список ❌ может быть длинным, чинить всё разом не нужно).

## Шаг 2: запиши результат

Добавь/обнови в `apps/<app>/PLAN.md` раздел `## Аудит заповедей студии`:

```markdown
## Аудит заповедей студии

_Дата: YYYY-MM-DD. Методология — `.claude/private/COMMANDMENTS_CHECKLIST.md`._

| № | Заповедь              | Статус | Где живёт / что сделать |
| - | --------------------- | ------ | ----------------------- |
| 1 | Списки: подгрузка+URL | ⚠️      | ...                     |
```

Не переписывай прошлый аудит поверх — если раздел уже есть, допиши новую дату ниже, старую
оставь (динамика важнее одной точки).

## Шаг 3: отчёт пользователю

Не дублируй всю таблицу в чат — только сводку:

- Сколько ✅ / ⚠️ / ❌ / ➖ всего.
- Список ❌, отсортированный на «локальный долг (готовый механизм есть)» и «техдолг студии
  (кандидат в libs/)».
- Явно спроси, чинить ли что-то сейчас или это остаётся списком на будущее — этот аудит сам по
  себе не должен запускать правки без подтверждения (список может быть длинным и с ложными
  срабатываниями на первом прогоне).

## После завершения

Если находки существенно уточнили сами критерии проверки (например, grep-паттерн не сработал
или дал ложный результат) — обнови `COMMANDMENTS_CHECKLIST.md`, не только результат в
`PLAN.md`: чек-лист должен становиться точнее с каждым прогоном на реальном приложении.