Справочник по CLI

OpenSpec CLI (openspec) предоставляет терминальные команды для настройки проекта, проверки, просмотра статуса и управления. Эти команды дополняют слэш-команды ИИ (например, /opsx:propose), описанные в разделе Команды.

Сводка

Категория	Команды	Назначение
Настройка	`init`, `update`	Инициализация и обновление OpenSpec в вашем проекте
Хранилища (автономные репозитории OpenSpec)	`store setup`, `store register`, `store unregister`, `store remove`, `store list`, `store doctor`	Управление хранилищами — автономными репозиториями OpenSpec, которые вы зарегистрировали
Состояние	`doctor`	Отчёт о состоянии связей для разрешённого корня
Рабочий контекст	`context`	Сборка рабочего набора (корень + хранилища, на которые есть ссылки)
Персональные рабочие наборы	`workset create`, `workset list`, `workset open`, `workset remove`	Сохранение и открытие персональных локальных рабочих представлений в вашем инструменте
Просмотр	`list`, `view`, `show`	Изучение изменений и спецификаций
Проверка	`validate`	Проверка изменений и спецификаций на наличие проблем
Жизненный цикл	`archive`	Завершение выполненных изменений
Рабочий процесс	`new change`, `status`, `instructions`, `templates`, `schemas`	Поддержка рабочего процесса, управляемого артефактами
Схемы	`schema init`, `schema fork`, `schema validate`, `schema which`	Создание и управление пользовательскими рабочими процессами
Конфигурация	`config`	Просмотр и изменение настроек
Утилиты	`feedback`, `completion`	Отправка обратной связи и интеграция с оболочкой

Команды для человека и для агентов

Большинство CLI-команд предназначены для использования человеком в терминале. Некоторые команды также поддерживают использование агентами/скриптами через вывод в формате JSON.

Команды только для человека

Эти команды являются интерактивными и предназначены для использования в терминале:

Command	Purpose
`openspec init`	Инициализировать проект (интерактивные запросы)
`openspec view`	Интерактивная панель управления
`openspec workset open <name>`	Открыть сохраненный рабочий набор (окно редактора или сессия агента в терминале)
`openspec config edit`	Открыть конфигурацию в редакторе
`openspec feedback`	Отправить обратную связь через GitHub
`openspec completion install`	Установить автодополнение для оболочки

Команды, совместимые с агентами

Эти команды поддерживают вывод --json для программного использования ИИ-агентами и скриптами:

Command	Human Use	Agent Use
`openspec list`	Просматривать изменения/спецификации	`--json` для структурированных данных
`openspec show <item>`	Читать содержимое	`--json` для парсинга
`openspec validate`	Проверять на наличие проблем	`--all --json` для массовой проверки
`openspec status`	Просматривать прогресс артефактов	`--json` для структурированного статуса
`openspec instructions`	Получать следующие шаги	`--json` для инструкций для агента
`openspec templates`	Искать пути к шаблонам	`--json` для разрешения путей
`openspec schemas`	Перечислить доступные схемы	`--json` для обнаружения схем
`openspec store setup <id>`	Создать и зарегистрировать локальное хранилище	`--json` с явными входными данными для структурированного вывода результата настройки
`openspec store register <path>`	Зарегистрировать существующее хранилище	`--json` для структурированного вывода результата регистрации
`openspec store unregister <id>`	Забыть регистрацию локального хранилища	`--json` для структурированного вывода результата очистки
`openspec store remove <id>`	Удалить папку зарегистрированного локального хранилища	`--yes --json` для неинтерактивного удаления
`openspec store list`	Просматривать зарегистрированные хранилища	`--json` для структурированных данных о регистрациях
`openspec store doctor`	Проверять конфигурацию локального хранилища	`--json` для структурированной диагностики
`openspec new change <id>`	Создать каркас изменения в репозитории	`--json`, а также `--store <id>` для использования зарегистрированного хранилища в качестве корня OpenSpec
`openspec workset create [name]`	Создать персональный рабочий вид	`--member <path> --json` для неинтерактивного создания
`openspec workset list`	Просматривать сохраненные рабочие наборы	`--json` для структурированных представлений
`openspec workset remove <name>`	Удалить сохраненный вид	`--yes --json` для неинтерактивного удаления

Глобальные параметры

Эти параметры работают со всеми командами:

Option	Description
`--version`, `-V`	Показать номер версии
`--no-color`	Отключить цветной вывод
`--help`, `-h`	Показать справку по команде

Команды настройки

`openspec init`

Инициализирует OpenSpec в вашем проекте. Создает структуру папок и настраивает интеграции с ИИ-инструментами.

Поведение по умолчанию использует глобальные параметры конфигурации: профиль core, доставка both, рабочие процессы propose, explore, apply, sync, archive.

openspec init [path] [options]

Аргументы:

Argument	Required	Description
`path`	Нет	Целевая директория (по умолчанию: текущая директория)

Параметры:

Option	Description
`--tools <list>`	Настроить ИИ-инструменты в неинтерактивном режиме. Используйте `all`, `none` или список, разделенный запятыми
`--force`	Автоматически очистить устаревшие файлы без запроса подтверждения
`--profile <profile>`	Переопределить глобальный профиль для этого запуска инициализации (`core` или `custom`)

