Робочий процес зі специфікацією
Визначайте вимоги до того, як почнете писати код.
Ласкаво просимо. Це центр усього, що стосується OpenSpec.
OpenSpec допомагає вам і вашому AI-асистенту з кодуванням узгодити, що саме будувати, до того як буде написано хоча б рядок коду. Ви описуєте зміну, AI створює короткий чернетковий специфікаційний документ і список завдань, ви обидва переглядаєте один і той самий план, а потім починається робота. Жодного більше випадку, коли ви на півдорозі дізнаєтеся, що AI побудував не те.
Якщо ви не будете читати нічого іншого, прочитайте ці дві сторінки:
/opsx:propose (підказка: у чаті з AI, а не в терміналі). Це плутає майже кожного хоча б раз.Друга сторінка важливіша, ніж здається. OpenSpec має дві частини: командний рядок, який ви запускаєте в терміналі, та slash-команди, які ви даєте своєму AI-асистенту. Розуміння того, що є чим, економить вам найпоширеніший момент плутанини.
Найкраща звичка, яку варто виробити першою: коли ви не впевнені, що будувати, починайте з
/opsx:explore. Це безризиковий партнер для роздумів, який читає ваш код, зважує варіанти та перетворює розмиту ідею на конкретний план до того, як існує будь-який артефакт чи код. Гід Спочатку дослідження робить цей випадок.
Я новачок. Почніть з Початок роботи, потім перегляньте Основні концепції. Коли щось здається незрозумілим, Часті запитання та Глосарій поруч.
У мене є проблема, але немає плану. Це найпоширеніший випадок, і він має спеціальну відповідь: Спочатку дослідження. Використовуйте /opsx:explore, щоб обміркувати це з AI, перш ніж щось вирішувати.
У мене велика наявна кодова база. Вам не потрібно документувати все. Використання OpenSpec у наявному проєкті показує, як почати роботу з реальним brownfield-кодом, не намагаючись перекрити все одразу.
Я просто хочу, щоб це працювало. Встановіть, запустіть openspec init, потім прочитайте Як працюють команди, щоб ваша перша slash-команда потрапила у правильне місце. Або доручіть налаштування своєму асистенту за допомогою промпту для AI-встановлення.
Я вчуся на прикладах. Сторінка Приклади та рецепти розглядає реальні зміни від початку до кінця: невелика функція, виправлення помилки, рефакторинг, дослідження.
AI щойно створив план — що далі? Прочитайте його. Перегляд зміни показує двоххвилинну перевірку, яка ловить хибний поворот, поки це ще дешево, а Написання якісних специфікацій розповідає, з чого складається план, гідний схвалення.
Я працюю в команді. OpenSpec у команді показує, як зміна пов'язана з гілкою та pull request, і як колеги переглядають план до коду.
Я переходжу зі старої робочої процедури. Гід по міграції пояснює, що змінилося і чому, і гарантує, що ваша наявна робота в безпеці.
Я хочу адаптувати під процес моєї команди. Налаштування охоплює конфігурацію проєкту, користувацькі схеми та спільний контекст.
Щось зламалося. Вирішення проблем збирає помилки, з якими люди дійсно стикаються, разом із виправленнями.
| Документ | Що ви отримаєте |
|---|---|
| Початок роботи | Встановлення, ініціалізація та виконання першої зміни від початку до кінця |
| Спочатку дослідження | Використання /opsx:explore для обміркування ідеї до того, як ви щось вирішите |
| Як працюють команди | Де виконуються slash-команди, що означає "інтерактивний режим", термінал проти чату |
| Основні концепції | Уся ментальна модель на одній сторінці: специфікації, зміни, дельти, архів |
| Встановлення | npm, pnpm, yarn, bun, Nix, промпт, який передає налаштування вашому AI-асистенту, та як перевірити, що все спрацювало |
| Документ | Що ви отримаєте |
|---|---|
| Робочі процеси | Поширені патерни та коли використовувати кожну команду |
| Приклади та рецепти | Повні розбори реальних змін, готові до копіювання |
| Написання якісних специфікацій | Як виглядає сильна вимога та сценарій, і як правильно визначити масштаб зміни |
| Перегляд зміни | Двоххвилинна перевірка чернеткового плану до того, як буде написано код |
| OpenSpec у команді | Як зміни пов'язані з гілками, pull request та переглядом |
| Використання OpenSpec у наявному проєкті | Впровадження OpenSpec у великій brownfield-кодовій базі |
| Редагування та ітерації зміни | Оновлення артефактів, повернення назад, узгодження ручних правок |
| Команди | Довідник усіх slash-команд /opsx:* |
| CLI | Довідник усіх команд openspec у терміналі |
| Документ | Що ви отримаєте |
|---|---|
| Концепції | Розгорнуте пояснення специфікацій, змін, артефактів, схем та архіву |
| Робочий процес OPSX | Чому робочий процес є гнучким, а не прив'язаним до фаз, плюс детальний огляд архітектури |
| Глосарій | Визначення кожного терміна в одному місці |
| Документ | Що ви отримаєте |
|---|---|
| Налаштування | Конфігурація проєкту, користувацькі схеми, спільний контекст |
| Багатомовність | Генерація артефактів мовами, відмінними від англійської |
| Підтримувані інструменти | 30+ AI-інструментів, з якими інтегрується OpenSpec, та куди потрапляють файли |
| Виставка спільноти | Проєкти та ресурсi, створені з OpenSpec і для OpenSpec |
| Документ | Що ви отримаєте |
|---|---|
| Часті запитання | Швидкі відповіді на найпоширеніші запитання |
| Вирішення проблем | Конкретні виправлення для конкретних збоїв |
| Гід по міграції | Перехід зі старої робочої процедури на OPSX |
| Документ | Що ви отримаєте |
|---|---|
| Сховища: гід користувача | Планування у власному репозиторії, коли ваша робота охоплює кілька репозиторіїв або команд |
| Договір агента | Машиночитні CLI-інтерфейси, якими керують агенти |
1. Встановлення npm install -g @fission-ai/openspec@latest
2. Ініціалізація cd your-project && openspec init
3. Дослідження (у вашому AI-чаті) /opsx:explore ← необов'язково, але чудова звичка
4. Пропозиція (у вашому AI-чаті) /opsx:propose add-dark-mode
5. Побудова (у вашому AI-чаті) /opsx:apply
6. Архівування (у вашому AI-чаті) /opsx:archiveКроки 1 і 2 відбуваються у вашому терміналі. Решта — у чаті вашого AI-асистента. Цей розподіл — єдина річ, яку варто запам'ятати, і Як працюють команди пояснює, чому саме так. Крок 3 необов'язковий, але починати з /opsx:explore, коли ви не впевнені, — звичка, яка найцінніша.
openspec feedback "ваше повідомлення" надсилає зворотний зв'язок прямо з терміналу (відкриває GitHub issue).Знайшли щось у цій документації, що неправильне, застаріле або незрозуміле? Це баг. Відкрийте issue або PR. Покращення документації — один із найцінніших внесків, які ви можете зробити.