📖 English version: Command Reference
Полный справочник всех команд cc-sdd с подробным использованием, примерами и устранением неполадок.
Примечание: Этот справочник основан на шаблонах команд Claude Code. Хотя основная функциональность согласована между всеми поддерживаемыми агентами (Cursor, Gemini CLI, Codex CLI, GitHub Copilot, Qwen Code, Windsurf), синтаксис команд может немного отличаться.
/kiro:steering- Создать/обновить память проекта/kiro:steering-custom- Добавить domain-specific steering
/kiro:spec-init- Инициализировать новую спецификацию функции/kiro:spec-requirements- Сгенерировать требования/kiro:spec-design- Создать технический дизайн/kiro:spec-tasks- Разбить на задачи/kiro:spec-impl- Выполнить реализацию
/kiro:validate-gap- Анализ существующего vs требований/kiro:validate-design- Ревью качества дизайна/kiro:validate-impl- Валидация реализации
/kiro:spec-status- Проверить прогресс функции
| Команда | Параметры | Основное назначение | Следующий шаг |
|---|---|---|---|
/kiro:steering |
– | Bootstrap или синхронизация памяти проекта | /kiro:spec-init |
/kiro:steering-custom |
– (интерактив) | Захват domain-specific паттернов | /kiro:spec-init |
/kiro:spec-init |
<описание> |
Создать папку спецификации | /kiro:spec-requirements |
/kiro:spec-requirements |
<имя-функции> |
Генерация требований EARS | /kiro:spec-design |
/kiro:validate-gap |
<имя-функции> |
(Опц.) Анализ пробелов в коде | /kiro:spec-design |
/kiro:spec-design |
<имя-функции> [-y] |
Создать research.md + design.md | /kiro:spec-tasks |
/kiro:validate-design |
<имя-функции> |
(Опц.) Ревью качества дизайна | /kiro:spec-tasks |
/kiro:spec-tasks |
<имя-функции> [-y] |
Разбить на задачи с P-метками | /kiro:spec-impl |
/kiro:spec-impl |
<имя-функции> [задачи] |
Выполнить задачи с TDD | /kiro:validate-impl |
/kiro:validate-impl |
[имя-функции] [задачи] |
Проверить качество реализации | /kiro:spec-status |
/kiro:spec-status |
<имя-функции> |
Сводка прогресса | Продолжить работу |
Назначение: Создать или обновить память проекта (steering), чтобы каждая команда могла ссылаться на общие правила, архитектурные ограничения и продуктовые рекомендации.
Параметры: Нет
Использование:
/kiro:steeringЧто делает: Анализирует вашу кодовую базу и генерирует/обновляет три основных steering-документа:
{{KIRO_DIR}}/steering/structure.md- Архитектурные паттерны, организация директорий, соглашения об именовании{{KIRO_DIR}}/steering/tech.md- Технологический стек, решения по фреймворкам, технические ограничения{{KIRO_DIR}}/steering/product.md- Бизнес-контекст, назначение продукта, основные возможности
Пример вывода (Bootstrap):
✅ Steering создан
## Сгенерировано:
- product.md: Next.js SaaS платформа для командной работы
- tech.md: Next.js 14, TypeScript, Prisma, PostgreSQL
- structure.md: Feature-first организация в src/features/
Проверьте и утвердите как источник истины.
Частые проблемы:
| Проблема | Причина | Решение |
|---|---|---|
| ❌ "No codebase found" | Запуск в пустой директории | Запускайте из корня проекта с кодом |
| ❌ "Permission denied" | Недостаточно прав | Проверьте права на запись в .kiro/ |
| Маленькая/новая кодовая база | Добавьте custom steering |
Советы:
- 💡 Запускайте steering до создания спецификаций для лучших результатов
- 💡 Держите контент высокоуровневым: правила архитектуры, именования, UX-принципы
- 💡 Steering захватывает паттерны, а не списки файлов
- 💡 Перезапускайте периодически для обновления контекста ИИ
Назначение: Создать специализированные steering-документы для domain-specific паттернов (API-стандарты, тестирование, UI/UX и т.д.).
Параметры: Нет (интерактивный)
Использование:
/kiro:steering-customЧто делает:
Интерактивная команда для создания пользовательских steering-файлов в {{KIRO_DIR}}/steering/.
Доступные шаблоны:
- api-standards.md - REST/GraphQL соглашения, обработка ошибок, версионирование
- testing.md - Организация тестов, стратегии мокирования, требования покрытия
- security.md - Паттерны аутентификации, валидация ввода, управление секретами
- database.md - Проектирование схемы, миграции, паттерны запросов
- error-handling.md - Типы ошибок, логирование, стратегии повторов
- authentication.md - Auth-потоки, разрешения, управление сессиями
- deployment.md - CI/CD, окружения, процедуры отката
- ui-ux.md - Компонентные библиотеки, тон текстов, правила доступности
Когда использовать:
- ✅ У проекта есть специфические стандарты, не покрытые основным steering
- ✅ Нескольким функциям нужны согласованные domain-знания
- ✅ Вы хотите обеспечить соглашения по всему продукту
- ✅ Сложным системам нужен специализированный контекст
Назначение: Инициализировать новую спецификацию функции со структурой директорий и метаданными.
Параметры: <описание-проекта>
Использование:
/kiro:spec-init <описание-проекта>Аргументы:
<описание-проекта>(обязательно): Детальное описание функции для сборки
Что делает:
- Генерирует уникальное имя функции из описания
- Создаёт директорию спецификации:
{{KIRO_DIR}}/specs/<имя-функции>/ - Инициализирует файл метаданных:
spec.json - Создаёт начальную заглушку требований:
requirements.md
Пример:
/kiro:spec-init Аутентификация пользователей с OAuth 2.0 и JWT-токенами для Next.js приложенияВывод:
## Сгенерированное имя функции
`user-auth-oauth`
Обоснование: Захватывает основную возможность (аутентификация) и подход (OAuth).
## Сводка проекта
Система аутентификации OAuth 2.0 с управлением JWT-токенами для Next.js.
## Созданные файлы
- ✓ .kiro/specs/user-auth-oauth/spec.json
- ✓ .kiro/specs/user-auth-oauth/requirements.md
## Следующий шаг
Запустите для генерации требований:
/kiro:spec-requirements user-auth-oauth
Частые проблемы:
| Проблема | Причина | Решение |
|---|---|---|
| ❌ "Ambiguous feature name" | Размытое описание | Дайте более конкретное описание |
| ❌ "Feature already exists" | Конфликт имён | ИИ автоматически добавит номер (-2) |
| ❌ "Template missing" | Повреждённая установка | Переустановите cc-sdd |
Назначение: Сгенерировать полные, тестируемые требования в формате EARS на основе описания функции.
Параметры: <имя-функции>
Использование:
/kiro:spec-requirements <имя-функции>Что делает:
- Загружает контекст проекта из ВСЕХ steering-файлов
- Читает описание функции из начального
requirements.md - Генерирует структурированные требования с использованием формата EARS
- Обновляет
requirements.mdи отмечает фазу как завершённую вspec.json
Формат EARS (Easy Approach to Requirements Syntax):
WHEN <триггер> THE <система> SHALL <действие>
IF <условие> THEN THE <система> SHALL <действие>
WHERE <функция> THE <система> SHALL <действие>
THE <система> SHALL <действие>
Пример:
/kiro:spec-requirements user-auth-oauthКогда использовать:
- ✅ После завершения
/kiro:spec-init - ✅ Когда нужно уточнить требования перед дизайном
- ✅ Для итерации по требованиям (запускайте несколько раз)
Частые проблемы:
| Проблема | Причина | Решение |
|---|---|---|
| ❌ "Missing project description" | Пустой requirements.md | Укажите детали функции |
| ❌ "Spec not found" | Неправильное имя | Проверьте .kiro/specs/ |
| Нет steering-контекста | Сначала запустите /kiro:steering |
Назначение: Создать полный технический дизайн, переводящий требования (ЧТО) в архитектурный дизайн (КАК).
Параметры: <имя-функции> [-y]
Использование:
/kiro:spec-design <имя-функции> [-y]Аргументы:
<имя-функции>(обязательно): Имя директории функции[-y](опционально): Авто-согласование требований без подтверждения
Что делает:
- Проверяет согласование требований (или авто-согласует с
-y) - Исследует подходящую архитектуру через анализ
- Фиксирует находки в
research.md(пропускается, если исследование не нужно) - Генерирует технический дизайн с компонентами, интерфейсами, моделями данных
- Создаёт Mermaid-диаграммы для сложных архитектур
- Обновляет
design.mdи метаданные
Процесс исследования: Команда автоматически определяет глубину исследования на основе сложности функции:
- Сложные/Новые функции → Полное исследование (WebSearch для паттернов, API, библиотек)
- Расширения → Лёгкое исследование (точки интеграции, существующие паттерны)
- Простые дополнения → Минимальное исследование (быстрая проверка паттернов)
Пример:
# Стандартный поток с запросом согласования
/kiro:spec-design user-auth-oauth
# Быстрый путь с авто-согласованием
/kiro:spec-design user-auth-oauth -yАвто-согласование (флаг -y):
⚠️ Используйте осторожно - пропускает человеческую проверку требований- ✅ Хорош для: Итераций в разработке, доверенных требований
- ❌ Избегайте для: Production-функций, критических систем
Назначение: Сгенерировать детальные, исполняемые задачи реализации с параллельными волнами P0, P1 и т.д.
Параметры: <имя-функции> [-y]
Использование:
/kiro:spec-tasks <имя-функции> [-y]Что делает:
- Проверяет согласование требований и дизайна (или авто-согласует с
-y) - Сопоставляет все требования с конкретными задачами реализации
- Размеряет задачи на 1-3 часа каждая для управляемых инкрементов
- Организует задачи с логической иерархией и прогрессией
- Отмечает волны выполнения метками
P#для параллельного выполнения - Обновляет
tasks.mdи метаданные
Структура задач:
P0 — Последовательный шлюз (должен завершиться до P1)
Крупная задача (1, 2, 3...)
Подзадачи (1.1, 1.2...) по 1-3 часа, каждая с критериями приёмки
P1 — Параллельная волна (несколько крупных могут выполняться одновременно)
Крупная задача (4, 5...)
Подзадачи (4.1, 4.2...)
Пример вывода:
## Статус
✓ Задачи сгенерированы в .kiro/specs/user-auth-oauth/tasks.md
## Сводка задач
- Всего: 8 крупных задач, 24 подзадачи
- Все 15 требований покрыты
- Средний размер задачи: 1-3 часа на подзадачу
- Оценочное завершение: 48-72 часа
## Следующие шаги
Проверьте tasks.md и начните реализацию:
/kiro:spec-impl user-auth-oauth 1.1,1.2
Принципы задач:
- ✅ Естественный язык - "Создать таблицу User", а не "Определить класс UserSchema"
- ✅ Самодостаточные - Каждая задача автономна с чётким охватом
- ✅ Инкрементальные - Каждая задача интегрируется с системой
- ✅ Тестируемые - Чёткие критерии приёмки для каждой задачи
- ✅ Parallel-aware -
P0для блокирующей работы, одинаковыеP#могут выполняться параллельно
Назначение: Выполнить задачи реализации с использованием методологии TDD (Test-Driven Development).
Параметры: <имя-функции> [номера-задач]
Использование:
/kiro:spec-impl <имя-функции> [номера-задач]Аргументы:
<имя-функции>(обязательно): Имя директории функции[номера-задач](опционально): ID задач через запятую- Формат:
1.1,1.2,1.3или1,2,3 - Если опущено: Выполняет все невыполненные задачи
- Формат:
Что делает: Выполняет задачи по циклу TDD Кента Бека:
- 🔴 RED - Сначала написать падающий тест
- 🟢 GREEN - Написать минимальный код для прохождения теста
- 🔵 REFACTOR - Очистить, сохраняя тесты зелёными
- ✅ VERIFY - Убедиться в отсутствии регрессий
- 📝 MARK COMPLETE - Обновить чекбокс в tasks.md
Примеры:
# Выполнить конкретные задачи
/kiro:spec-impl user-auth-oauth 1.1,1.2,1.3
# Выполнить все невыполненные задачи
/kiro:spec-impl user-auth-oauth
# Выполнить одну задачу
/kiro:spec-impl user-auth-oauth 2.1
# Выполнить крупную задачу (все подзадачи)
/kiro:spec-impl user-auth-oauth 1Шаги валидации для каждой завершённой задачи:
- ✅ Все тесты проходят (новые + существующие)
- ✅ Нет регрессий в существующей функциональности
- ✅ Покрытие кода сохранено или улучшено
- ✅ Реализация следует спецификациям design.md
- ✅ Чекбокс обновлён в tasks.md
Советы:
- 💡 Начинайте с малого - Выполняйте 1-2 задачи за раз сначала
- 💡 TDD обязателен - Тесты пишутся до реализации
- 💡 Проверяйте регрессии - Существующие тесты должны проходить
- 💡 Используйте
/kiro:validate-implпосле завершения задач
Назначение: Анализ пробела между требованиями и существующей кодовой базой для информирования стратегии реализации (опциональная контрольная точка для brownfield-проектов).
Параметры: <имя-функции>
Использование:
/kiro:validate-gap <имя-функции>Что делает:
- Загружает требования и весь steering-контекст
- Анализирует существующую кодовую базу с помощью Grep и Read
- Выявляет недостающие возможности и проблемы интеграции
- Оценивает несколько подходов реализации
- Генерирует отчёт анализа пробелов
Когда использовать:
- ✅ Brownfield-проекты - Существующая кодовая база с новыми требованиями
- ✅ Перед фазой дизайна - Информирование технических решений
- ✅ Сложные интеграции - Сначала понять существующие паттерны
- ❌ Greenfield-проекты - Пропустите для новых кодовых баз
Структура анализа:
- Существующие возможности - Что уже реализовано
- Недостающие возможности - Что нужно построить
- Точки интеграции - Где новый код соединяется
- Несколько вариантов - Жизнеспособные подходы с компромиссами
- Потребности в исследовании - Области для углублённого изучения
Назначение: Интерактивное ревью качества технического дизайна для обеспечения готовности к реализации (опциональная контрольная точка).
Параметры: <имя-функции>
Использование:
/kiro:validate-design <имя-функции>Что делает:
- Загружает документ дизайна и весь контекст
- Проводит интерактивное ревью качества
- Выявляет максимум 3 критические проблемы
- Отмечает сильные стороны дизайна
- Даёт решение GO/NO-GO с обоснованием
Типы решений:
- 🟢 GO - Дизайн готов к реализации
- 🟡 CONDITIONAL GO - Мелкие проблемы, можно продолжить
- 🔴 NO-GO - Фундаментальные проблемы, требуется редизайн
Критерии ревью:
- ✅ Покрытие требований
- ✅ Интерфейсы и контракты компонентов
- ✅ Интеграция с существующей системой
- ✅ Соображения безопасности
- ✅ Обработка ошибок и граничные случаи
- ✅ Тестируемость
- ✅ Влияние на производительность
Назначение: Валидация реализации относительно требований, дизайна и задач для обеспечения качества и полноты.
Параметры: [имя-функции] [номера-задач]
Использование:
/kiro:validate-impl [имя-функции] [номера-задач]Аргументы:
[имя-функции](опционально): Функция для валидации- Если опущено: Определяется из истории разговора
[номера-задач](опционально): Конкретные задачи для валидации- Если опущено: Проверяет все завершённые задачи (
[x])
- Если опущено: Проверяет все завершённые задачи (
Что делает:
- Обнаруживает завершённые реализации
- Загружает требования, дизайн, задачи и steering-контекст
- Проверяет:
- ✅ Тесты существуют и проходят
- ✅ Трассируемость требований (EARS требования покрыты)
- ✅ Структура дизайна отражена в коде
- ✅ Нет регрессий существующей функциональности
- Отчитывается о результатах валидации
Примеры:
# Авто-определение из недавних команд /kiro:spec-impl
/kiro:validate-impl
# Провалидировать конкретную функцию
/kiro:validate-impl user-auth-oauth
# Провалидировать конкретные задачи
/kiro:validate-impl user-auth-oauth 1.1,1.2,1.3Когда использовать:
- ✅ После реализации - Валидировать завершённые задачи
- ✅ Перед PR/merge - Контрольная точка качества для code review
- ✅ Отладка - Выявить пробелы, когда функции не работают
- ✅ Проверка прогресса - Убедиться в полноте реализации
Назначение: Отобразить полный статус и прогресс спецификации по всем фазам.
Параметры: <имя-функции>
Использование:
/kiro:spec-status <имя-функции>Что делает:
- Загружает метаданные спецификации из
spec.json - Анализирует все файлы спецификации (requirements, design, tasks)
- Вычисляет проценты завершения
- Определяет следующие действия
- Сообщает о блокерах
Индикаторы статуса:
- ✅ Complete - Фаза завершена и согласована
- ⏳ In Progress - Фаза начата, не завершена
- ❌ Blocked - Невозможно продолжить (недостающие зависимости)
- 🔄 Needs Review - Сгенерировано, но не согласовано
Когда использовать:
- ✅ Проверить прогресс - Увидеть, где находится функция
- ✅ После перерывов - Возобновить работу после отсутствия
- ✅ Планирование - Оценить оставшиеся усилия
- ✅ Отладка - Выявить недостающие согласования или файлы
- ✅ Обновления статуса - Поделиться прогрессом с командой
Расчёт завершения:
- Requirements: Сгенерировано + Согласовано = 100%
- Design: Сгенерировано + Согласовано = 100%
- Tasks: Сгенерировано + Согласовано = 100%
- Implementation: (Завершённые задачи / Всего задач) × 100%
# 1. Настройка проекта
/kiro:steering
# 2. Инициализация функции
/kiro:spec-init Аутентификация пользователей с OAuth 2.0 и JWT
# 3. Генерация требований
/kiro:spec-requirements user-auth-oauth
# 4. Создание дизайна
/kiro:spec-design user-auth-oauth
# 5. Разбивка на задачи
/kiro:spec-tasks user-auth-oauth
# 6. Инкрементальная реализация
/kiro:spec-impl user-auth-oauth 1.1,1.2
/kiro:spec-impl user-auth-oauth 1.3,1.4
/kiro:spec-impl user-auth-oauth 2
# 7. Проверка прогресса
/kiro:spec-status user-auth-oauth
# 8. Валидация реализации
/kiro:validate-impl user-auth-oauth# 1. Установка контекста проекта
/kiro:steering
/kiro:steering-custom # Добавить domain-specific паттерны
# 2. Инициализация расширения
/kiro:spec-init Добавить OAuth в существующую систему auth
# 3. Генерация требований
/kiro:spec-requirements oauth-enhancement
# 4. Анализ пробелов интеграции
/kiro:validate-gap oauth-enhancement
# 5. Создание дизайна (с учётом анализа пробелов)
/kiro:spec-design oauth-enhancement
# 6. Валидация дизайна относительно существующей системы
/kiro:validate-design oauth-enhancement
# 7. Разбивка на задачи
/kiro:spec-tasks oauth-enhancement
# 8. Реализация и валидация
/kiro:spec-impl oauth-enhancement 1.1,1.2
/kiro:validate-impl oauth-enhancement# 1. Быстрая настройка
/kiro:steering
# 2. Инициализация с описанием
/kiro:spec-init Добавить страницу профиля пользователя с загрузкой аватара
# 3. Авто-согласование через дизайн
/kiro:spec-requirements user-profile
/kiro:spec-design user-profile -y
/kiro:spec-tasks user-profile -y
# 4. Реализовать всё сразу
/kiro:spec-impl user-profile
# 5. Финальная валидация
/kiro:validate-impl user-profile