При использовании --profile custom применяются рабочие процессы, выбранные в текущий момент в глобальной конфигурации (openspec config profile).

Поддерживаемые идентификаторы инструментов (--tools): amazon-q, antigravity, auggie, bob, claude, cline, codeartsagent, codex, forgecode, codebuddy, continue, costrict, crush, cursor, factory, gemini, github-copilot, hermes, iflow, junie, kilocode, kimi, kiro, lingma, vibe, oh-my-pi, opencode, pi, qoder, qwen, roocode, trae, windsurf, zcode

Этот список повторяет значение AI_TOOLS в файле src/core/config.ts. Сведения о возможностях и путях команд для каждого инструмента см. в разделе Поддерживаемые инструменты.

Примеры:

bash

# Интерактивная инициализация
openspec init

# Инициализировать в указанной директории
openspec init ./my-project

# Неинтерактивный режим: настроить для Claude и Cursor
openspec init --tools claude,cursor

# Настроить для всех поддерживаемых инструментов
openspec init --tools all

# Переопределить профиль для этого запуска
openspec init --profile core

# Пропустить запросы и автоматически очистить устаревшие файлы
openspec init --force

Что создается:

openspec/
├── specs/              # Ваши спецификации (источник истины)
├── changes/            # Предлагаемые изменения
└── config.yaml         # Конфигурация проекта

.claude/skills/         # Навыки Claude Code (если выбран claude)
.cursor/skills/         # Навыки Cursor (если выбран cursor)
.cursor/commands/       # Команды Cursor OPSX (если доставка включает команды)
... (конфигурации других инструментов)

`openspec update`

Обновите файлы инструкций OpenSpec после обновления CLI. Перегенерируйте конфигурационные файлы ИИ-инструментов, используя текущий глобальный профиль, выбранные рабочие процессы и режим доставки.

openspec update [path] [options]

Аргументы:

Argument	Required	Description
`path`	Нет	Целевая директория (по умолчанию: текущая директория)

Параметры:

Option	Description
`--force`	Принудительно обновить, даже если файлы уже актуальны

Пример:

bash

# Обновить файлы инструкций после обновления через npm
npm update @fission-ai/openspec
openspec update

Хранилища (автономные репозитории OpenSpec)

Бета-версия. Хранилища и построенные на них функции (ссылки, рабочий контекст, рабочие наборы) являются новыми; названия команд, флаги, форматы файлов и вывод JSON могут изменяться между релизами. Для ознакомления с функционалом, ориентированным на решение задач, см. руководство по хранилищам.

Хранилище — это автономный репозиторий OpenSpec, который вы зарегистрировали на этом устройстве, например репозиторий с планами или репозиторий с контрактами. Регистрация хранилища позволяет обычным командам (list, show, status, validate, new change, archive и т. д.) работать с ним из любого места путем передачи параметра --store <id>.

`openspec store setup`

Создать и зарегистрировать локальное хранилище. Если в терминале не переданы аргументы, OpenSpec проведет пользователя через процесс настройки. Агенты и скрипты должны передавать явные входные данные и использовать параметр --json.

bash

openspec store setup [id] [options]

Параметры:

Option	Description
`--path <path>`	Папка, в которой должно располагаться хранилище (например `~/openspec/<id>`)
`--remote <url>`	Записать канонический удаленный репозиторий в файл `store.yaml` нового хранилища
`--init-git`	Инициализировать репозиторий Git с начальным коммитом (по умолчанию)
`--no-init-git`	Пропустить все действия с Git: без инициализации, без начального коммита
`--json`	Выводить данные в формате JSON

При неинтерактивном запуске (с параметром --json, в скриптах, для агентов) необходимо передавать как идентификатор хранилища, так и параметр --path. В интерактивном терминале процесс настройки запрашивает расположение с редактируемым предложением в видимом месте, доступном пользователю (например ~/openspec/<id>); по умолчанию он никогда не использует управляемую директорию данных OpenSpec.

Примеры:

bash

openspec store setup
openspec store setup team-context
openspec store setup team-context --path ~/openspec/team-context --no-init-git
openspec store setup team-context --path ~/openspec/team-context --no-init-git --json

`openspec store register`

Зарегистрировать существующую папку локального хранилища. Во время бета-тестирования хранилищ корень может быть зарегистрирован до того, как появятся какие-либо изменения, будут применены спецификации или изменения будут заархивированы; в этом случае папки openspec/changes/, openspec/specs/ и openspec/changes/archive/ могут отсутствовать, пока обычные команды не создадут их. Репозиторий, содержащий только конфигурацию и объявляющий store: <id>, остается указателем на другое хранилище и не регистрируется как корень хранилища, пока этот указатель не будет удален.

bash

openspec store register [path] [options]

Параметры:

Option	Description
`--id <id>`	Идентификатор хранилища; по умолчанию используется метаданные хранилища или название папки
`--yes`	Подтвердить создание метаданных идентичности хранилища для работоспособного корня OpenSpec
`--json`	Выводить данные в формате JSON

`openspec store unregister`

Забыть регистрацию локального хранилища без удаления файлов.

bash

