Довідник CLI

CLI OpenSpec (openspec) надає команди терміналу для налаштування проєкту, валідації, перевірки статусу та керування. Ці команди доповнюють слеш-команди AI (наприклад, /opsx:propose), задокументовані у Commands.

Огляд

Категорія	Команди	Призначення
Налаштування	`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.

Команди лише для людини

Ці команди є інтерактивними та призначені для використання в терміналі:

Команда	Призначення
`openspec init`	Ініціалізація проєкту (інтерактивні запити)
`openspec view`	Інтерактивна панель
`openspec workset open <name>`	Відкрити збережений робочий набір (вікно редактора або сесія термінального агента)
`openspec config edit`	Відкрити конфігурацію в редакторі
`openspec feedback`	Надіслати відгук через GitHub
`openspec completion install`	Встановити автодоповнення оболонки

Команди, сумісні з агентами

Ці команди підтримують виведення --json для програмного використання AI-агентами та скриптами:

Команда	Використання людиною	Використання агентом
`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` для неінтерактивного видалення

Глобальні опції

Ці опції працюють з усіма командами:

Опція	Опис
`--version`, `-V`	Показати номер версії
`--no-color`	Вимкнути кольорове виведення
`--help`, `-h`	Показати довідку для команди

Команди налаштування

`openspec init`

Ініціалізувати OpenSpec у вашому проєкті. Створює структуру тек та налаштовує інтеграції з AI-інструментами.

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

openspec init [path] [options]

Аргументи:

Аргумент	Обов'язковий	Опис
`path`	Ні	Цільова тека (за замовчуванням: поточна тека)

Опції:

Опція	Опис
`--tools <list>`	Налаштувати AI-інструменти неінтерактивно. Використовуйте `all`, `none` або список через кому
`--force`	Автоматичне очищення застарілих файлів без запитів
`--profile <profile>`	Перевизначити глобальний профіль для цього запуску init (`core` або `custom`)

--profile custom використовує будь-які робочі процеси, обрані в глобальній конфігурації (openspec config profile).

Підтримувані ID інструментів (--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/       # Команди OPSX для Cursor (якщо доставка включає команди)
... (інші конфігурації інструментів)

`openspec update`

Оновити файли інструкцій OpenSpec після оновлення CLI. Повторно генерує файли конфігурації AI-інструментів, використовуючи ваш поточний глобальний профіль, обрані робочі процеси та режим доставки.

openspec update [path] [options]

Аргументи:

Аргумент	Обов'язковий	Опис
`path`	Ні	Цільова тека (за замовчуванням: поточна тека)

Опції:

Опція	Опис
`--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]

Опції:

Опція	Опис
`--path <path>`	Тека, де має знаходитися сховище (наприклад, `~/openspec/<id>`)
`--remote <url>`	Записати канонічний віддалений репозиторій у `store.yaml` нового сховища
`--init-git`	Ініціалізувати Git-репозиторій з початковим комітом (за замовчуванням)
`--no-init-git`	Пропустити всі Git-дії: ні ініціалізації, ні початкового коміту
`--json`	Виведення JSON

Неінтерактивні запуски (--json, скрипти, агенти) повинні передавати як ID сховища, так і --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]

Опції:

