
Обновление конфигурации, деактивация или переименование агента. Используй при изменении промпта агента, смене модели, деактивации устаревшего агента или миграции на новое имя.
Проверка AGENT.md на соответствие стандарту — frontmatter, промпт, секции, ссылки. Используй после создания или изменения агента, при code review или перед коммитом.
Создание git-ветки по стандарту именования с привязкой к analysis chain. Используй при начале работы над задачей — автоматически формирует имя ветки из номера анализа NNNN.
Завершение analysis chain — pre-flight проверки, T7 DONE каскад, перенос Planned Changes в AS IS, system-agent mode=done, cross-chain, отчёт. Используй при переводе цепочки из REVIEW в DONE.
Оркестратор полного цикла — создаёт TaskList от идеи до релиза по standard-process.md. Используй при запросе на добавление функциональности, изменение поведения, исправление бага или любом изменении системы.
Создание коммита по Conventional Commits — анализ diff, формирование message, staging, обработка hooks, push. Используй при создании коммита вместо ручного git commit.
Изменение документа проектирования SDD — обновление контента, разрешение маркеров, перевод DRAFT в WAITING, откат артефактов. Используй при изменении существующего проектирования.
Запуск разработки по analysis chain — prerequisite check, создание Issues/Milestone/Branch, переход WAITING → RUNNING. Используй при переходе Plan Dev в WAITING для запуска кодирования.
Изменение документа дискуссии SDD — обновление контента, разрешение маркеров, принятие предложений, перевод DRAFT в WAITING. Используй при изменении существующей дискуссии.
Поднятие Docker dev-окружения — docker compose up -d --build, healthcheck всех сервисов, troubleshooting. Используй перед /test и /test-ui (шаг 5.1).
Проверка черновика в .claude/drafts/ на соответствие стандарту — frontmatter, структура, именование файла. Используй после создания или изменения черновика, перед коммитом.
Процесс хотфикса — диагностика бага/инцидента, impact analysis, параллельное исправление кода и документации. Используй при багах, production-инцидентах, bundle мелких фиксов.
Инициализация проекта — GitHub Labels, Security, docs/, pre-commit, customization. Используй при настройке нового проекта или для healthcheck существующего.
Создание GitHub Issue с метками, milestone и описанием по стандарту проекта. Используй при постановке задачи, регистрации бага или запросе на улучшение.
Обновление, закрытие или переоткрытие GitHub Issue с соблюдением стандарта проекта. Используй при изменении описания, меток, milestone или статуса существующего Issue.
Проверка GitHub Issue на соответствие стандарту — заголовок, метки, milestone, описание. Используй для аудита Issue, проверки перед закрытием или валидации всех Issue в milestone.
Проверка labels.yml и меток на GitHub — синхронизация с репозиторием, валидация Issue/PR. Используй для аудита меток, после изменения labels.yml или при проверке корректности меток на Issue.
Валидация ссылок между markdown-документами — проверка frontmatter-полей, якорных ссылок и путей. Используй после рефакторинга, переименования файлов или перед коммитом.
Merge PR с pre/post проверками, sync main и cleanup. Используй при merge PR вместо ручного gh pr merge.
Проверка завершённости миграции — version drift, соответствие содержания Workflows стандарту, актуальность скриптов. Используй после /migration-create для подтверждения что все зависимости синхронизированы.
Обновление описания, закрытие или удаление GitHub Milestone. Используй при изменении срока релиза, закрытии завершённого milestone или удалении ошибочно созданного.
Создание документа плана разработки SDD — чтение Plan Tests (TC-N), Design (SVC-N), Discussion (REQ-N), Clarify, генерация TASK-N с 5 полями, подзадачи, кросс-сервисные зависимости, маппинг Issues. Используй после одобрения Plan Tests (WAITING) для определения задач реализации.
Изменение документа плана тестов SDD — обновление TC-N, разрешение маркеров, перевод DRAFT в WAITING, обработка CONFLICT. Используй при изменении существующего плана тестов.
Проверка документа плана тестов на соответствие стандарту SDD — frontmatter, именование, TC-N формат (естественные предложения, не G/W/T), покрытие REQ-N/STS-N, матрица, маркеры, зона ответственности. Используй после создания или изменения плана тестов, при code review или перед коммитом.
Создание Pull Request с автосбором Issues из chain, формированием title/body/labels, push и preview. Используй при создании PR вместо ручного gh pr create.
Создание GitHub Release — проверка chains, pre-release валидация, Release Notes, публикация, CHANGELOG. Используй при подготовке нового релиза или для hotfix.
Создание review.md с секцией Контекст ревью — читает цепочку документов, запускает extract-svc-context.py, заполняет сервисные блоки. Используй при переходе Plan Dev → WAITING, до начала разработки.
Ревью кода — локальное ревью ветки или ревью PR на GitHub. Объединяет оба этапа code review. Используй перед git push или при получении PR на ревью.
Откат analysis chain (ROLLING_BACK → REJECTED) — 5 фаз оркестрации, валидация артефактов, отчёт, подтверждение пользователя. Используй при откате цепочки из RUNNING/WAITING в REJECTED.
Создание нового rule-файла в .claude/rules/ с frontmatter и регистрацией. Используй при добавлении нового автоматического правила для Claude Code — контекстного или глобального.
Проверка rule-файла на соответствие стандарту — frontmatter, формат, пути, триггеры. Используй после создания или изменения rule, при code review или аудите правил Claude Code.
Создание нового Python-скрипта автоматизации с docstring, argparse и регистрацией в README. Используй при добавлении скрипта валидации, синхронизации или другой автоматизации проекта.
Обновление логики, рефакторинг или удаление Python-скрипта автоматизации. Используй при изменении поведения скрипта, добавлении новых проверок, исправлении ошибок или удалении устаревшего скрипта.
Создание нового specs/docs/{svc}.md — per-service документа с 10 секциями по стандарту. Используй при появлении нового сервиса или перед началом работы с сервисом без документации.
Проверка specs/docs/{svc}.md на соответствие стандарту — frontmatter, 10 секций, таблицы, подсекции API/Data Model, автономия, Changelog. Используй после создания или изменения сервисного документа, при code review или перед коммитом.
Обновление SSOT-ссылки, параметров или деактивация существующего скилла. Используй при изменении SSOT-инструкции, переименовании скилла или выводе из эксплуатации.
Проверка SKILL.md на соответствие стандарту — frontmatter, секции, SSOT-ссылка, размер. Используй после создания или изменения скилла, при code review или массовой валидации всех скиллов.
Проверка согласованности SSOT структуры проекта — README, .instructions/, дерево папок, ссылки. Используй после изменения структуры, при аудите проекта или перед релизом для проверки целостности.
Изменение per-tech стандарта кодирования — добавление сервиса, обновление конвенций, откат, деактивация. Используй при изменении существующего per-tech стандарта.
Playwright UI smoke-тесты — делегирует test-ui-agent (playwright-cli), скриншоты, отчёт PASS/FAIL. Используй после /test (шаг 5.3).
Финальная валидация — sync main, docker up, make test/lint/build/test-e2e, проверка полноты, отчёт READY/NOT READY. Используй после завершения разработки (все TASK-N done) перед ревью ветки.
Создание нового агента (AGENT.md) с промптом, конфигурацией и регистрацией в README. Используй при добавлении нового AI-агента для автоматизации задач проекта.
Отображение статусов analysis chain цепочек (одна/все/dashboard). Используй для мониторинга прогресса analysis chain или обновления dashboard в README.
Создание документа проектирования SDD с Unified Scan (5 источников), Clarify, генерацией секций SVC-N (9 подсекций, 8:8 маппинг), INT-N, STS-N, валидацией и артефактами. Используй после одобрения Discussion (WAITING) для распределения ответственностей между сервисами.
Проверка документа проектирования на соответствие стандарту SDD — frontmatter, именование, секции SVC-N (9 подсекций, 8:8 маппинг), INT-N, STS-N, delta-формат, маркеры, зона ответственности. Используй после создания или изменения проектирования, при code review или перед коммитом.
Создание документа дискуссии SDD с Clarify, генерацией разделов и валидацией. Используй при вызове пользователем "новой дискуссии", запуске нового "воркфлоу" и т.д. — в общем при разговоре с пользователем о проблеме, требованиях и критериях успеха проекта.
Проверка документа дискуссии на соответствие стандарту SDD — frontmatter, именование, секции, нумерация, маркеры, зона ответственности. Используй после создания или изменения дискуссии, при code review или перед коммитом.
Синхронизация specs/docs/ после аналитической цепочки — оркестрация service-agent, technology-agent, system-agent с ревью. Используй после Plan Dev (все 4 документа в WAITING) для создания per-service docs, per-tech стандартов и обновления overview.md.
Создание новой инструкции (standard/validation/create/modify) с frontmatter, секциями и регистрацией в README. Используй при добавлении нового процесса, стандарта или воркфлоу.
Обновление содержания, деактивация или миграция инструкции. Используй при изменении процесса, переименовании файла, обновлении standard-version или выводе инструкции из эксплуатации.
Проверка инструкции на соответствие стандарту — frontmatter, обязательные секции, ссылки, чек-лист. Используй после создания или изменения инструкции, при code review или перед коммитом.
Добавление, удаление или переименование меток GitHub с синхронизацией labels.yml. Используй при изменении набора меток проекта, добавлении новой категории или исправлении опечатки в метке.
Поиск по всей документации проекта — инструкции, скиллы, агенты, правила, README и скрипты. Используй при поиске документов по ключевым словам, для навигации по проекту или перед созданием нового объекта (проверка дубликатов).
Выполнение миграции зависимых файлов после обновления стандарта — Workflows, экземпляры, скрипты. Используй после изменения любого standard-*.md файла для синхронизации всех зависимостей.
Создание GitHub Milestone с версией, описанием и датой завершения по стандарту проекта. Используй при планировании нового релиза или группировки задач в итерацию.
Проверка GitHub Milestone на соответствие стандарту — формат версии, описание, привязка Issue. Используй для аудита milestones, проверки перед релизом или валидации всех milestones проекта.
Изменение документа плана разработки SDD — обновление TASK-N, разрешение маркеров, перевод DRAFT в WAITING, рабочие правки при RUNNING, обработка CONFLICT с синхронизацией Issues. Используй при изменении существующего плана разработки.
Проверка документа плана разработки на соответствие стандарту SDD — frontmatter, именование, TASK-N (5 полей), подзадачи, зависимости (циклы, порядок), TC трассируемость, INFRA лимит, маркеры, зона ответственности. Используй после создания или изменения плана разработки, при code review или перед коммитом.
Создание документа плана тестов SDD — чтение Design (SVC-N, INT-N, STS-N) и Discussion (REQ-N), Clarify, генерация TC-N acceptance-сценариев, тестовых данных, системных сценариев и матрицы покрытия. Используй после одобрения Design (WAITING) для определения тестовых сценариев.
Post-release валидация — проверка Release, Notes, CHANGELOG, деплой. Используй после создания GitHub Release для проверки корректности публикации.
Проверка Python-кода на соответствие принципам программирования проекта — SSOT, DRY, именование, структура. Используй при code review, после написания нового кода или рефакторинга.
Проверка документа ревью кода на соответствие стандарту — frontmatter, именование, секции Контекст ревью и Итерации, вердикт, статус OPEN/RESOLVED. Используй после создания или изменения review.md, при code review или перед коммитом.
Обновление содержания, деактивация или миграция rule-файла в .claude/rules/. Используй при изменении правил для Claude Code, переименовании rule или выводе устаревшего правила из эксплуатации.
Проверка Python-скрипта на соответствие стандарту — docstring, argparse, кодировка, регистрация в README. Используй после создания или изменения скрипта, при code review или аудите автоматизации.
Изменение specs/docs/{svc}.md — обновление секций, деактивация при удалении сервиса, миграция при переименовании. Используй при изменении API, Data Model, зависимостей или Tech Stack сервиса.
Создание нового скилла (SKILL.md) с frontmatter, SSOT-ссылкой и регистрацией в README. Используй при добавлении новой команды для Claude Code на базе существующей SSOT-инструкции.
Создание новой папки в структуре проекта с README, .instructions/ и синхронизацией SSOT. Используй при добавлении нового модуля, сервиса или раздела документации.
Переименование, перемещение или удаление папки в структуре проекта с обновлением всех ссылок и SSOT. Используй при реорганизации структуры, переименовании модуля или удалении устаревшего раздела.
Создание per-tech стандарта кодирования (полностью при Design → WAITING). Используй при добавлении новой технологии в Tech Stack — запускает N technology-agent параллельно, по одному на технологию.
Проверка per-tech стандарта на соответствие стандарту — frontmatter, секции, rule, реестр. Используй после создания или изменения per-tech стандарта, при code review или перед коммитом.