openspec store unregister <id> [--json]

Используйте эту команду, если хранилище было перемещено, клонировано в другое место или больше не должно отображаться OpenSpec на этом устройстве.

`openspec store remove`

Забыть регистрацию локального хранилища и удалить его локальную папку.

bash

openspec store remove <id> [--yes] [--json]

Команда remove показывает точный путь к папке перед удалением в интерактивном терминале. Агенты, скрипты и вызывающие стороны, использующие JSON, должны передавать параметр --yes для подтверждения удаления. OpenSpec отказывается удалять папку, в которой отсутствуют соответствующие метаданные хранилища.

`openspec store list`

Перечислить локально зарегистрированные хранилища.

bash

openspec store list [--json]
openspec store ls [--json]

`openspec store doctor`

Проверить регистрацию локального хранилища, его метаданные и наличие репозитория Git.

bash

openspec store doctor [id] [--json]

Команда doctor предназначена только для диагностики; она сообщает об отсутствующих корнях, несоответствиях метаданных и недействительном состоянии локального реестра без внесения изменений в хранилище.

Ссылки на хранилища из проекта

Репозиторий проекта может объявить, на каких хранилищах основана его работа, в файле openspec/config.yaml:

yaml

schema: spec-driven
references:
  - team-context

С этого момента вывод команды openspec instructions в этом репозитории (как для отдельных артефактов, так и для поверхности apply, в форматах JSON и для человека) содержит индекс спецификаций каждого referenced хранилища — идентификаторы спецификаций, однострочное резюме из раздела Purpose каждой спецификации и команду для получения (openspec show <spec-id> --type spec --store <id>). Индекс строится в реальном времени из зарегистрированной рабочей копии при каждом запуске; содержимое спецификаций никогда не копируется в вывод.

Ссылки являются контекстом только для чтения. Они никогда не меняют место выполнения команд: работа остается в собственном корне репозитория, а запись в referenced хранилище остается явным действием с параметром --store. Ссылка, которую невозможно разрешить (например, хранилище, не зарегистрированное на этом устройстве), преобразуется в предупреждение в индексе с точным способом исправления, а инструкции все равно генерируются. Команда openspec doctor сообщает о состоянии ссылок в одном месте.

Запись источника клонирования хранилища

Хранилище может записать свой канонический источник клонирования в зафиксированный файл идентичности, поэтому при онбординге никогда не возникает тупиковая ситуация с требованием «зарегистрируйте хранилище»:

bash

openspec store setup team-context --path ~/openspec/team-context \
  --remote git@github.com:acme/team-context.git

Удаленный репозиторий записывается в файл .openspec-store/store.yaml внутри начального коммита, поэтому каждый клон изначально знает о нем. Для существующего хранилища отредактируйте файл store.yaml вручную и зафиксируйте изменения коммитом. Команда store doctor показывает записанный удаленный репозиторий (а также наблюдаемый исходный репозиторий Git рабочей копии); руководство по совместному использованию при настройке/регистрации называет его, а команда register записывает исходный репозиторий рабочей копии в реестр, локальный для устройства.

Объявление ссылки также может содержать источник клонирования, поэтому коллега, у которого еще нет хранилища, получает полное готовое к использованию решение для исправления (git clone <remote> <path> && openspec store register <path> --id <id>):

yaml

references:
  - { id: team-context, remote: "git@github.com:acme/team-context.git" }

Запись удаленного репозитория не является синхронизацией: OpenSpec никогда не клонирует, не получает изменения и не отправляет их самостоятельно.

Объявление хранилища по умолчанию

Репозиторий, чье планирование полностью вынесено во внешнее хранилище (без локальных папок openspec/specs/ или openspec/changes/) может объявить свое хранилище один раз вместо передачи параметра --store в каждой команде:

yaml

# openspec/config.yaml (единственный файл в папке openspec/)
store: team-context

После этого обычные команды автоматически используют объявленное хранилище; баннер корня и блок JSON root сообщают source: "declared" с идентификатором хранилища, а выводимые подсказки все еще содержат --store <id>. Объявление является запасным вариантом, а не переопределением: явный параметр --store всегда имеет приоритет, а директория с реальными папками для планирования игнорирует этот указатель (с выводом предупреждения). Чтобы преобразовать репозиторий с указателем в локальный корень OpenSpec, удалите строку store: и запустите команду openspec init — инициализация отказывается создавать каркас, пока объявление присутствует.

Вариант на уровне устройства покрывает все репозитории сразу: openspec config set defaultStore <id> (см. раздел «Конфигурация»). Он используется только в том случае, если не удалось разрешить ни параметр --store, ни локальный корень, ни указатель проекта; в этом случае баннер корня и блок JSON root сообщают source: "global_default".

Doctor (состояние связей)

Один вопрос в режиме только для чтения, одно место для проверки: корень OpenSpec исправен, а хранилища, на которые он ссылается, доступны на этой машине?

bash

openspec doctor [--store <id>] [--json]

