OpenSpec

Команды и возможности OpenSpec 1.16.0 проверены 31 октября 2026 года.

OpenSpec от Fission-AI организует SDD вокруг изменения с этапами propose, review, apply и archive. Постоянные спецификации описывают систему, а дельты фиксируют предлагаемые изменения требований.

OpenSpec поддерживает разные кодинг-агенты и ассистенты, включая Claude Code, Codex, Cursor и GitHub Copilot.

Установка

Для установки через npm нужен Node.js ≥22.12.0. Отдельный бинарный CLI не требует Node.js; выберите способ установки в официальном руководстве. Ниже показан поддерживаемый вариант через npm.

npm install -g @fission-ai/openspec@latest
openspec init

openspec init создаёт каталог openspec/ и регистрирует слэш-команды с префиксом /opsx:; openspec update обновляет инструкции для агентов после апгрейда.

Рабочий процесс

Набор команд зависит от профиля. Выберите его через openspec config profile, затем выполните openspec update в проекте, чтобы применить выбор к инструкциям агента. Базовый рабочий процесс проходит следующие шаги.

  1. /opsx:explore помогает исследовать код и сравнить варианты до подготовки артефактов.
  2. /opsx:propose <идея> создаёт пакет предложения, который вы проверяете до реализации.
  3. /opsx:apply выполняет задачи из чек-листа.
  4. /opsx:archive предлагает синхронизировать дельты с постоянными спецификациями, если это ещё не сделано, и переносит изменение в архив.

Если требования меняются после подготовки предложения, /opsx:update обновляет плановые артефакты. /opsx:sync переносит дельты в постоянные спецификации; синхронизация также доступна при архивировании.

Расширенный профиль включает /opsx:new, /opsx:continue, /opsx:ff, /opsx:verify, /opsx:bulk-archive и /opsx:onboard. Они поддерживают поэтапную подготовку, проверку и архивирование больших изменений.

При завершении изменения выполните /opsx:archive и подтвердите предложенную синхронизацию дельт. Если спецификации уже обновлены через /opsx:sync, повторная синхронизация не нужна. Архивирование сохраняет артефакты изменения; порядок относительно мержа команда выбирает в своём процессе.

Схема показывает путь одного изменения от предложения до архива.

/opsx:proposeвы проверили · /opsx:applyтребования изменились ·/opsx:update/opsx:sync/opsx:archive ссинхронизацией/opsx:archiveпредложениереализациядельта впостояннойспецификациив архиведельта попадает в постоянную спецификацию при синхронизации
/opsx:proposeвы проверили · /opsx:applyтребования изменились ·/opsx:update/opsx:sync/opsx:archive ссинхронизацией/opsx:archiveпредложениереализациядельта впостояннойспецификациив архиведельта попадает в постоянную спецификацию при синхронизации

Пока изменение не синхронизировано, принятые требования живут в дельте внутри пакета, а постоянная спецификация описывает систему как есть. Синхронизация выполняется отдельно или при архивировании, а архив хранит объяснение и историю изменения.

Синтаксис зависит от агента. Codex может показывать $openspec-propose, а Cursor и GitHub Copilot используют форму /opsx-propose. Точный синтаксис выбранного инструмента печатает openspec init.

Артефакты

Каталог openspec/ разделяет постоянные спецификации и пакеты изменений.

Путь Что лежит
openspec/specs/ Постоянные спецификации — актуальная модель того, что уже построено
openspec/changes/\<изменение>/proposal.md Зачем меняем
openspec/changes/\<изменение>/specs/ Дельты требований с конкретными сценариями
openspec/changes/\<изменение>/design.md Технический подход
openspec/changes/\<изменение>/tasks.md Чек-лист реализации
openspec/changes/archive/ Завершённые изменения

Пример изменения требования

В сервисе доставки событий вебхук отключается после пяти неудач подряд. Постоянная спецификация в openspec/specs/webhooks/spec.md содержит это правило.

### Requirement: Delivery failure cutoff
Система SHALL отключать вебхук после пяти неудачных попыток подряд.

#### Scenario: Failed deliveries reach cutoff
- **WHEN** пятая подряд попытка доставки завершается неудачей
- **THEN** вебхук отключается

Команда согласовала другой порог для временно недоступных получателей. В пакете изменения агент создаёт дельту в openspec/changes/raise-cutoff/specs/webhooks/spec.md. Для изменяемого требования он сохраняет заголовок и приводит новое требование со сценарием целиком.

## MODIFIED Requirements

### Requirement: Delivery failure cutoff
Система SHALL отключать вебхук после десяти неудачных попыток подряд.

#### Scenario: Failed deliveries reach cutoff
- **WHEN** десятая подряд попытка доставки завершается неудачей
- **THEN** вебхук отключается

В этом примере MODIFIED Requirements обозначает замену существующего требования. После реализации и проверки команда подтверждает sync при /opsx:archive. В постоянном spec.md требование Delivery failure cutoff теперь содержит порог десять и соответствующий сценарий; маркер MODIFIED Requirements остаётся частью дельты в архиве. Если предложение отклонено, постоянное правило с порогом пять не меняется. Формат разделов и сценариев описан в документации OpenSpec.

Чем отличается

  • Постоянные спецификации описывают текущее требуемое поведение системы.
  • Дельта фиксирует разницу между текущими и предлагаемыми требованиями.
  • Процесс рассчитан на последовательные изменения существующей кодовой базы.
  • Общие спецификации помогают команде согласовать требования и историю их изменения.

Когда выбирать

OpenSpec подходит для существующей системы, требования к которой нужно поддерживать вместе с кодом. Для процесса на основе скиллов с обязательными контрольными точками рассмотрите Superpowers, а для работы через трекер задач сравните пак Мэтта Покока.

results matching ""

    No results matching ""