Довідка CLI

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

Зміст

Категорія	Команди	Призначення
Налаштування	`init`, `update`	Ініціалізувати та оновити OpenSpec у вашому проєкті
Сховища (standalone OpenSpec repos)	`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`	Зворотний зв'язок та інтеграція з оболонкою (shell)

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

Більшість команд інтерфейсу командного рядка (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>`	Перевизначити глобальний профіль для цього запуску ініціалізації (`core` або `custom`)

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

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

Цей список віддзеркалює AI_TOOLS у src/core/config.ts. Дивіться Supported Tools для навичок та шляхів команд кожного інструменту.

Приклади:

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 upgrade
npm update @fission-ai/openspec
openspec update

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

Бета. Сховища та функції, побудовані на них (посилання, робочий контекст, робочі набори), є новими; назви команд, прапорці, формати файлів та вивід JSON можуть змінюватися між релізами. Для покрокового проходження з акцентом на проблему див. stores guide.

Сховище — це незалежний репозиторій 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`

Реєструє існуючу локальну папку сховища.

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-джерело вибірки); setup/register називає його, а 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

Звичайні команди потім автоматично розв'язуються до оголошеного сховища; банер кореня та блок root у JSON повідомляють source: "declared" з ID сховища, а виведені підказки все ще містять --store <id>. Оголошення є запасним варіантом, ніколи не перевизначаючим: явний --store завжди перемагає, а директорія з реальними папками планування ігнорує вказівник (з попередженням). Щоб перетворити репозиторій-вказівник на локальний корінь OpenSpec, видаліть рядок store: та виконайте openspec init — init відмовляється створювати шаблон, поки оголошення присутнє.

Doctor (здоров'я репозиторію)

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

bash

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

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

Особисті набори робіт

Бета. Набори робіт є частиною нового бета-інтерфейсу; команди, прапорці та формати файлів можуть змінюватися між релізами. Для ознайомлення дивіться stores guide.

Набір робіт (workset) — це особистий, названий перегляд папок, над якими ви працюєте разом — корінь планування плюс все інше, що ви обираєте — який зберігається на вашій машині та відкривається за назвою у вашому інструменті. Він суто локальний: ніколи не комітиться, ніколи не ділиться, ніколи не походить від декларацій, і видалення одного з них ніколи не торкається членської папки.

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 (один прапор --dir на кожного члена) — і ключ 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

Вивід (текст):

Changes:
  add-dark-mode     No tasks      just now

`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-індексом (режим 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]

Аргументи:

Аргумент	Обов'язковий	Опис
`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

Вивід (текст):

Validating add-dark-mode...
  ✓ proposal.md valid
  ✓ specs/ui/spec.md valid
  ⚠ design.md: missing "Technical Approach" section

1 warning found

Вивід (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`	Пропустити оновлення специфікацій (для змін лише інфраструктури/інструментарію/документації)
`--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]

Параметри:

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

Приклади:

bash

# Інтерактивна перевірка статусу
openspec status

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

# JSON для використання агентом
openspec status --change add-dark-mode --json

Вивід (текст):

Change: add-dark-mode
Schema: spec-driven
Progress: 2/4 artifacts complete

[x] proposal
[ ] design
[x] specs
[-] tasks (blocked by: design)

Вивід (JSON):

json

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

`openspec instructions`

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

openspec instructions [artifact] [options]

Аргументи:

Аргумент	Обов'язковий	Опис
`artifact`	Ні	ID артефакту: `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

# Отримати інструкції apply/реалізації
openspec instructions apply --change add-dark-mode

# JSON для споживання агентом
openspec instructions design --change add-dark-mode --json

Вивід включає:

Шаблонний вміст для артефакту
Контекст проєкту з конфігурації
Вміст із залежних артефактів
Правила для кожного артефакту з конфігурації

`openspec templates`

Показати розв'язані шляхи шаблонів для всіх артефактів у схемі.

openspec templates [options]

Параметри:

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

Приклади:

bash

# Показати шляхи шаблонів для стандартної схеми
openspec templates

# Показати шаблони для користувацької схеми
openspec templates --schema my-workflow

# JSON для програмного використання
openspec templates --json

Вивід (текст):

Schema: spec-driven

Templates:
  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

Вивід:

Available schemas:

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

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

Команди схем (Schema Commands)

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

`openspec schema init`

Створити нову локальну для проєкту схему.

openspec schema init <name> [options]

Аргументи:

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

Опції:

Опція	Опис
`--description <text>`	Опис схеми
`--artifacts <list>`	Артифактні ID, розділені комами (за замовчуванням: `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/<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

# Форк вбудованої схеми, орієнтованої на специфікації
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
  Джерело: /usr/local/lib/node_modules/@fission-ai/openspec/schemas/spec-driven

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

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

Команди конфігурації (Configuration Commands)

`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

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

# Редагувати конфіг у вашому редакторі
openspec config edit

# Налаштувати профіль за допомогою майстра на основі дій
openspec config profile

# Швидкий пресет: переключити робочі процеси на core (зберігаючи delivery mode)
openspec config profile core

openspec config profile починається з підсумку поточного стану, а потім дозволяє вам вибрати:

Змінити delivery + робочі процеси
Змінити лише delivery
Змінити лише робочі процеси
Зберегти поточні налаштування (вихід)

Якщо ви зберігаєте поточні налаштування, жодні зміни не записуються і жодного підтвердження оновлення не відображається. Якщо немає змін конфігурації, але файли поточного проєкту не синхронізовані з вашим глобальним профілем/delivery, OpenSpec покаже попередження та запропонує openspec update. Натискання Ctrl+C також коректно скасовує процес (без stack trace) і виходить із кодом 130. У контрольному списку робочого процесу [x] означає, що робочий процес вибраний у глобальній конфігурації. Щоб застосувати ці вибори до файлів проєкту, виконайте openspec update (або оберіть Apply changes to this project now? при запиті всередині проєкту).

Інтерактивні приклади:

bash

# Оновлення лише delivery
openspec config profile
# вибрати: Змінити лише delivery
# вибрати delivery: Skills only

# Оновлення лише робочих процесів
openspec config profile
# вибрати: Змінити лише робочі процеси
# перемкнути робочі процеси у контрольному списку, а потім підтвердити

Утиліти (Utility Commands)

`openspec feedback`

Надіслати відгук про OpenSpec. Створює issue на GitHub.

openspec feedback <message> [options]

Аргументи:

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

Опції:

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

Вимоги: 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 <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

Коди виходу (Exit Codes)

Код	Значення
`0`	Успіх
`1`	Помилка (помилка валідації, відсутні файли тощо)

Змінні середовища (Environment Variables)

Змінна	Опис
`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 ​

Сховища (standalone 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 ​

Команди схем (Schema Commands) ​

openspec schema init ​

openspec schema fork ​

openspec schema validate ​

openspec schema which ​

Команди конфігурації (Configuration Commands) ​

openspec config ​

Утиліти (Utility Commands) ​

openspec feedback ​

openspec completion ​

Коди виходу (Exit Codes) ​

Змінні середовища (Environment Variables) ​

Пов'язана документація (Related Documentation) ​

Довідка CLI

Зміст

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

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

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

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

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

`openspec init`

`openspec update`

Сховища (standalone 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`

Команди схем (Schema Commands)

`openspec schema init`

`openspec schema fork`

`openspec schema validate`

`openspec schema which`

Команди конфігурації (Configuration Commands)

`openspec config`

Утиліти (Utility Commands)

`openspec feedback`

`openspec completion`

Коди виходу (Exit Codes)

Змінні середовища (Environment Variables)

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