Отчёт разделяет оценку состояния корня, оценку состояния метаданных хранилищ (в том числе примечание о расхождении записанного удалённого репозитория и источника рабочей копии, а также примечание, если рабочая копия хранилища отстала от последнего полученного upstream-трекингового указателя), и оценку состояния ссылок (в выводе отображаются те же инструкции диагностики с вариантами исправления через клонирование для неразрешённых ссылок). Результаты проверки состояния любой степени серьёзности завершают команду с кодом выхода 0 — агенты считывают массивы status; код выхода 1 возвращается только при сбоях выполнения команды (отсутствие корня, неизвестное хранилище). Doctor никогда не клонирует, не синхронизирует и не восстанавливает данные. Чтобы получить собранный набор сам по себе, а не его оценку состояния, используйте openspec context.

Рабочий контекст (собранный набор)

Всё, с чем связана эта работа через декларации OpenSpec, объединено в один рабочий набор: корень OpenSpec и хранилища, на которые он ссылается.

bash

openspec context [--store <id>] [--json] [--code-workspace <path> [--force]]

Краткий вывод в формате JSON пригоден для обработки агентами (каждое доступное хранилище, на которое есть ссылка, содержит рецепт его получения; для неразрешённых членов набора выводятся те же инструкции исправления, что и в выводе doctor). Параметр --code-workspace дополнительно создаёт файл рабочей области VS Code, содержащий корень и все доступные хранилища, на которые есть ссылки (папки ref:<id>) — это единственная операция записи, которую выполняет эта команда, и она отклоняется без параметра --force, если файл уже существует. Недоступные члены набора выводятся в отчёте, их наличие никогда не предполагается.

"Рабочий контекст" — это собранный набор; поле context: в openspec/config.yaml содержит фоновую информацию о проекте, внедряемую в инструкции — это два разных понятия. openspec doctor отвечает на вопрос, исправен ли набор; openspec context отвечает на вопрос, что из себя представляет этот набор.

Личные рабочие наборы

Бета-версия. Рабочие наборы являются частью нового бета-интерфейса; команды, флаги и форматы файлов могут изменяться между релизами. Для пошагового руководства см. руководство по хранилищам.

Рабочий набор — это персональное именованное представление папок, с которыми вы работаете вместе: корня планирования плюс любые другие папки по вашему выбору. Он хранится на вашем устройстве и повторно открывается по имени в вашем инструменте. Он полностью локальный: его никогда не коммитят, не делятся им, он не создается на основе объявлений, а удаление рабочего набора никогда не затрагивает папки-участники.

bash

openspec workset create [name] [--member <path> | --member <name>=<path>]... [--tool <id>] [--json]
openspec workset list [--json]
openspec workset open <name> [--tool <id>]
openspec workset remove <name> [--yes] [--json]

create запускает короткий пошаговый процесс (или принимает флаги --member в неинтерактивном режиме; первый участник является основным — сессии начинаются в нем). open запускает выбранный инструмент: редакторы (VS Code, Cursor) открывают окно со всеми участниками и возвращают управление; CLI-агенты (Claude Code, codex) захватывают этот терминал как сессию со всеми подключенными участниками, без предварительно заполненного запроса, и завершают работу при вашем выходе. Если при открытии папка-участник отсутствует, она пропускается с соответствующим примечанием, остальные открываются. Сохраненное предпочтение инструмента можно переопределять при каждом открытии с помощью флага --tool.

Поддержка нового инструмента — это конфигурация, а не написание кода. Каждый инструмент относится к одному из двух стилей запуска: workspace-file (запускается с помощью сгенерированного файла .code-workspace) или attach-dirs (один флаг подключения на каждого участника). Ключ openers в глобальном config.json (откройте его командой openspec config edit) позволяет добавлять инструменты или корректировать встроенные для каждого поля:

json

{
  "openers": {
    "zed": { "style": "workspace-file" },
    "claude": { "attach_flag": "--dir" }
  }
}

Все состояние рабочих наборов хранится в папке worksets/ в глобальной директории с данными (сохраненные представления плюс сгенерированные файлы <name>.code-workspace, которые пересоздаются при каждом открытии); удаление этой папки удаляет все следы.

Команды просмотра

`openspec list`

Выводит список изменений или спецификаций в вашем проекте.

openspec list [options]

Опции:

Опция	Описание
`--specs`	Выводить список спецификаций вместо изменений
`--changes`	Выводить список изменений (по умолчанию)
`--sort <order>`	Сортировать по `recent` (по умолчанию) или `name`
`--json`	Выводить результат в формате JSON

Примеры:

bash

# Вывести список всех активных изменений
openspec list

# Вывести список всех спецификаций
openspec list --specs

# Вывод в формате JSON для скриптов
openspec list --json

Вывод (текст):

Изменения:
  add-dark-mode     Нет задач      только что

`openspec view`

Отображает интерактивную панель для просмотра спецификаций и изменений.

openspec view

Открывает терминальный интерфейс для навигации по спецификациям и изменениям вашего проекта.

`openspec show`

Отображает сведения об изменении или спецификации.

openspec show [item-name] [options]

Аргументы:

Аргумент	Обязательный	Описание
`item-name`	Нет	Название изменения или спецификации (запрос ввода при пропуске)

Опции:

Опция	Описание
`--type <type>`	Указать тип: `change` или `spec` (определяется автоматически, если нет неоднозначности)
`--json`	Выводить результат в формате JSON
`--no-interactive`	Отключить запросы ввода

