OpenSpec
OpenSpec (Fission-AI) строит спеко-ориентированную разработку не вокруг фичи, а вокруг изменения с жизненным циклом propose → review → apply → archive. Ключевая идея — разделить «что уже есть» и «что меняется»: постоянные спецификации системы обновляются дельтами, как схема базы данных — миграциями.
OpenSpec — агент-агностичный тулкит: слэш-команды работают в Claude Code, Cursor, GitHub Copilot и ещё двух десятках ассистентов.
Установка
CLI распространяется через npm (нужен Node.js ≥ 20.19):
npm install -g @fission-ai/openspec@latest
openspec init
openspec init создаёт каталог openspec/ и регистрирует слэш-команды с
префиксом /opsx:; openspec update обновляет инструкции для агентов после
апгрейда.
Рабочий процесс
Набор команд зависит от выбранного профиля (openspec config profile).
Базовый профиль — три команды по циклу изменения:
/opsx:explore— режим размышлений до всяких артефактов: агент читает код и взвешивает варианты, ничего не меняя./opsx:propose <идея>— формальное предложение изменения: создаётся связка артефактов (см. ниже). Ревью связки — контрольная точка до первой строки кода./opsx:apply— реализация по чек-листу задач.
Расширенный профиль добавляет команды для длинных работ: /opsx:new,
/opsx:continue, /opsx:ff (fast-forward), /opsx:verify (сверка
реализации с артефактами), /opsx:bulk-archive, /opsx:onboard
(развёртывание OpenSpec на существующем проекте).
После мержа изменение архивируется: его дельты вливаются в постоянные спецификации, а само оно переезжает в архив — история решений остаётся в репозитории.
Артефакты
Всё живёт в openspec/, в двух зонах:
| Путь | Что лежит |
|---|---|
openspec/specs/ |
Постоянные спецификации — актуальная модель того, что уже построено |
openspec/changes/<изменение>/proposal.md |
Зачем меняем |
openspec/changes/<изменение>/specs/ |
Дельты требований с конкретными сценариями |
openspec/changes/<изменение>/design.md |
Технический подход |
openspec/changes/<изменение>/tasks.md |
Чек-лист реализации |
openspec/changes/archive/ |
Завершённые изменения |
Чем отличается
- Спецификация — не одноразовый документ фичи, а постоянно актуальная модель системы: в любой момент видно, что система обязана делать сейчас.
- Дельты вместо переписывания: изменение описывает разницу с текущими требованиями, а не всю систему заново.
- Явная ставка на браунфилд: авторы описывают процесс как «fluid, not rigid; iterative, not waterfall» — конвейер задуман под живую кодовую базу, а не только под гринфилд.
- Командная работа: спецификации принадлежат команде, поддерживаются общий дашборд, координация между репозиториями и интеграция по MCP.
Когда выбирать
OpenSpec — лучший вариант, когда работа идёт в существующей системе и главная ценность — накапливающаяся, всегда актуальная модель требований. Если же нужен максимально простой линейный конвейер для новых фич, ближе более линейные тулкиты вроде GitHub Spec Kit (см. полезные ссылки).