Команди
Це довідник по слеш-командах OpenSpec. Ці команди викликаються в інтерфейсі чату вашого AI-ассистента для кодування (наприклад, Claude Code, Cursor, Windsurf).
Щодо шаблонів робочих процесів та коли використовувати кожну команду, див. Робочі процеси. Щодо CLI-команд, див. CLI.
Швидкий довідник
Шлях за замовчуванням (профіль core)
| Команда | Призначення |
|---|---|
/opsx:propose | Створити зміну та згенерувати артефакти планування в один крок |
/opsx:explore | Обміркувати ідеї перед фіксацією зміни |
/opsx:apply | Реалізувати завдання зі зміни |
/opsx:archive | Архівувати завершену зміну |
Розширені команди робочого процесу (вибір користувацького робочого процесу)
| Команда | Призначення |
|---|---|
/opsx:new | Розпочати нову заготовку зміни |
/opsx:continue | Створити наступний артефакт на основі залежностей |
/opsx:ff | Швидке просування: створити всі артефакти планування одразу |
/opsx:verify | Перевірити відповідність реалізації артефактам |
/opsx:sync | Об'єднати дельта-специфікації з основними специфікаціями |
/opsx:bulk-archive | Архівувати кілька змін одночасно |
/opsx:onboard | Керований посібник через повний робочий процес |
Глобальний профіль за замовчуванням — core. Щоб увімкнути розширені команди робочого процесу, виконайте openspec config profile, виберіть робочі процеси, а потім виконайте openspec update у вашому проєкті.
Довідник команд
/opsx:propose
Створює нову зміну та генерує артефакти планування в один крок. Це стандартна початкова команда в профілі core.
Синтаксис:
text
/opsx:propose [назва-або-опис-зміни]Аргументи:
| Аргумент | Обов'язковий | Опис |
|---|---|---|
назва-або-опис-зміни | Ні | Назва у форматі kebab-case або опис зміни природною мовою |
Що робить:
- Створює
openspec/changes/<назва-зміни>/ - Генерує артефакти, необхідні перед реалізацією (для
spec-driven: пропозиція, специфікації, дизайн, завдання) - Зупиняється, коли зміна готова до
/opsx:apply
Приклад:
text
Ви: /opsx:propose add-dark-mode
ШІ: Створено openspec/changes/add-dark-mode/
✓ proposal.md
✓ specs/ui/spec.md
✓ design.md
✓ tasks.md
Готово до реалізації. Запустіть /opsx:apply.Поради:
- Використовуйте для найшвидшого повного циклу
- Якщо потрібен покроковий контроль артефактів, увімкніть розширені робочі процеси та використовуйте
/opsx:new+/opsx:continue
/opsx:explore
Обмірковує ідеї, досліджує проблеми та уточнює вимоги перед фіксацією зміни.
Синтаксис:
/opsx:explore [тема]Аргументи:
| Аргумент | Обов'язковий | Опис |
|---|---|---|
тема | Ні | Що ви хочете дослідити або вивчити |
Що робить:
- Відкриває дослідницьку розмову без структурних вимог
- Досліджує базу коду для відповідей на запитання
- Порівнює варіанти та підходи
- Створює візуальні діаграми для прояснення думок
- Може перейти до
/opsx:propose(за замовчуванням) або/opsx:new(розширений робочий процес), коли інсайти кристалізуються
Приклад:
text
Ви: /opsx:explore
ШІ: Що ви хочете дослідити?
Ви: Як нам обробляти автентифікацію для мобільного додатку?
ШІ: Дозвольте мені дослідити ваше поточне налаштування автентифікації...
[Аналізує базу коду]
Я бачу, що ви використовуєте сесійну автентифікацію для веб-додатку.
Для мобільного додатку у нас є три основні варіанти:
1. Токени JWT (безстанні, працює офлайн)
2. OAuth2 (якщо потрібен сторонній вхід)
3. Розширити поточні сесії (простіше, але потребує з'єднання)
Ваш API вже має налаштовану CORS. Який напрямок вас цікавить?
Ви: Оберемо JWT. Чи можемо ми почати зміну для цього?
ШІ: Готовий, коли ви будете готові. Запустіть /opsx:propose add-jwt-auth, щоб почати.Поради:
- Використовуйте, коли вимоги незрозумілі або потрібне дослідження
- Під час дослідження артефакти не створюються
- Добре підходить для порівняння кількох підходів перед рішенням
- Може читати файли та шукати в базі коду
/opsx:new
Запускає нову заготовку зміни. Створює папку зміни та чекає на генерацію артефактів за допомогою /opsx:continue або /opsx:ff.
Ця команда є частиною набору розширених робочих процесів (не входить до профілю core за замовчуванням).
Синтаксис:
/opsx:new [назва-зміни] [--schema <назва-схеми>]Аргументи:
| Аргумент | Обов'язковий | Опис |
|---|---|---|
назва-зміни | Ні | Назва для папки зміни (запитується, якщо не надано) |
--schema | Ні | Схема робочого процесу для використання (за замовчуванням: з конфігурації або spec-driven) |
Що робить:
- Створює директорію
openspec/changes/<назва-зміни>/ - Створює файл метаданих
.openspec.yamlу папці зміни - Показує шаблон першого артефакту, готового до створення
- Запитує назву зміни та схему, якщо вони не надані
Що створює:
openspec/changes/<назва-зміни>/
└── .openspec.yaml # Метадані зміни (схема, дата створення)Приклад:
Ви: /opsx:new add-dark-mode
ШІ: Створено openspec/changes/add-dark-mode/
Схема: spec-driven
Готово до створення: proposal
Використовуйте /opsx:continue для створення або /opsx:ff для створення всіх артефактів.Поради:
- Використовуйте описові назви:
add-feature,fix-bug,refactor-module - Уникайте загальних назв на кшталт
update,changes,wip - Схему також можна встановити в конфігурації проекту (
openspec/config.yaml)
/opsx:continue
Створює наступний артефакт у ланцюгу залежностей. Створює один артефакт за раз для поступового прогресу.
Синтаксис:
/opsx:continue [назва-зміни]Аргументи:
| Аргумент | Обов'язковий | Опис |
|---|---|---|
назва-зміни | Ні | Яку зміну продовжити (визначається з контексту, якщо не надано) |
Що робить:
- Запитує граф залежностей артефактів
- Показує, які артефакти готові, а які заблоковані
- Створює перший готовий артефакт
- Читає файли залежностей для контексту
- Показує, що стає доступним після створення
Приклад:
Ви: /opsx:continue
ШІ: Зміна: add-dark-mode
Статус артефактів:
✓ proposal (виконано)
◆ specs (готово)
◆ design (готово)
○ tasks (заблоковано - потребує: specs)
Створення specs...
[Читає proposal.md, створює specs на основі вимог]
✓ Створено openspec/changes/add-dark-mode/specs/ui/spec.md
Тепер доступно: tasks
Запустіть /opsx:continue для створення наступного артефакту.Поради:
- Використовуйте, коли хочете переглянути кожен артефакт перед продовженням
- Добре підходить для складних змін, де потрібен контроль
- Кілька артефактів можуть стати готовими одночасно
- Ви можете редагувати створені артефакти перед продовженням
/opsx:ff
Швидке просування через створення артефактів. Створює всі артефакти планування одразу.
Синтаксис:
/opsx:ff [назва-зміни]Аргументи:
| Аргумент | Обов'язковий | Опис |
|---|---|---|
назва-зміни | Ні | Яку зміну швидко просувати (визначається з контексту, якщо не надано) |
Що робить:
- Створює всі артефакти в порядку залежностей
- Відстежує прогрес через список завдань
- Зупиняється, коли всі артефакти, необхідні для застосування, завершені
- Читає кожну залежність перед створенням наступного артефакту
Приклад:
Ви: /opsx:ff add-dark-mode
ШІ: Швидке просування add-dark-mode...
✓ Створення proposal.md
✓ Створення specs/ui/spec.md
✓ Створення design.md
✓ Створення tasks.md
Всі артефакти планування завершені!
Готово до реалізації. Запустіть /opsx:apply для початку.Поради:
- Використовуйте, коли маєте чітке уявлення про те, що створюєте
- Швидше за
/opsx:continueдля простих змін - Ви все одно можете редагувати артефакти після цього
- Добре підходить для малих та середніх функцій
/opsx:apply
Реалізує завдання зі зміни. Працює через список завдань, пише код та відмічає пункти.
Синтаксис:
/opsx:apply [назва-зміни]Аргументи:
| Аргумент | Обов'язковий | Опис |
|---|---|---|
назва-зміни | Ні | Яку зміну реалізувати (визначається з контексту, якщо не надано) |
Що робить:
- Читає
tasks.mdта визначає незавершені завдання - Працює над завданнями одне за одним
- Пише код, створює файли, запускає тести за потреби
- Позначає завдання як завершені прапорцями
[x]
Приклад:
Ви: /opsx:apply
ШІ: Реалізація add-dark-mode...
Читання tasks.md:
- [ ] 1.1 Створити ThemeContext
- [ ] 1.2 Додати CSS custom properties
- [ ] 1.3 Реалізувати збереження в localStorage
Робота над 1.1: Створити ThemeContext...
[Створює src/context/ThemeContext.tsx]
✓ 1.1 Завершено
Робота над 1.2: Додати CSS custom properties...
[Оновлює src/styles/globals.css]
✓ 1.2 Завершено
...Поради:
- Може відновити роботу з місця перерви
- Використовуйте для паралельних змін, вказуючи назву зміни
- Стан завершення відстежується в прапорцях
tasks.md
/opsx:verify
Перевіряє, чи реалізація відповідає артефактам вашої зміни. Перевіряє повноту, правильність та узгодженість.
Синтаксис:
/opsx:verify [назва-зміни]Аргументи:
| Аргумент | Обов'язковий | Опис |
|---|---|---|
назва-зміни | Ні | Яку зміну перевірити (визначається з контексту, якщо не надано) |
Що робить:
- Перевіряє три виміри якості реалізації
- Шукає в базі коду докази реалізації
- Повідомляє про проблеми, класифіковані як КРИТИЧНІ, ПОПЕРЕДЖЕННЯ або ПРОПОЗИЦІЇ
- Не блокує архівацію, але виявляє проблеми
Виміри перевірки:
| Вимір | Що перевіряє |
|---|---|
| Повнота | Всі завдання виконано, всі вимоги реалізовано, сценарії охоплено |
| Правильність | Реалізація відповідає наміру специфікації, обробляються крайні випадки |
| Узгодженість | Рішення дизайну відображені в коді, шаблони узгоджені |
Приклад:
Ви: /opsx:verify
ШІ: Перевірка add-dark-mode...
ПОВНОТА
✓ Всі 8 завдань у tasks.md позначено
✓ Всі вимоги у specs мають відповідний код
⚠ Сценарій "System preference detection" не має покриття тестами
ПРАВИЛЬНІСТЬ
✓ Реалізація відповідає наміру специфікації
✓ Крайні випадки зі сценаріїв обробляються
✓ Стани помилок відповідають визначенням специфікації
УЗГОДЖЕНІСТЬ
✓ Рішення дизайну відображені в структурі коду
✓ Конвенції іменування узгоджені з design.md
⚠ Дизайн згадує "CSS variables", але реалізація використовує класи Tailwind
ПІДСУМКОВО
─────────────────────────────
Критичних проблем: 0
Попереджень: 2
Готово до архівації: Так (з попередженнями)
Рекомендації:
1. Додати тест для виявлення системних уподобань
2. Оновити design.md, щоб відобразити використання Tailwind, або рефакторити для використання CSS variablesПоради:
- Запускайте перед архівацією, щоб виявити невідповідності на ранньому етапі
- Попередження не блокують архівацію, але вказують на потенційні проблеми
- Добре підходить для перегляду роботи ШІ перед фіксацією
- Може виявити розбіжність між артефактами та реалізацією
/opsx:sync
Необов'язкова команда. Зливає дельта-специфікації зі зміни в основні специфікації. Архівація запропонує синхронізацію за потреби, тому зазвичай вам не потрібно запускати це вручну.
Синтаксис:
/opsx:sync [назва-зміни]Аргументи:
| Аргумент | Обов'язковий | Опис |
|---|---|---|
назва-зміни | Ні | Яку зміну синхронізувати (визначається з контексту, якщо не надано) |
Що робить:
- Читає дельта-специфікації з папки зміни
- Аналізує секції ДОДАНО/ЗМІНЕНО/ВИДАЛЕНО/ПЕРЕЙМЕНОВАНО
- Зливає зміни в основну директорію
openspec/specs/ - Зберігає існуючий вміст, не згаданий у дельті
- Не архівує зміну (залишається активною)
Приклад:
text
Ви: /opsx:sync
ШІ: Синхронізація дельта-специфікацій add-dark-mode...
Читання: openspec/changes/add-dark-mode/specs/ui/spec.md
Ціль: openspec/specs/ui/spec.md
Зміни для застосування:
✓ ДОДАНО: Вимога вибору теми (2 сценарії)
✓ ДОДАНО: Вимога доступності (1 сценарій)
Злиття...
✓ openspec/specs/ui/spec.md оновлено
Зміна залишається активною. Запустіть /opsx:archive, коли будете готові завершити.Коли використовувати вручну:
| Сценарій | Використовувати sync? |
|---|---|
| Тривала зміна, хочете мати специфікації в основній гілці перед архівацією | Так |
| Кілька паралельних змін потребують оновлених базових специфікацій | Так |
| Хочете попередньо переглянути/перевірити злиття окремо | Так |
| Швидка зміна, одразу до архівації | Ні (архівація обробить це) |
Поради:
- Синхронізація розумна, а не копіювання та вставка
- Може додавати сценарії до існуючих вимог без дублювання
- Зміна залишається активною після синхронізації (не архівується)
- Більшість користувачів ніколи не потребуватимуть виклику цього безпосередньо — архівація запропонує за потреби
/opsx:archive
Архівує завершену зміну. Фіналізує зміну та переміщує її до папки архіву.
Синтаксис:
/opsx:archive [назва-зміни]Аргументи:
| Аргумент | Обов'язковий | Опис |
|---|---|---|
назва-зміни | Ні | Яку зміну архівувати (визначається з контексту, якщо не надано) |
Що робить:
- Перевіряє статус завершення артефактів
- Перевіряє завершення завдань (попереджає, якщо незавершені)
- Пропонує синхронізувати дельта-специфікації, якщо вони ще не синхронізовані
- Переміщує папку зміни до
openspec/changes/archive/YYYY-MM-DD-<назва>/ - Зберігає всі артефакти для аудиту
Приклад:
text
Ви: /opsx:archive
ШІ: Архівація add-dark-mode...
Статус артефактів:
✓ proposal.md існує
✓ specs/ існує
✓ design.md існує
✓ tasks.md існує (8/8 завдань завершено)
Дельта-специфікації: Ще не синхронізовано
→ Синхронізувати зараз? (рекомендовано)
Ви: Так
ШІ: ✓ Синхронізовано специфікації до openspec/specs/ui/spec.md
✓ Переміщено до openspec/changes/archive/2025-01-24-add-dark-mode/
Зміна успішно архівована.Поради:
- Архівація не блокується незавершеними завданнями, але попереджає
- Дельта-специфікації можна синхронізувати під час архівації або заздалегідь
- Архівовані зміни зберігаються для історії
- Спочатку використовуйте
/opsx:verifyдля виявлення проблем
/opsx:bulk-archive
Архівує кілька завершених змін одразу. Обробляє конфлікти специфікацій між змінами.
Синтаксис:
/opsx:bulk-archive [назви-змін...]Аргументи:
| Аргумент | Обов'язковий | Опис |
|---|---|---|
назви-змін | Ні | Конкретні зміни для архівації (запитує вибір, якщо не надано) |
Що робить:
- Перелічує всі завершені зміни
- Перевіряє кожну зміну перед архівацією
- Виявляє конфлікти специфікацій між змінами
- Вирішує конфлікти, перевіряючи, що фактично реалізовано
- Архівує в хронологічному порядку
Приклад:
Ви: /opsx:bulk-archive
ШІ: Знайдено 3 завершені зміни:
- add-dark-mode (8/8 завдань завершено)
- fix-login-bug (3/3 завдань завершено)
- update-footer (2/2 завдань завершено)
Перевірка конфліктів специфікацій...
⚠ add-dark-mode та update-footer обидві зачіпають specs/ui/
Перевірка бази коду для вирішення...
Обидві зміни реалізовано. Злиття в хронологічному порядку:
1. add-dark-mode (створено 20 січня)
2. update-footer (створено 22 січня)
Архівувати всі 3 зміни?
Ви: Так
ШІ: ✓ Архівовано add-dark-mode
✓ Архівовано fix-login-bug
✓ Архівовано update-footer
Специфікації злито: add-dark-mode → update-footerПоради:
- Добре підходить для паралельних потоків роботи
- Вирішення конфліктів агентне (перевіряє базу коду)
- Зміни архівуються в порядку створення
- Запитує перед перезаписом вмісту специфікацій
/opsx:onboard
Керований вступ через повний робочий процес OpenSpec. Інтерактивний підручник з використанням вашої фактичної бази коду.
Синтаксис:
/opsx:onboardЩо робить:
- Проводить через повний цикл робочого процесу з коментарями
- Сканує вашу базу коду для реальних можливостей вдосконалення
- Створює реальну зміну з реальними артефактами
- Реалізує фактичну роботу (малі, безпечні зміни)
- Архівує завершену зміну
- Пояснює кожен крок по мірі його виконання
Фази:
- Вітання та аналіз бази коду
- Пошук можливості для вдосконалення
- Створення зміни (
/opsx:new) - Написання пропозиції
- Створення специфікацій
- Написання дизайну
- Створення завдань
- Реалізація завдань (
/opsx:apply) - Перевірка реалізації
- Архівація зміни
- Підсумок та наступні кроки
Приклад:
Ви: /opsx:onboard
ШІ: Ласкаво просимо до OpenSpec!
Я проведу вас через повний робочий процес, використовуючи вашу фактичну базу коду.
Ми знайдемо щось невелике для покращення, створимо для цього належну зміну,
реалізуємо її та заархівуємо.
Дозвольте мені просканувати вашу базу коду для можливостей...
[Аналізує базу коду]
Я знайшов кілька речей, над якими ми можемо працювати:
1. Додати валідацію введення до форми зворотного зв'язку
2. Покращити повідомлення про помилки в процесі автентифікації
3. Додати стани завантаження для асинхронних кнопок
Що вас цікавить? (або запропонуйте щось інше)Поради:
- Найкраще для нових користувачів, які вивчають робочий процес
- Використовує реальний код, а не приклади-іграшки
- Створює реальну зміну, яку можна залишити або відхилити
- Займає 15-30 хвилин для завершення
Синтаксис команд за інструментами ШІ
Різні інструменти ШІ використовують дещо різний синтаксис команд. Використовуйте формат, який відповідає вашому інструменту:
| Інструмент | Приклад синтаксису |
|---|---|
| Claude Code | /opsx:propose, /opsx:apply |
| Cursor | /opsx-propose, /opsx-apply |
| Windsurf | /opsx-propose, /opsx-apply |
| Copilot (IDE) | /opsx-propose, /opsx-apply |
| Trae | Виклики на основі навичок, такі як /openspec-propose, /openspec-apply-change (без згенерованих файлів команд opsx-*) |
Мета однакова для всіх інструментів, але спосіб відображення команд може відрізнятися залежно від інтеграції.
Примітка: Команди GitHub Copilot (
.github/prompts/*.prompt.md) доступні лише в розширеннях IDE (VS Code, JetBrains, Visual Studio). GitHub Copilot CLI наразі не підтримує користувацькі файли підказок — перегляньте Підтримувані інструменти для деталей та обхідних рішень.
Застарілі команди
Ці команди використовують старіший робочий процес "все одразу". Вони все ще працюють, але рекомендуються команди OPSX.
| Команда | Що вона робить |
|---|---|
/openspec:proposal | Створює всі артефакти одразу (пропозицію, специфікації, дизайн, завдання) |
/openspec:apply | Реалізує зміну |
/openspec:archive | Архівує зміну |
Коли використовувати застарілі команди:
- Існуючі проекти, що використовують старий робочий процес
- Прості зміни, де не потрібне покрокове створення артефактів
- Надається перевага підходу "все або нічого"
Міграція на OPSX: Застарілі зміни можна продовжувати за допомогою команд OPSX. Структура артефактів сумісна.
Усунення несправностей
"Зміну не знайдено"
Команда не змогла визначити, над якою зміною працювати.
Рішення:
- Явно вкажіть назву зміни:
/opsx:apply add-dark-mode - Перевірте, чи існує папка зміни:
openspec list - Переконайтеся, що ви в правильній директорії проекту
"Артефакти не готові"
Усі артефакти або завершені, або заблоковані відсутніми залежностями.
Рішення:
- Запустіть
openspec status --change <назва>, щоб побачити, що блокує - Перевірте, чи існують необхідні артефакти
- Спочатку створіть відсутні артефакти-залежності
"Схему не знайдено"
Вказана схема не існує.
Рішення:
- Перелічіть доступні схеми:
openspec schemas - Перевірте написання назви схеми
- Створіть схему, якщо вона є користувацькою:
openspec schema init <назва>
Команди не розпізнаються
Інструмент ШІ не розпізнає команди OpenSpec.
Рішення:
- Переконайтеся, що OpenSpec ініціалізовано:
openspec init - Повторно згенеруйте навички:
openspec update - Перевірте, чи існує директорія
.claude/skills/(для Claude Code) - Перезапустіть свій інструмент ШІ, щоб він підхопив нові навички
Артефакти генеруються неналежним чином
ШІ створює неповні або неправильні артефакти.
Рішення:
- Додайте контекст проекту в
openspec/config.yaml - Додайте правила для окремих артефактів для конкретних вказівок
- Надайте більше деталей у описі зміни
- Використовуйте
/opsx:continueзамість/opsx:ffдля більшого контролю
Наступні кроки
- Робочі процеси - Поширені патерни та коли використовувати кожну команду
- CLI - Термінальні команди для керування та валідації
- Налаштування - Створення користувацьких схем та робочих процесів