Опции для изменений:

Опция	Описание
`--deltas-only`	Показать только дельта-спецификации (режим JSON)

Опции для спецификаций:

Опция	Описание
`--requirements`	Показать только требования, исключить сценарии (режим JSON)
`--no-scenarios`	Исключить содержимое сценариев (режим JSON)
`-r, --requirement <id>`	Показать конкретное требование по 1-based индексу (режим JSON)

Примеры:

bash

# Интерактивный выбор
openspec show

# Показать конкретное изменение
openspec show add-dark-mode

# Показать конкретную спецификацию
openspec show auth --type spec

# Вывод в формате JSON для парсинга
openspec show add-dark-mode --json

Команды валидации

`openspec validate`

Проверяет изменения и спецификации на наличие структурных ошибок.

openspec validate [item-name] [options]

Изменение с нулевым количеством дельта-спецификаций не проходит валидацию, если в его файле .openspec.yaml не указано skip_specs: true (для чистой рефакторизации, работы с инструментами или документации см. Рецепт 5).

Аргументы:

Аргумент	Обязательный	Описание
`item-name`	Нет	Конкретный элемент для валидации (запрос ввода при пропуске)

Опции:

Опция	Описание
`--all`	Проверить все изменения и спецификации
`--changes`	Проверить все изменения
`--specs`	Проверить все спецификации
`--type <type>`	Указать тип, если название неоднозначно: `change` или `spec`
`--strict`	Включить строгий режим валидации
`--json`	Выводить результат в формате JSON
`--concurrency <n>`	Максимальное количество параллельных проверок (по умолчанию: 6, или значение переменной окружения `OPENSPEC_CONCURRENCY`)
`--no-interactive`	Отключить запросы ввода

Примеры:

bash

# Интерактивная валидация
openspec validate

# Проверить конкретное изменение
openspec validate add-dark-mode

# Проверить все изменения
openspec validate --changes

# Проверить все с выводом в формате JSON (для CI/скриптов)
openspec validate --all --json

# Строгая валидация с повышенным параллелизмом
openspec validate --all --strict --concurrency 12

Вывод (текст):

Проверка add-dark-mode...
  ✓ proposal.md валиден
  ✓ specs/ui/spec.md валиден
  ⚠ design.md: отсутствует раздел «Технический подход»

Найдено 1 предупреждение

Вывод (JSON):

json

{
  "version": "1.0.0",
  "results": {
    "changes": [
      {
        "name": "add-dark-mode",
        "valid": true,
        "warnings": ["design.md: missing 'Technical Approach' section"]
      }
    ]
  },
  "summary": {
    "total": 1,
    "valid": 1,
    "invalid": 0
  }
}

Команды жизненного цикла

`openspec archive`

Архивирует завершенное изменение и объединяет дельта-спецификации с основными спецификациями.

openspec archive [change-name] [options]

Аргументы:

Аргумент	Обязательный	Описание
`change-name`	Нет	Изменение для архивации (запрос ввода при пропуске)

Опции:

Опция	Описание
`-y, --yes`	Пропустить запросы подтверждения
`--skip-specs`	Пропустить обновление спецификаций для одного запуска архивации. Если изменение постоянно не имеет дельта-спецификаций, следует указать `skip_specs: true` в его `.openspec.yaml` — в этом случае оно архивируется без флага
`--no-validate`	Пропустить валидацию (требуется подтверждение)

Примеры:

bash

# Интерактивная архивация
openspec archive

# Архивировать конкретное изменение
openspec archive add-dark-mode

# Архивировать без запросов (для CI/скриптов)
openspec archive add-dark-mode --yes

# Архивировать изменение, связанное с инструментами, которое не затрагивает спецификации
openspec archive update-ci-config --skip-specs

Что делает команда:

Проверяет изменение на валидность (если не указан флаг --no-validate)
Запрашивает подтверждение (если не указан флаг --yes)
Объединяет дельта-спецификации с папкой openspec/specs/
Перемещает папку изменения в openspec/changes/archive/YYYY-MM-DD-<name>/

Команды рабочего процесса

Эти команды поддерживают рабочий процесс OPSX, ориентированный на артефакты. Они полезны как для людей, отслеживающих прогресс, так и для агентов, определяющих следующие шаги.

`openspec new change`

Создает директорию изменения и опциональные метаданные, фиксируемые в определенном корне проекта OpenSpec.

bash

openspec new change <name> [options]

Названия изменений должны использовать нижний регистр с дефисами в качестве разделителей (kebab-case). Они начинаются со строчной буквы, затем могут содержать строчные буквы, цифры и одиночные дефисы. Нельзя начинать название с цифры, использовать пробелы, знаки подчеркивания, заглавные буквы, последовательные дефисы или дефисы в начале/конце названия. При включении идентификатора внешнего тикета добавляйте к нему префикс в виде слова, например ticket-123-add-notifications вместо 123-add-notifications.

Опции:

Опция	Описание
`--description <text>`	Описание для добавления в `index.md`
`--goal <text>`	Опциональная целевая метаданная для сохранения вместе с изменением
`--schema <name>`	Схема рабочего процесса для использования
`--store <id>`	Идентификатор хранилища для использования в качестве корня проекта OpenSpec (хранилище — это отдельный репозиторий OpenSpec, который вы зарегистрировали)
`--json`	Выводить результат в формате JSON

