Инструменты вроде OpenSpec и GitHub Spec Kit решают одну практическую задачу: превратить работу с ИИ-агентом из череды случайных подсказок в управляемый процесс, где требования, план и задачи живут в репозитории как обычные файлы. Для аналитика это означает смену роли: вы не «просите код», а формулируете спецификацию, которую агент исполняет по шагам. Ниже — обзор обоих инструментов, их команд и различий, а также ориентиры, когда какой брать.
1. Что общего и зачем это аналитику
Оба инструмента реализуют подход spec-driven development (SDD): сначала фиксируется спецификация, затем на её основе строится план и список задач, и только потом агент пишет код. Спецификация становится источником истины, а не побочным артефактом переписки с агентом.
Для аналитика это прямое продолжение привычной работы со спецификациями требований (см. 02.03.03 Спецификация требований (SRS, Use Case, User Story)): требования описываются в Markdown, проверяются через сценарии, а не остаются в голове автора. Дополнительно инструменты опираются на приёмы формулирования подсказок (см. 11.03 Промпт-инжиниринг для аналитика) и на интеграцию ИИ с рабочими инструментами команды (см. 11.05 Интеграция LLM с инструментами аналитика).
Ключевая идея: задача агенту ставится не сообщением в чате, а артефактом в репозитории. Агент читает спецификацию и следует ей.
2. OpenSpec: обзор
OpenSpec (проект Fission-AI) распространяется как пакет @fission-ai/openspec под лицензией MIT. Требуется Node.js 20.19+.
Установка:
npm install -g @fission-ai/openspec@latest- либо
brew install openspec
Работа в проекте:
openspec init— инициализация в текущем репозитории;openspec update— обновление подсказок для агента;openspec config profile— переключение профиля команд.
2.1. Команды в чате агента
Канонические имена команд:
| Команда | Назначение |
|---|---|
/opsx:explore | Исследование задачи до формулировки предложения |
/opsx:propose | Создание предложения об изменении |
/opsx:apply | Применение изменения |
/opsx:archive | Архивирование завершённого изменения |
Команда propose создаёт каталог openspec/changes/<name>/ со структурой:
proposal.md— суть предложения;specs/— спецификации;design.md— проектные решения;tasks.md— список задач.
Спецификация — обычный Markdown с блоками Requirement и Scenario в формате WHEN/THEN. Это тот же принцип проверяемости, что и в классических сценариях использования.
2.2. Расширенный профиль
Помимо базовых команд есть расширенный профиль: /opsx:new, /opsx:continue, /opsx:ff, /opsx:verify, /opsx:bulk-archive, /opsx:onboard. Он включается через openspec config profile и затем openspec update.
В некоторых средах имя команды отличается: например, в Cursor команда может называться /opsx-propose. Точную форму печатает openspec init — ориентируйтесь на его вывод.
2.3. Stores (beta)
Отдельная возможность — Stores: вынесение планов в отдельный репозиторий, чтобы один набор планов обслуживал несколько репозиториев кода. Функциональность помечена как beta.
3. GitHub Spec Kit: обзор
GitHub Spec Kit использует CLI с именем specify. Установка:
uv tool install specify-cli— требуются Python 3.11+ иuv.
Инициализация проекта:
specify init my-project --integration copilot
Интеграции включают Copilot, Cursor и другие; вариант generic — запасной, если нужной интеграции нет.
3.1. Навыки в чате агента
Важно: в Spec Kit это навыки (skills) в чате агента, а не команды терминала.
| Навык | Когда применяется |
|---|---|
/speckit-constitution | Один раз на проект |
/speckit-specify | На каждую фичу |
/speckit-plan | На каждую фичу |
/speckit-tasks | На каждую фичу |
/speckit-implement | На каждую фичу |
/speckit-converge | На каждую фичу |
Цикл работы: constitution задаётся один раз, затем для каждой фичи повторяется последовательность specify → plan → tasks → implement → converge. Пары implement → converge повторяют до тех пор, пока отчёт не станет Converged.
3.2. Расширения
Дополнительно можно подключать расширения:
specify extension add bug— цикл assess → fix → test, артефакты складываются в.specify/bugs/;specify extension add assess— цикл intake → research → define → shape → decide, артефакты в.specify/assessments/.
SDD входит в ядро инструмента, а исправление дефектов (bug fixing) и оценка идей (idea assessment) — это отдельные точки входа, а не обязательные фазы основного цикла.
4. Сравнение
| Критерий | OpenSpec | GitHub Spec Kit |
|---|---|---|
| CLI | openspec | specify |
| Установка | npm install -g @fission-ai/openspec@latest или brew install openspec | uv tool install specify-cli (Python 3.11+, uv) |
| Инициализация | openspec init | specify init my-project --integration copilot |
| Форма команд | Команды в чате агента (/opsx:*) | Навыки в чате агента (/speckit-*) |
| Базовая единица | Изменение в openspec/changes/<name>/ | Фича в цикле specify → plan → tasks → implement → converge |
| Спецификация | Markdown, Requirement и Scenario (WHEN/THEN) | Формируется навыками specify и plan |
| Профили/расширения | Расширенный профиль через openspec config profile; Stores (beta) | Расширения bug и assess через specify extension add |
| Лицензия | MIT | — (в заметках не указана) |
Принципиальные отличия:
- Модель процесса. OpenSpec строится вокруг отдельного «изменения» с фиксированным набором файлов (
proposal.md,specs/,design.md,tasks.md). Spec Kit строится вокруг повторяемого цикла по фиче с явной фазой конституции проекта. - Точка входа. В OpenSpec основной вход —
/opsx:propose; в Spec Kit —/speckit-constitutionодин раз, затем/speckit-specifyна каждую фичу. - Мультирепозиторность. OpenSpec предлагает Stores (beta) для планов, общих для нескольких репозиториев кода. В Spec Kit аналогичной возможности в заметках нет.
- Дополнительные сценарии. В Spec Kit исправление дефектов и оценка идей вынесены в отдельные расширения; в OpenSpec аналогичные роли выполняют команды расширенного профиля.
5. Когда какой инструмент брать аналитику
Ориентиры выбора:
- Нужен лёгкий старт и понятная структура артефактов — OpenSpec:
openspec init, затем/opsx:propose, и у вас на рукахproposal.md,specs/,design.md,tasks.md. - Работаете в экосистеме GitHub и Copilot — Spec Kit:
specify init ... --integration copilot, затем цикл навыков. - Планы должны обслуживать несколько репозиториев кода — смотрите на Stores в OpenSpec (учитывая статус beta).
- Нужны отдельные формализованные входы для дефектов и идей — расширения
bugиassessв Spec Kit. - Команда уже стандартизировала «конституцию» проекта — Spec Kit с
/speckit-constitutionдаёт явное место для этих правил.
В обоих случаях задача аналитика смещается к качеству спецификации: чем точнее сформулированы требования и сценарии, тем предсказуемее результат работы агента. Сам подход разобран в 11.10 Spec-Driven Development — спецификация как источник работы ИИ.