Опція	Опис
`--id <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 та для людини) містить індекс специфікацій кожного сховища, на яке є посилання — ID специфікацій, однорядкове резюме з розділу Purpose кожної специфікації та команду отримання (openspec show <spec-id> --type spec --store <id>). Індекс будується на льоту з зареєстрованої копії при кожному запуску; вміст специфікації ніколи не копіюється у виведення.

Посилання є контекстом лише для читання. Вони ніколи не змінюють, де працюють команди: робота залишається в корені власного репозиторію, а запис у сховище, на яке є посилання, залишається явною дією --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-походження копії); поради щодо спільного використання налаштування/реєстрації називають його; а реєстрація записує походження копії в локальний реєстр машини.

Оголошення посилання також може містити джерело клонування, товариш, який ще не має сховища, отримує повне, готове до вставлення виправлення (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" з ID сховища, а надруковані поради все ще містять --store <id>. Оголошення є запасним варіантом, ніколи не перевизначенням: явний --store завжди має пріоритет, а тека з реальними теками планування ігнорує вказівник (з попередженням). Щоб перетворити репозиторій-вказівник на локальний корінь OpenSpec, видаліть рядок store: та запустіть openspec init — init відмовляється створювати каркас, поки оголошення присутнє.

Варіант на рівні машини охоплює всі репозиторії одразу: openspec config set defaultStore <id> (див. Конфігурація). Він консультується лише після того, як --store, локальний корінь та вказівник проєкту не змогли розв'язатися; банер кореня та блок JSON root тоді повідомляють source: "global_default".

Доктор (стан зв'язків)

Одне запитання лише для читання, одне місце: чи є корінь OpenSpec справним і чи доступні сховища, на які він посилається, на цій машині?

bash

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

Звіт поділяє стан кореня, стан метаданих сховищ (включаючи примітку, коли записаний віддалений репозиторій та джерело вибірки розходяться, а також примітку, коли вибірка сховища відстала від свого останнього отриманого відстежуваного посилання вищого рівня), і стан посилань (відображаються ті самі інструкції діагностики, з варіантами виправлення шляхом клонування для нерозв'язаних посилань). Результати перевірки здоров'я будь-якого рівня серйозності завершують роботу з кодом 0 — агенти зчитують масиви status; з кодом 1 завершують роботу лише збої команди (немає кореня, невідоме сховище). Доктор ніколи не клонує, не синхронізує та не відновлює. Щоб отримати сам зібраний набір, а не його стан, використовуйте 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 <порядок>`	Сортує за значенням `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 <тип>`	Вкажіть тип: `change` або `spec` (визначається автоматично, якщо немає неоднозначності)
`--json`	Виводить у форматі JSON
`--no-interactive`	Вимкнути запити

Опції, специфічні для змін:

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

Опції, специфічні для специфікацій:

Опція	Опис
`--requirements`	Показати лише вимоги, виключити сценарії (режим JSON)
`--no-scenarios`	Виключити вміст сценаріїв (режим JSON)
`-r, --requirement <id>`	Показати конкретну вимогу за 1-індексованим індексом (режим 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 <тип>`	Вкажіть тип, якщо назва неоднозначна: `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 дійсний
  ⚠ design.md: відсутній розділ "Технічний підхід"

Знайдено 1 попередження

Виведення (JSON):

json

{
  "version": "1.0.0",
  "results": {
    "changes": [
      {
        "name": "add-dark-mode",
        "valid": true,
        "warnings": ["design.md: відсутній розділ 'Технічний підхід'"]
      }
    ]
  },
  "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 у нижньому регістрі. Вони починаються з літери нижнього регістру, потім містять лише літери нижнього регістру, цифри та одинарні дефіси. Заборонено починати назву з цифри, використовувати пробіли, підкреслення, літери верхнього регістру, послідовні дефіси або дефіси на початку чи в кінці назви. Якщо ви включаєте ID зовнішнього квитка, додайте до нього префікс зі слова, наприклад ticket-123-add-notifications замість 123-add-notifications.

Опції:

Опція	Опис
`--description <текст>`	Опис, який додається до файлу `index.md`
`--goal <текст>`	Необов'язкові метадані цілі, що зберігаються разом зі зміною
`--schema <назва>`	Схема робочого процесу для використання
`--store <id>`	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 <назва>`	Перевизначення схеми (визначається автоматично з конфігурації зміни)
`--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 (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`

Отримує розширені інструкції для створення артефакту або застосування завдань. Використовується AI-агентами, щоб зрозуміти, що створити далі.

openspec instructions [artifact] [options]

Аргументи:

Аргумент	Обов'язковий	Опис
`artifact`	Ні	ID артефакту: `proposal`, `specs`, `design`, `tasks` або `apply`

Опції:

Опція	Опис
`--change <id>`	Назва зміни (обов'язкова в неінтерактивному режимі)
`--schema <назва>`	Перевизначення схеми
`--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 <назва>`	Схема для перевірки (за замовчуванням: `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> [options]

Аргументи:

Аргумент	Обов'язковий	Опис
`name`	Так	Назва схеми (kebab-case)

Опції:

Опція	Опис
`--description <text>`	Опис схеми
`--artifacts <list>`	Ідентифікатори артефактів, розділені комами (за замовчуванням: `proposal,specs,design,tasks`)
`--default`	Встановити як стандартну схему проєкту
`--no-default`	Не запитувати про встановлення за замовчуванням
`--force`	Перезаписати існуючу схему
`--json`	Вивід у форматі JSON

Приклади:

bash

# Інтерактивне створення схеми
openspec schema init research-first

# Неінтерактивне з конкретними артефактами
openspec schema init rapid \
  --description "Робочий процес швидких ітерацій" \
  --artifacts "proposal,tasks" \
  --default

Що створює:

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

`openspec schema fork`

Копіювати існуючу схему у ваш проєкт для налаштування.

openspec schema fork <source> [name] [options]

Аргументи:

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

Опції:

Опція	Опис
`--force`	Перезаписати існуючий пункт призначення
`--json`	Вивід у форматі JSON

Приклад:

bash

# Форк вбудованої схеми spec-driven
openspec schema fork spec-driven my-workflow

`openspec schema validate`

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

openspec schema validate [name] [options]

Аргументи:

Аргумент	Обов'язковий	Опис
`name`	Ні	Схема для перевірки (перевіряє всі, якщо опущено)

Опції:

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

Приклад:

bash

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

# Перевірити всі схеми
openspec schema validate

`openspec schema which`

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

openspec schema which [name] [options]

Аргументи:

Аргумент	Обов'язковий	Опис
`name`	Ні	Назва схеми

Опції:

Опція	Опис
`--all`	Перелічити всі схеми з їхніми джерелами
`--json`	Вивід у форматі JSON

Приклад:

bash

# Перевірити, звідки походить схема
openspec schema which spec-driven

Вивід:

spec-driven розв'язується з: package
  Source: /usr/local/lib/node_modules/@fission-ai/openspec/schemas/spec-driven

Пріоритетність схем:

Проєкт: openspec/schemas/<name>/
Користувач: ~/.local/share/openspec/schemas/<name>/
Пакет: Вбудовані схеми

Команди конфігурації

`openspec config`

Перегляд та зміна глобальної конфігурації OpenSpec.

openspec config <subcommand> [options]

Підкоманди:

Підкоманда	Опис
`path`	Показати розташування файлу конфігурації
`list`	Показати всі поточні налаштування
`get <key>`	Отримати конкретне значення
`set <key> <value>`	Встановити значення
`unset <key>`	Видалити ключ
`reset`	Скинути до значень за замовчуванням
`edit`	Відкрити у `$EDITOR`
`profile [preset]`	Інтерактивно налаштувати профіль робочого процесу або через пресет

Приклади:

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 issue.

openspec feedback <message> [options]

Аргументи:

Аргумент	Обов'язковий	Опис
`message`	Так	Повідомлення відгуку

Опції:

Опція	Опис
`--body <text>`	Детальний опис

Вимоги: GitHub CLI (gh) має бути встановлено та автентифіковано.

Приклад:

bash

openspec feedback "Додати підтримку користувацьких типів артефактів" \
  --body "Я хотів би визначити власні типи артефактів понад вбудовані."

`openspec completion`

Керування автодовненням оболонки для OpenSpec CLI.

openspec completion <subcommand> [shell]

Підкоманди:

Підкоманда	Опис
`generate [shell]`	Вивести скрипт автодовнення у stdout
`install [shell]`	Встановити автодовнення для вашої оболонки
`uninstall [shell]`	Видалити встановлені автодовнення

Підтримувані оболонки: 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`	Вимкнути кольоровий вивід, коли встановлено

Пов'язана документація

Commands - AI-команди з косою рискою (/opsx:propose, /opsx:apply тощо)
Workflows - Загальні шаблони та коли використовувати кожну команду
Customization - Створення користувацьких схем та шаблонів
Getting Started - Посібник з початкового налаштування

Довідник CLI ​

Огляд ​

Команди для людини та агента ​

Команди лише для людини ​

Команди, сумісні з агентами ​

Глобальні опції ​

Команди налаштування ​

openspec init ​

openspec update ​

Сховища (окремі репозиторії OpenSpec) ​

openspec store setup ​

openspec store register ​

openspec store unregister ​

openspec store remove ​

openspec store list ​

openspec store 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`

Посилання на сховища з проєкту

Запис місця клонування сховища

Оголошення сховища за замовчуванням

Доктор (стан зв'язків)

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

Персональні робочі набори

Команди перегляду

`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`

Коди виходу

Змінні середовища

Пов'язана документація