Примеры:

bash

openspec new change add-billing-api
openspec new change add-billing-api --store team-context --json

`openspec status`

Отображает статус завершения артефактов для изменения.

openspec status [options]

Опции:

Опция	Описание
`--change <id>`	Название изменения (запрос ввода при пропуске)
`--schema <name>`	Переопределение схемы (определяется автоматически из конфигурации изменения)
`--json`	Выводить результат в формате JSON

Примеры:

bash

# Интерактивная проверка статуса
openspec status

# Статус конкретного изменения
openspec status --change add-dark-mode

# Вывод в формате JSON для использования агентами
openspec status --change add-dark-mode --json

Вывод (текст):

Изменение: add-dark-mode
Схема: spec-driven
Прогресс: 2/4 артефактов завершено

[x] proposal
[ ] design
[x] specs
[-] tasks (заблокировано: design)

Изменение, в котором указано skip_specs: true, отображает этап specs как [~] specs (skipped: change declares skip_specs) и исключает его из подсчета прогресса.

Вывод (JSON):

json

{
  "changeName": "add-dark-mode",
  "schemaName": "spec-driven",
  "isComplete": false,
  "applyRequires": ["tasks"],
  "artifacts": [
    {"id": "proposal", "outputPath": "proposal.md", "status": "done", "requires": []},
    {"id": "design", "outputPath": "design.md", "status": "ready", "requires": ["proposal"]},
    {"id": "specs", "outputPath": "specs/**/*.md", "status": "done", "requires": ["proposal"]},
    {"id": "tasks", "outputPath": "tasks.md", "status": "blocked", "requires": ["specs", "design"], "missingDeps": ["design"]}
  ]
}

`openspec instructions`

Получает расширенные инструкции для создания артефакта или выполнения задач. Используется ИИ-агентами для понимания, что нужно создать следующим.

openspec instructions [artifact] [options]

Аргументы:

Аргумент	Обязательный	Описание
`artifact`	Нет	Идентификатор артефакта: `proposal`, `specs`, `design`, `tasks` или `apply`

Опции:

Опция	Описание
`--change <id>`	Название изменения (обязательно в неинтерактивном режиме)
`--schema <name>`	Переопределение схемы
`--json`	Выводить результат в формате JSON

Особый случай: Используйте apply в качестве артефакта, чтобы получить инструкции по реализации задач.

Примеры:

bash

# Получить инструкции для следующего артефакта
openspec instructions --change add-dark-mode

# Получить инструкции для конкретного артефакта
openspec instructions design --change add-dark-mode

# Получить инструкции по применению/реализации
openspec instructions apply --change add-dark-mode

# Вывод в формате JSON для обработки агентами
openspec instructions design --change add-dark-mode --json

В выводе содержится:

Шаблон содержимого артефакта
Контекст проекта из конфигурации
Содержимое зависимых артефактов
Правила для каждого артефакта из конфигурации

Для артефакта, пропущенного с помощью параметра skip_specs: true, в выводе содержится только предупреждение (в режиме JSON добавляются поля skipped/warning) — такой артефакт не должен создаваться.

`openspec templates`

Отображает разрешенные пути к шаблонам для всех артефактов в схеме.

openspec templates [options]

Опции:

Опция	Описание
`--schema <name>`	Схема для проверки (по умолчанию: `spec-driven`)
`--json`	Выводить результат в формате JSON

Примеры:

bash

# Показать пути к шаблонам для схемы по умолчанию
openspec templates

# Показать шаблоны для пользовательской схемы
openspec templates --schema my-workflow

# Вывод в формате JSON для программного использования
openspec templates --json

Вывод (текст):

Схема: spec-driven

Шаблоны:
  proposal  → ~/.openspec/schemas/spec-driven/templates/proposal.md
  specs     → ~/.openspec/schemas/spec-driven/templates/specs.md
  design    → ~/.openspec/schemas/spec-driven/templates/design.md
  tasks     → ~/.openspec/schemas/spec-driven/templates/tasks.md

`openspec schemas`

Выводит список доступных схем рабочих процессов с их описаниями и потоками артефактов.

openspec schemas [options]

Опции:

Опция	Описание
`--json`	Выводить результат в формате JSON

Пример:

bash

openspec schemas

Вывод:

Доступные схемы:

  spec-driven (пакет)
    Стандартный рабочий процесс разработки, ориентированный на спецификации
    Поток: proposal → specs → design → tasks

  my-custom (проект)
    Пользовательский рабочий процесс для этого проекта
    Поток: research → proposal → tasks

Команды для работы со схемами

Команды для создания и управления пользовательскими схемами рабочих процессов.

`openspec schema init`

Создать новую схему, локальную для проекта.

openspec schema init <имя> [опции]

Аргументы:

Аргумент	Обязательность	Описание
`name`	Да	Имя схемы (в формате kebab-case)

Опции:

