spec-reviewer

Субагент для анализа готовности спецификации к выполнению AI-агентами. НЕ вызывай напрямую — используется через /spec-review команду. Анализирует: достаточно ли контекста для LLM, есть ли примеры, определены ли границы автономности, точки эскалации к человеку, критерии успешности для AI.

Субагент для бизнес-анализа спецификаций. НЕ вызывай напрямую — используется через spec-reviewer оркестратор. Анализирует бизнес-аспекты: цели, user stories, acceptance criteria, бизнес-правила, роли, права доступа, edge cases.

Субагент для анализа API и интеграций в спецификациях. НЕ вызывай напрямую — используется через /spec-review команду. Анализирует: API endpoints, контракты, интеграции с внешними системами, webhooks, error handling, версионирование API.

Субагент для проверки покрытия спецификации по трём осям. НЕ вызывай напрямую -- используется через /spec-review команду. Анализирует: для каждой фичи/функции -- есть ли описание что строим (PRD, User Story), как строим (ERD, API, C4), как проверяем (Test Plan, AC).

Легковесный классификатор спецификаций (haiku). НЕ вызывай напрямую — используется через /spec-review команду. Быстро определяет: 1. Какие аспекты присутствуют в спецификации (для выбора агентов) 2. Предварительную оценку объёма (quick scope)

Субагент для анализа данных в спецификациях. НЕ вызывай напрямую — используется через /spec-review команду. Анализирует: модели данных, схемы БД, миграции, консистентность, связи между сущностями, валидацию, хранение.

Субагент для анализа инфраструктуры и безопасности в спецификациях. НЕ вызывай напрямую — используется через /spec-review команду. Анализирует: deployment, безопасность, мониторинг, масштабируемость, производительность (NFR), CI/CD, инфраструктуру.

Субагент для анализа рисков в спецификациях. НЕ вызывай напрямую — используется через /spec-review команду. Анализирует: технические риски, бизнес-риски, зависимости от внешних факторов, что может пойти не так, mitigation strategies.

Субагент для оценки объёма спецификации и разбиения на части. НЕ вызывай напрямую — используется через /spec-review команду. Анализирует: количество фич, сложность, зависимости. Определяет влезает ли в одну сессию, предлагает декомпозицию.

Субагент для анализа тестируемости спецификаций. НЕ вызывай напрямую — используется через /spec-review команду. Анализирует: можно ли написать тесты по спеке, какие test cases очевидны, что сложно протестировать, где неоднозначности мешают тестированию.

Субагент для UX/UI анализа спецификаций. НЕ вызывай напрямую — используется через /spec-review команду. ОПЦИОНАЛЬНО: запускается только если спецификация касается пользовательского интерфейса. Анализирует: user flows, UI states, edge cases в интерфейсе, accessibility, responsive design, loading/error states.

**UNIVERSAL TRIGGER**: Ревью спецификаций и ТЗ на гапы, нестыковки и противоречия. Используй когда: - "get/show/list/display spec issues", "retrieve spec analysis" - "check/analyze/fetch spec review", "review spec" - "проверь спецификацию/ТЗ", "ревью спеки", "проанализируй ТЗ" - "найди гапы в требованиях", "найди нестыковки/противоречия" - пользователь дал ссылку на Google Doc, GitHub issue или Docmost-документ со спецификацией - пользователь вставил текст спецификации и просит проверить **Уровни глубины**: - `--quick` / `-q` — только критические блокеры (быстро) - `--standard` / `-s` — критические + высокие (по умолчанию) - `--deep` / `-d` — все проблемы включая средние - `--exhaustive` / `-e` — полный аудит с рекомендациями - `--no-ask` — использовать standard без вопроса (для CI/CD) **Ключевые слова для уровней**: - "быстро проверь", "только блокеры" -> quick - "тщательно", "подробно", "глубоко" -> deep - "полный аудит", "исчерпывающий" -> exhaustive **Google Doc**: - "проверь спеку docs.google.com/document/d/XXX" - "ревью этого ТЗ [ссылка на Google Doc]" **Docmost**: - "проверь спеку https://docs.company.com/p/XXXXXXXX" - "ревью этого ТЗ в Docmost [ссылка]" **GitHub Issue** (ТОЛЬКО с ревью-контекстом!): - "проанализируй issue #123" (ревью-слово: "проанализируй") - "проверь спецификацию github.com/.../issues/456" (ревью-слово: "проверь") - голый "issue #123" без ревью-контекста -- НЕ триггер (github-issues или task-routing) **Текст в сообщении**: - "проверь это ТЗ: [текст спецификации]" - пользователь вставил большой текст и просит ревью **Локальный файл**: - "проверь спеку в docs/spec.md" - "сделай ревью файла requirements.txt" TRIGGERS: спецификация, ТЗ, spec, specification, requirements, проверь спеку, ревью спеки, review spec, analyze spec, найди гапы, найди противоречия, найди нестыковки, docs.google.com/document, github.com/issues, docmost, /p/, техническое задание, требования, acceptance criteria, проанализируй требования, check requirements, --quick, -q, --deep, -d, --exhaustive, -e, --no-ask, быстро проверь, тщательно проанализируй, полный аудит, только блокеры, глубокий анализ, исчерпывающий