OPSX Workflow
Відгуки вітаються у Discord.
Що це таке?
OPSX тепер є стандартним робочим процесом для OpenSpec.
Це гнучкий, ітераційний робочий процес для змін у OpenSpec. Більше ніяких жорстких фаз — лише дії, які ви можете виконувати будь-коли.
Чому це існує
Спадковий робочий процес OpenSpec працює, але він закритий для змін:
- Інструкції закодовані жорстко — вони заховані в коді на TypeScript, і ви не можете їх змінювати
- Все або нічого — одна велика команда створює всі артефакти відразу, ви не можете перевіряти окремі частини
- Фіксована структура — однаковий робочий процес для всіх, без можливості налаштування
- Чорний ящик — коли результат роботи ШІ поганий, ви не можете корегувати запити (промпти)
OPSX відкриває ці можливості. Тепер кожен може:
- Експериментувати з інструкціями — редагувати шаблон, перевіряти, чи працює ШІ краще
- Перевіряти детально — перевіряти інструкції для кожного артефакту окремо
- Налаштовувати робочі процеси — визначати власні артефакти та залежності між ними
- Швидко ітерувати — змінювати шаблон, негайно перевіряти результат, без необхідності перезбірки
Спадковий робочий процес: OPSX:
┌────────────────────────┐ ┌────────────────────────┐
│ Закодовані жорстко в пакеті │ │ schema.yaml │◄── Ви редагуєте це
│ (не можна змінити) │ │ templates/*.md │◄── Або це
│ ↓ │ │ ↓ │
│ Чекати нового релізу │ │ Миттєвий ефект │
│ ↓ │ │ ↓ │
│ Сподіватися, що краще │ │ Перевірте самостійно │
└────────────────────────┘ └────────────────────────┘Це для всіх:
- Команди — створюйте робочі процеси, які відповідають вашому реальному способу роботи
- Досвідчені користувачі — корегуйте промпти, щоб отримувати кращі результати від ШІ для вашого кодового базу
- Контриб'ютори OpenSpec — експериментуйте з новими підходами без необхідності випуску нових версій
Ми всі досі вивчаємо, що працює найкраще. OPSX дає нам можливість вчитися разом.
Досвід користувача
Проблема лінійних робочих процесів: Ви перебуваєте "на етапі планування", потім "на етапі реалізації", потім "завершили". Але реальна робота не відбувається так. Ви реалізуєте щось, розумієте, що ваш дизайн був помилковим, потрібно оновити специфікації, продовжити реалізацію. Лінійні етапи суперечать тому, як насправді відбувається робота.
Підхід OPSX:
- Дії, а не етапи — створюйте, реалізуйте, оновлюйте, архівуйте — виконуйте будь-яку з них у будь-який час
- Залежності — це можливості — вони показують, що можна зробити, а не що потрібно робити далі
proposal ──→ specs ──→ design ──→ tasks ──→ implementНалаштування
bash
# Переконайтеся, що у вас встановлено openspec — навички генеруються автоматично
openspec initЦя команда створює навички в .claude/skills/ (або аналогічній), які автоматично виявляються асистентами з написання коду на базі ШІ.
За замовчуванням OpenSpec використовує профіль робочого процесу core (propose, explore, apply, sync, archive). Якщо ви хочете використовувати розширені команди робочого процесу (new, continue, ff, verify, bulk-archive, onboard), налаштуйте їх за допомогою openspec config profile та застосуйте зміни командою openspec update.
Під час налаштування вам буде запропоновано створити конфігурацію проєкту (openspec/config.yaml). Це необов'язковий, але рекомендований крок.
Конфігурація проєкту
Конфігурація проєкту дозволяє встановлювати значення за замовчуванням та додавати контекст, специфічний для вашого проєкту, до всіх артефактів.
Створення конфігурації
Конфігурація створюється під час виконання openspec init, або вручную:
yaml
# openspec/config.yaml
schema: spec-driven
context: |
Технологічний стек: TypeScript, React, Node.js
Конвенції для API: RESTful, відповіді у форматі JSON
Тестування: Vitest для модульних тестів, Playwright для e2e-тестування
Стиль коду: ESLint з Prettier, строгий TypeScript
rules:
proposal:
- Додайте план відкату змін
- Визначте зацікавлені команди
specs:
- Використовуйте формат Given/When/Then для сценаріїв
design:
- Додайте діаграми послідовності для складних сценаріїв роботиПоля конфігурації
| Field | Type | Description |
|---|---|---|
schema | string | Базова схема для нових змін (наприклад, spec-driven) |
context | string | Контекст проєкту, який додається до інструкцій для всіх артефактів |
rules | object | Правила для окремого артефакту, ключом є ID артефакту |
Як це працює
Пріоритетність схеми (від найвищого до найнижчого):
- Прапорець CLI (
--schema <name>) - Метадані зміни (
.openspec.yamlв директорії зміни) - Конфігурація проєкту (
openspec/config.yaml) - Значення за замовчуванням (
spec-driven)
Додавання контексту:
- Контекст додається на початок інструкцій для кожного артефакту
- Загортається в теги
<context>...</context> - Допомагає ШІ зрозуміти конвенції вашого проєкту
Додавання правил:
- Правила додаються лише для відповідних артефактів
- Загортаються в теги
<rules>...</rules> - З'являються після контексту, перед шаблоном
ID артефактів за схемою
spec-driven (за замовчуванням):
proposal— Пропозиція зміниspecs— Специфікаціїdesign— Технічний дизайнtasks— Завдання з реалізації
Валідація конфігурації
- Невідомі ID артефактів в полі
rulesгенерують попередження - Назви схем перевіряються на відповідність доступним схемам
- Контекст має обмеження за розміром у 50 КБ
- Про невалідний YAML повідомляється з вказівкою номерів рядків
Усунення несправностей
"Невідомий ID артефакту в rules: X"
- Перевірте, що ID артефактів відповідають вашій схемі (див. список вище)
- Виконайте команду
openspec schemas --json, щоб переглянути ID артефактів для кожної схеми
Конфігурація не застосовується:
- Переконайтеся, що файл розташований за шляхом
openspec/config.yaml(не.yml) - Перевірте синтаксис YAML за допомогою валідатора
- Зміни в конфігурації застосовуються миттєво (перезапуск не потрібен)
Занадто великий контекст:
- Контекст має обмеження у 50 КБ
- Натомість стисніть інформацію або додайте посилання на зовнішню документацію
Команди
| Команда | Що робить |
|---|---|
/opsx:propose | Створює зміну та генерує планувальні артефакти в один крок (шлях за замовчуванням для швидкого старту) |
/opsx:explore | Допомагає продумати ідеї, дослідити проблеми, уточнити вимоги |
/opsx:new | Створює каркас нової зміни (розширений робочий процес) |
/opsx:continue | Створює наступний артефакт (розширений робочий процес) |
/opsx:ff | Швидко створює всі планувальні артефакти (розширений робочий процес) |
/opsx:apply | Реалізує завдання, оновлюючи артефакти за потреби |
/opsx:update | Оновлює планувальні артефакти зміни та підтримує їх узгодженість |
/opsx:verify | Перевіряє реалізацію на відповідність артефактам (розширений робочий процес) |
/opsx:sync | Синхронізує специфікації зі змінами з основною гілкою (робочий процес за замовчуванням, необов'язковий крок) |
/opsx:archive | Архівує зміну після завершення роботи над нею |
/opsx:bulk-archive | Архівує кілька завершених змін (розширений робочий процес) |
/opsx:onboard | Кероване проходження повного циклу роботи з зміною (розширений робочий процес) |
Використання
Дослідити ідею
/opsx:exploreПродумайте ідеї, дослідіть проблеми, порівняйте варіанти. Жодної структури не потрібно — просто партнер для мислення. Коли ідеї оформляться, перейдіть до /opsx:propose (за замовчуванням) або /opsx:new//opsx:ff (для розширеного робочого процесу).
Створити нову зміну
/opsx:proposeСтворює зміну та генерує планувальні артефакти, необхідні перед початком реалізації.
Якщо ви увімкнули розширені робочі процеси, замість цього можна використовувати:
text
/opsx:new # створює лише каркас
/opsx:continue # створює один артефакт за раз
/opsx:ff # створює всі планувальні артефакти відразуСтворити артефакти
/opsx:continueПоказує, які артефакти можна створити на основі залежностей, потім створює один артефакт. Використовуйте кілька разів поспіль, щоб послідовно формувати вашу зміну.
/opsx:ff add-dark-modeСтворює всі планувальні артефакти відразу. Використовуйте, коли у вас є чітке уявлення про те, що ви будуєте.
Реалізація (гнучка частина)
/opsx:applyПроходить по завданнях, відмічаючи їх як виконані по ходу роботи. Якщо ви працюєте з кількома змінами одночасно, ви можете виконати /opsx:apply <name>; в іншому випадку система визначить потрібну зміну з контексту розмови та запропонує вам вибрати, якщо не зможе визначити самостійно.
Оновлення зміни
/opsx:update add-dark-mode - we're storing the theme in a cookie nowОновлює існуючі планувальні артефакти зміни та підтримує їх узгодженість — в будь-якому напрямку (редагування дизайну може вплинути на пропозицію зміни). Працює лише з планувальними артефактами: ніколи не редагує код і не створює відсутні артефакти (для цього використовуйте /opsx:continue). Кожне редагування спочатку підтверджується з вами. Якщо зміна вже була реалізована, система рекомендує виконати /opsx:apply, щоб код відповідав оновленому плану. Якщо ваше редагування змінює мету зміни, краще створити нову зміну — див. розділ Коли оновлювати, а коли створити зміну з нуля.
Завершення роботи
/opsx:archive # Перемістити в архів після завершення (запитує синхронізацію специфікацій, якщо потрібно)Коли оновлювати існуючу зміну, а коли створити нову
Ви завжди можете редагувати пропозицію зміни або специфікації перед початком реалізації. Але коли покращення перетворюються на "зовсім іншу роботу"?
Що описує пропозиція зміни
Пропозиція зміни визначає три речі:
- Мета — Яку проблему ви вирішуєте?
- Обсяг — Що входить/не входить в межі роботи?
- Підхід — Як ви плануєте це вирішити?
Питання полягає в тому: що саме змінилося, і наскільки сильно?
Оновлюйте існуючу зміну, якщо:
Та сама мета, уточнена реалізація
- Ви виявили крайові випадки, про які не подумали раніше
- Потрібно скоригувати підхід, але мета залишається незмінною
- Під час реалізації виявилося, що дизайн був трохи невірним
Обсяг зменшується
- Ви розумієте, що повний обсяг занадто великий, хочете спочатку випустити мінімально життєздатну версію (MVP)
- "Додати темну тему" → "Додати перемикач темної теми (системні налаштування в версії 2)"
Корекції на основі отриманого досвіду
- Кодова база структурована не так, як ви очікували
- Залежність не працює так, як очікувалося
- "Використовувати CSS-змінні" → "Замість цього використовувати префікс
dark:від Tailwind"
Створюйте нову зміну, якщо:
Мета змінилася кардинально
- Сама проблема тепер інша
- "Додати темну тему" → "Додати повноцінну систему тем з кастомними кольорами, шрифтами, відступами"
Обсяг зріс надмірно
- Зміна настільки зросла, що це вже зовсім інша робота
- Оригінальна пропозиція після оновлень буде невпізнаваною
- "Виправити помилку входу" → "Переписати систему автентифікації"
Оригінальну зміну можна завершити
- Оригінальну зміну можна відмітити як "виконану"
- Нова робота є самостійною, а не уточненням існуючої
- Завершити "Додати темну тему (MVP)" → Архівувати → Створити нову зміну "Розширити темну тему"
Евристичні правила
┌─────────────────────────────────────┐
│ Це та сама робота? │
└──────────────┬──────────────────────┘
│
┌──────────────────┼──────────────────┐
│ │ │
▼ ▼ ▼
Та сама мета? >50% перекриття? Чи можна завершити
Та сама проблема? Такий самий обсяг? оригінал без
│ │ цих змін?
│ │ │
┌────────┴────────┐ ┌──────┴──────┐ ┌───────┴───────┐
│ │ │ │ │ │
ТАК НІ ТАК НІ НІ ТАК
│ │ │ │ │ │
▼ ▼ ▼ ▼ ▼ ▼
ОНОВИТИ НОВА ОНОВИТИ НОВА ОНОВИТИ НОВА| Тест | Оновити існуючу | Створити нову зміну |
|---|---|---|
| Ідентичність | "Те саме, уточнене" | "Зовсім інша робота" |
| Перекриття обсягу | >50% перекриття | <50% перекриття |
| Завершеність | Неможливо відмітити як "виконану" без змін | Можна завершити оригінал, нова робота є самостійною |
| Історія змін | Ланцюжок оновлень описує послідовну історію | Правки більше заплутають, ніж прояснять |
Принцип
Оновлення зберігає контекст. Нова зміна забезпечує ясність.
Вибирайте оновлення, коли історія ваших роздумів є цінною. Вибирайте нову зміну, коли початок з нуля буде яснішим, ніж внесення правок.
Порівняйте це з гілками в git:
- Продовжуйте робити коміти, поки працюєте над однією функцією
- Створюйте нову гілку, коли це дійсно нова робота
- Іноді злийте частково реалізовану функцію та почніть з нуля для другого етапу
В чому різниця
Спадковий варіант (/openspec:proposal) | OPSX (/opsx:*) | |
|---|---|---|
| Структура | Один великий документ з пропозицією зміни | Окремі артефакти з залежностями між ними |
| Робочий процес | Лінійні етапи: планування → реалізація → архівування | Гнучкі дії — виконуйте будь-яку в будь-який час |
| Ітерація | Незручно повертатися назад | Оновлюйте артефакти по мірі отримання нового досвіду |
| Можливості налаштування | Фіксована структура | На основі схем (ви можете визначати власні артефакти) |
Ключова ідея: робота не є лінійною. OPSX припиняє притворюватися, що вона лінійна.
Поглиблене вивчення архітектури
Цей розділ пояснює, як OPSX працює під капотом та як він порівнюється з застарілим робочим процесом. Приклади в цьому розділі використовують розширений набір команд (new, continue тощо); користувачі стандартного core можуть відобразити той самий потік як propose → apply → sync → archive.
Філософія: Фази vs Дії
┌─────────────────────────────────────────────────────────────────────────────┐
│ ЗАСТАРІЛИЙ РОБОЧИЙ ПРОЦЕС │
│ (Закріплений за фазами, все або нічого) │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │
│ │ ПЛАНУВАННЯ │ ───► │ РЕАЛІЗАЦІЯ │ ───► │ АРХІВАЦІЯ │ │
│ │ ФАЗА │ │ ФАЗА │ │ ФАЗА │ │
│ └──────────────┘ └──────────────┘ └──────────────┘ │
│ │ │ │ │
│ ▼ ▼ ▼ │
│ /openspec:proposal /openspec:apply /openspec:archive │
│ │
│ • Створює ВСІ артефакти одночасно │
│ • Неможливо повернутися для оновлення специфікацій під час реалізації │
│ • Фазові ворота забезпечують лінійний прогрес │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────────────────────┐
│ РОБОЧИЙ ПРОЦЕС OPSX │
│ (Гнучкі дії, ітеративний) │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ ┌────────────────────────────────────────────┐ │
│ │ ДІЇ (не фази) │ │
│ │ │ │
│ │ new ◄──► continue ◄──► apply ◄──► archive │ │
│ │ │ │ │ │ │ │
│ │ └──────────┴───────────┴───────────┘ │ │
│ │ будь-який порядок │ │
│ └────────────────────────────────────────────┘ │
│ │
│ • Створюйте артефакти по одному АБО прискорено │
│ • Оновлюйте специфікації/дизайн/завдання під час реалізації │
│ • Залежності забезпечують прогрес, фази не існують │
│ │
└─────────────────────────────────────────────────────────────────────────────┘Архітектура компонентів
Застарілий робочий процес використовує жорстко закодовані шаблони в TypeScript:
┌─────────────────────────────────────────────────────────────────────────────┐
│ КОМПОНЕНТИ ЗАСТАРІЛОГО РОБОЧОГО ПРОЦЕСУ │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ Жорстко закодовані шаблони (рядки TypeScript) │
│ │ │
│ ▼ │
│ Конфігуратори/адаптери для конкретних інструментів │
│ │ │
│ ▼ │
│ Згенеровані файли команд (.claude/commands/openspec/*.md) │
│ │
│ • Фіксована структура, немає обізнаності про артефакти │
│ • Зміна потребує модифікації коду + перезбірки │
│ │
└─────────────────────────────────────────────────────────────────────────────┘OPSX використовує зовнішні схеми та рушій графа залежностей:
┌─────────────────────────────────────────────────────────────────────────────┐
│ КОМПОНЕНТИ OPSX │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ Визначення схем (YAML) │
│ ┌─────────────────────────────────────────────────────────────────────┐ │
│ │ name: spec-driven │ │
│ │ artifacts: │ │
│ │ - id: proposal │ │
│ │ generates: proposal.md │ │
│ │ requires: [] ◄── Залежності │ │
│ │ - id: specs │ │
│ │ generates: specs/**/*.md ◄── Glob-шаблони │ │
│ │ requires: [proposal] ◄── Увімкнюється після proposal │ │
│ └─────────────────────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ Рушій графа артефактів │
│ ┌─────────────────────────────────────────────────────────────────────┐ │
│ │ • Топологічне сортування (впорядкування залежностей) │ │
│ │ • Визначення стану (існування у файловій системі) │ │
│ │ • Розширена генерація інструкцій (шаблони + контекст) │ │
│ └─────────────────────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ Файли навичок (.claude/skills/openspec-*/SKILL.md) │
│ │
│ • Сумісні з різними редакторами (Claude Code, Cursor, Windsurf) │
│ • Навички запитують CLI для структурованих даних │
│ • Повністю налаштовувані через файли схем │
│ │
└─────────────────────────────────────────────────────────────────────────────┘Модель графа залежностей
Артефакти утворюють орієнтований ациклічний граф (DAG). Залежності є увімкнювачами, а не воротами:
proposal
(кореневий вузол)
│
┌─────────────┴─────────────┐
│ │
▼ ▼
specs design
(потребує: (потребує:
proposal) proposal)
│ │
└─────────────┬─────────────┘
│
▼
tasks
(потребує:
specs, design)
│
▼
┌──────────────┐
│ ФАЗА APPLY │
│ (потребує: │
│ tasks) │
└──────────────┘Переходи станів:
BLOCKED ────────────────► READY ────────────────► DONE
│ │ │
Відсутні Всі залежності Файл існує
залежності у стані DONE у файловій системіПотік інформації
Застарілий робочий процес — агент отримує статичні інструкції:
Користувач: "/openspec:proposal"
│
▼
┌─────────────────────────────────────────┐
│ Статичні інструкції: │
│ • Створити proposal.md │
│ • Створити tasks.md │
│ • Створити design.md │
│ • Створити specs/<capability>/spec.md │
│ │
│ Немає обізнаності про те, що існує або │
│ залежності між артефактами │
└─────────────────────────────────────────┘
│
▼
Агент створює ВСІ артефакти за один разOPSX — агент запитує розширений контекст:
Користувач: "/opsx:continue"
│
▼
┌──────────────────────────────────────────────────────────────────────────┐
│ Крок 1: Запит поточного стану │
│ ┌────────────────────────────────────────────────────────────────────┐ │
│ │ $ openspec status --change "add-auth" --json │ │
│ │ │ │
│ │ { │ │
│ │ "artifacts": [ │ │
│ │ {"id": "proposal", "status": "done"}, │ │
│ │ {"id": "specs", "status": "ready"}, ◄── Перший готовий │ │
│ │ {"id": "design", "status": "ready"}, │ │
│ │ {"id": "tasks", "status": "blocked", "missingDeps": ["specs"]}│ │
│ │ ] │ │
│ │ } │ │
│ └────────────────────────────────────────────────────────────────────┘ │
│ │
│ Крок 2: Отримання розширених інструкцій для готового артефакту │
│ ┌────────────────────────────────────────────────────────────────────┐ │
│ │ $ openspec instructions specs --change "add-auth" --json │ │
│ │ │ │
│ │ { │ │
│ │ "template": "# Specification\n\n## ADDED Requirements...", │ │
│ │ "dependencies": [{"id": "proposal", "path": "...", "done": true}│ │
│ │ "unlocks": ["tasks"] │ │
│ │ } │ │
│ └────────────────────────────────────────────────────────────────────┘ │
│ │
│ Крок 3: Читання залежностей → Створення ОДНОГО артефакту → Показати, │
│ що розблоковано │
└──────────────────────────────────────────────────────────────────────────┘Модель ітерацій
Застарілий робочий процес — незручно для ітерацій:
┌─────────┐ ┌─────────┐ ┌─────────┐
│/proposal│ ──► │ /apply │ ──► │/archive │
└─────────┘ └─────────┘ └─────────┘
│ │
│ ├── "Чекай, у дизайні помилка"
│ │
│ ├── Варіанти:
│ │ • Редагувати файли вручну (зламає контекст)
│ │ • Відмовитися від цього і розпочати з нуля
│ │ • Продовжити роботу і виправити пізніше
│ │
│ └── Немає офіційного механізму для повернення назад
│
└── Створює ВСІ артефакти одразуOPSX — природна ітерація:
/opsx:new ───► /opsx:continue ───► /opsx:apply ───► /opsx:archive
│ │ │
│ │ ├── "У дизайні помилка"
│ │ │
│ │ ▼
│ │ Просто відредагуй design.md
│ │ і продовжуй!
│ │ │
│ │ ▼
│ │ /opsx:apply продовжує
│ │ з місця, на якому ви зупинилися
│ │
│ └── Створює ОДИН артефакт, показує, що розблоковано
│
└── Створює каркас зміни, чекає на подальші вказівкиВласні схеми
Створюйте власні робочі процеси за допомогою команд керування схемами:
bash
# Створити нову схему з нуля (інтерактивно)
openspec schema init my-workflow
# Або форкнути існуючу схему як відправну точку
openspec schema fork spec-driven my-workflow
# Валідувати структуру вашої схеми
openspec schema validate my-workflow
# Перевірити, звідки завантажується схема (корисно для налагодження)
openspec schema which my-workflowСхеми зберігаються в openspec/schemas/ (локально для проєкту, під керуванням версій) або ~/.local/share/openspec/schemas/ (глобально для користувача).
Структура схеми:
openspec/schemas/research-first/
├── schema.yaml
└── templates/
├── research.md
├── proposal.md
└── tasks.mdПриклад schema.yaml:
yaml
name: research-first
artifacts:
- id: research # Додається перед proposal
generates: research.md
requires: []
- id: proposal
generates: proposal.md
requires: [research] # Тепер залежить від research
- id: tasks
generates: tasks.md
requires: [proposal]Граф залежностей:
research ──► proposal ──► tasksПідсумок
| Аспект | Стара версія | OPSX |
|---|---|---|
| Шаблони | Жорстко закодовані на TypeScript | Зовнішні YAML + Markdown |
| Залежності | Відсутні (всі артефакти створюються одразу) | DAG із топологічним сортуванням |
| Стан | Фазова ментальна модель | Наявність у файловій системі |
| Кастомізація | Редагувати вихідний код, перезібрати | Створити schema.yaml |
| Ітерація | Фазове блокування | Гнучка, можна редагувати будь-що |
| Підтримка редакторів | Конфігуратори/адаптери для конкретних інструментів | Єдина директорія skills |
Схеми
Схеми визначають перелік існуючих артефактів та їх залежності. Наразі доступні:
- spec-driven (за замовчуванням): proposal → specs → design → tasks
bash
# Перелічити доступні схеми
openspec schemas
# Переглянути всі схеми з джерелами їх завантаження
openspec schema which --all
# Створити нову схему в інтерактивному режимі
openspec schema init my-workflow
# Форкнути існуючу схему для кастомізації
openspec schema fork spec-driven my-workflow
# Валідувати структуру схеми перед використанням
openspec schema validate my-workflowПоради
- Використовуйте
/opsx:explore, щоб обдумати ідею перед фіксацією зміни /opsx:ff, якщо ви точно знаєте, що хочете,/opsx:continue— під час дослідження ідей- Під час використання
/opsx:apply, якщо щось пішло не так — виправте артефакт, потім продовжуйте - Задачі відстежують прогрес за допомогою прапореців у
tasks.md - Перевіряйте статус у будь-який час:
openspec status --change "name"
Зворотний зв'язок
Це ще не відполірований інструмент. І це навмисно — ми вивчаємо, що працює краще.
Знайшли помилку? Маєте ідеї? Приєднуйтесь до нас на Discord або відкрийте issue на GitHub.