Опция	Описание
`--description <текст>`	Описание схемы
`--artifacts <список>`	Список идентификаторов артефактов, разделенных запятыми (по умолчанию: `proposal,specs,design,tasks`)
`--default`	Установить как схему проекта по умолчанию
`--no-default`	Не запрашивать подтверждение на установку по умолчанию
`--force`	Перезаписать существующую схему
`--json`	Вывести результат в формате JSON

Примеры:

bash

# Интерактивное создание схемы
openspec schema init research-first

# Неинтерактивное создание с указанием конкретных артефактов
openspec schema init rapid \
  --description "Rapid iteration workflow" \
  --artifacts "proposal,tasks" \
  --default

Что создается:

openspec/schemas/<имя>/
├── schema.yaml           # Определение схемы
└── templates/
    ├── proposal.md       # Шаблон для каждого артефакта
    ├── specs.md
    ├── design.md
    └── tasks.md

`openspec schema fork`

Скопировать существующую схему в ваш проект для доработки.

openspec schema fork <источник> [имя] [опции]

Аргументы:

Аргумент	Обязательность	Описание
`source`	Да	Исходная схема для копирования
`name`	Нет	Имя новой схемы (по умолчанию: `<source>-custom`)

Опции:

Опция	Описание
`--force`	Перезаписать существующую схему в месте назначения
`--json`	Вывести результат в формате JSON

Пример:

bash

# Форк встроенной схемы spec-driven
openspec schema fork spec-driven my-workflow

`openspec schema validate`

Проверить структуру и шаблоны схемы на корректность.

openspec schema validate [имя] [опции]

Аргументы:

Аргумент	Обязательность	Описание
`name`	Нет	Имя схемы для проверки (если не указано, проверяются все схемы)

Опции:

Опция	Описание
`--verbose`	Показать подробные шаги проверки
`--json`	Вывести результат в формате JSON

Примеры:

bash

# Проверить конкретную схему
openspec schema validate my-workflow

# Проверить все схемы
openspec schema validate

`openspec schema which`

Показать источник, из которого загружается указанная схема (удобно для отладки порядка приоритета загрузки).

openspec schema which [имя] [опции]

Аргументы:

Аргумент	Обязательность	Описание
`name`	Нет	Имя схемы

Опции:

Опция	Описание
`--all`	Показать все схемы с указанием их источников
`--json`	Вывести результат в формате JSON

Пример:

bash

# Проверить источник загрузки схемы
openspec schema which spec-driven

Вывод:

spec-driven resolves from: package
  Source: /usr/local/lib/node_modules/@fission-ai/openspec/schemas/spec-driven

Приоритет загрузки схем:

Проект: openspec/schemas/<имя>/
Пользователь: ~/.local/share/openspec/schemas/<имя>/
Пакет: Встроенные схемы

Команды для работы с конфигурацией

`openspec config`

Просмотр и изменение глобальной конфигурации OpenSpec.

openspec config <подкоманда> [опции]

Подкоманды:

Подкоманда	Описание
`path`	Показать путь к файлу конфигурации
`list`	Показать все текущие параметры
`get <ключ>`	Получить значение конкретного параметра
`set <ключ> <значение>`	Установить значение параметра
`unset <ключ>`	Удалить параметр
`reset`	Сбросить до значений по умолчанию
`edit`	Открыть в редакторе, указанном в переменной `$EDITOR`
`profile [пресет]`	Настроить профиль рабочих процессов в интерактивном режиме или с использованием пресета

Примеры:

bash

# Показать путь к файлу конфигурации
openspec config path

# Показать все параметры
openspec config list

# Получить значение конкретного параметра
openspec config get telemetry.enabled

# Установить значение параметра
openspec config set telemetry.enabled false

# Явно установить строковое значение
openspec config set user.name "My Name" --string

# Удалить пользовательский параметр
openspec config unset user.name

# Установить хранилище по умолчанию для всего устройства (используется как запасной корень, если не указаны параметры --store, локальный корень или хранилище проекта: разрешается указатель)
openspec config set defaultStore team-plans

# Сбросить всю конфигурацию
openspec config reset --all --yes

# Открыть конфигурацию в вашем редакторе
openspec config edit

# Настроить профиль с помощью мастера на основе действий
openspec config profile

# Быстрый пресет: переключить рабочие процессы на базовый (сохраняет режим доставки)
openspec config profile core

Команда openspec config profile начинается с отображения сводки текущего состояния, после чего предлагает выбрать одно из действий:

Изменить режим доставки и рабочие процессы
Изменить только режим доставки
Изменить только рабочие процессы
Сохранить текущие параметры (выход)

Если вы выберете сохранение текущих параметров, никакие изменения не будут записаны, и запрос на обновление не будет показан. Если в конфигурации не было внесено изменений, но файлы текущего проекта не синхронизированы с вашим глобальным профилем/режимом доставки, OpenSpec покажет предупреждение и предложит выполнить команду openspec update. Нажатие Ctrl+C также корректно отменяет выполнение мастера (без вывода трассировки стека) и завершает работу с кодом 130. В чек-листе рабочих процессов отметка [x] означает, что соответствующий рабочий процесс выбран в глобальной конфигурации. Чтобы применить эти выборки к файлам проекта, выполните команду openspec update (или выберите пункт «Применить изменения к этому проекту сейчас?» в появившемся в проекте запросе).

Интерактивные примеры:

bash

# Обновление только режима доставки
openspec config profile
# выбрать: Изменить только режим доставки
# выбрать режим доставки: Только навыки

# Обновление только рабочих процессов
openspec config profile
# выбрать: Изменить только рабочие процессы
# переключите нужные рабочие процессы в чек-листе, затем подтвердите выбор

Вспомогательные команды

`openspec feedback`

Отправить отзыв о работе OpenSpec. Создает задачу в GitHub.

openspec feedback <сообщение> [опции]

Аргументы:

Аргумент	Обязательность	Описание
`message`	Да	Текст отзыва

Опции:

Опция	Описание
`--body <текст>`	Подробное описание

Требования: должен быть установлен и авторизован GitHub CLI (gh).

Пример:

bash

openspec feedback "Add support for custom artifact types" \
  --body "I'd like to define my own artifact types beyond the built-in ones."

`openspec completion`

Управление автодополнением команд для CLI OpenSpec.

openspec completion <подкоманда> [оболочка]

Подкоманды:

Подкоманда	Описание
`generate [оболочка]`	Вывести скрипт автодополнения в стандартный вывод
`install [оболочка]`	Установить автодополнение для вашей оболочки
`uninstall [оболочка]`	Удалить установленное автодополнение

Поддерживаемые оболочки: bash, zsh, fish, powershell

Примеры:

bash

# Установить автодополнение (оболочка определяется автоматически)
openspec completion install

# Установить для конкретной оболочки
openspec completion install zsh

# Сгенерировать скрипт для ручной установки
openspec completion generate bash > ~/.bash_completion.d/openspec

# Удалить автодополнение
openspec completion uninstall

Коды завершения

Код	Значение
`0`	Успешное выполнение
`1`	Ошибка (сбой проверки, отсутствие файлов и т. д.)

Переменные окружения

Переменная	Описание
`OPENSPEC_TELEMETRY`	Установите значение `0` для отключения телеметрии
`DO_NOT_TRACK`	Установите значение `1` для отключения телеметрии (стандартный сигнал DNT)
`OPENSPEC_CONCURRENCY`	Уровень параллелизма по умолчанию для пакетной проверки (по умолчанию: 6)
`EDITOR` или `VISUAL`	Редактор, используемый для команды `openspec config edit`
`NO_COLOR`	Отключить цветной вывод, если переменная установлена

Связанная документация

Команды — Слэш-команды ИИ (/opsx:propose, /opsx:apply и т. д.)
Рабочие процессы — Распространенные сценарии использования и правила выбора команд
Настройка и кастомизация — Создание пользовательских схем и шаблонов
Начало работы — Руководство по первичной настройке

Справочник по CLI ​

Сводка ​

Команды для человека и для агентов ​

Команды только для человека ​

Команды, совместимые с агентами ​

Глобальные параметры ​

Команды настройки ​

openspec init ​

openspec update ​

Хранилища (автономные репозитории OpenSpec) ​

openspec store setup ​

openspec store register ​

openspec store unregister ​

openspec store remove ​

openspec store list ​

openspec store doctor ​

Ссылки на хранилища из проекта ​

Запись источника клонирования хранилища ​

Объявление хранилища по умолчанию ​

Doctor (состояние связей) ​

Рабочий контекст (собранный набор) ​

Личные рабочие наборы ​

Команды просмотра ​

openspec list ​

openspec view ​

openspec show ​

Команды валидации ​

openspec validate ​

Команды жизненного цикла ​

openspec archive ​

Команды рабочего процесса ​

openspec new change ​

openspec status ​

openspec instructions ​

openspec templates ​

openspec schemas ​

Команды для работы со схемами ​

openspec schema init ​

openspec schema fork ​

openspec schema validate ​

openspec schema which ​

Команды для работы с конфигурацией ​

openspec config ​

Вспомогательные команды ​

openspec feedback ​

openspec completion ​

Коды завершения ​

Переменные окружения ​

Связанная документация ​

Справочник по CLI

Сводка

Команды для человека и для агентов

Команды только для человека

Команды, совместимые с агентами

Глобальные параметры

Команды настройки

`openspec init`

`openspec update`

Хранилища (автономные репозитории OpenSpec)

`openspec store setup`

`openspec store register`

`openspec store unregister`

`openspec store remove`

`openspec store list`

`openspec store doctor`

Ссылки на хранилища из проекта

Запись источника клонирования хранилища

Объявление хранилища по умолчанию

Doctor (состояние связей)

Рабочий контекст (собранный набор)

Личные рабочие наборы

Команды просмотра

`openspec list`

`openspec view`

`openspec show`

Команды валидации

`openspec validate`

Команды жизненного цикла

`openspec archive`

Команды рабочего процесса

`openspec new change`

`openspec status`

`openspec instructions`

`openspec templates`

`openspec schemas`

Команды для работы со схемами

`openspec schema init`

`openspec schema fork`

`openspec schema validate`

`openspec schema which`

Команды для работы с конфигурацией

`openspec config`

Вспомогательные команды

`openspec feedback`

`openspec completion`

Коды завершения

Переменные окружения

Связанная документация