SpecScore vs OpenSpec

Оба инструмента хранят спецификации в Markdown рядом с вашим кодом — читаемые для ИИ-агентов. Они решают разные задачи: OpenSpec организует спецификации и генерирует команды для агентов. SpecScore проверяет структуру и ссылки спецификаций, контролирует жизненный цикл и обеспечивает трассируемость кода к требованиям.

Аналоги OpenSpec в 2026 году.

Что у них общего.

Спецификации хранятся в репозитории как Markdown-файлы — с контролем версий и ревью через PR.
Оба проекта с открытым исходным кодом.
Оба используют критерии приёмки в формате Given/When/Then.
Оба поддерживают ИИ-агентов для разработки как полноценных потребителей спецификаций.

Сильные стороны OpenSpec.

Самая широкая поддержка агентов

OpenSpec поддерживает 29 ИИ-агентов для разработки через генерируемые файлы навыков — Claude, Cursor, Copilot, Gemini, Windsurf, Cline и другие. Если ваш агент есть в списке, OpenSpec интегрируется без настройки.

Низкий порог входа

npm install -g @fission-ai/openspec && openspec init — и вы уже пишете спецификации. Не нужно изучать схему, не требуется frontmatter. Инструмент спроектирован так, чтобы начать было максимально просто — особенно для существующих проектов.

Продуманная модель дельта-изменений

Формат ADDED / MODIFIED / REMOVED в OpenSpec для развития спецификаций хорошо продуман. Каждое изменение — это папка с предложением, дельта-спецификациями и задачами — структурированный способ предлагать модификации.

Сравнение возможностей.

Возможность	OpenSpec	SpecScore
Формат спецификаций	Markdown (без frontmatter)	Markdown + YAML frontmatter
Линтинг спецификаций	Только структура файлов	Структура и ссылки — обязательные секции, заголовки критериев приёмки, ссылки, расхождения индексов
Идентификаторы требований	Нет (ссылки по заголовку)	На основе slug (`REQ: slug-format`)
Идентификаторы критериев приёмки	Нет	Машинно-адресуемые ID
Статус жизненного цикла	Неявный (по расположению файла)	Контролируемый — Draft → Under Review → Approved → Implementing → Stable → Deprecated
Трассируемость кода к спецификациям	Нет	`specscore:` аннотации + `Verifies:` трейлеры коммитов
Подфункции	Нет	Да (вложенные директории)
Перекрёстные ссылки	Нет формального механизма	Зависимости, исходные идеи, ссылки на планы
Интеграция с CI	Базовая (`openspec validate`)	`specscore spec lint` с настраиваемой строгостью, подходит для CI и git-хуков
Поддержка агентов	29 агентов	Основной — Claude Code + CLI для любого агента
Настройка схемы	Да (`schema.yaml`, fork/init)	Фиксированная схема (консистентность по дизайну)
Предложения изменений	Дельта-модель (ADDED/MODIFIED/REMOVED)	Идеи и предложения на изменения
Зависимость от среды выполнения	Node.js 20.19+	Нет — единый бинарный файл на Go
Лицензия	MIT	CLI — Apache-2.0 · формат — CC BY 4.0

В чём SpecScore идёт дальше.

Проверка идёт глубже структуры файлов

Команда validate в OpenSpec проверяет структуру файлов — существует ли файл, есть ли нужные секции. SpecScore проверяет больше, в два слоя: spec lint детерминированно проверяет структуру и ссылки — обязательные секции, форму заголовков, перекрёстные ссылки и индексы, согласованность статусов, — а проверка ИИ (/review, /score) ловит то, что не под силу линтеру: неоднозначные критерии и расплывчатые формулировки.

$ specscore spec lint

features/apply-discount/README.md:0 [error] oq-section: Open Questions section not found
features/apply-discount/README.md:0 [error] index-entries: Child directory not listed in index: refunds
features/apply-discount/refunds:0 [error] readme-exists: README.md not found

3 violations found (3 errors)

У каждого требования есть машиночитаемый ID

OpenSpec ссылается на требования по заголовку — это хрупко при переименованиях. SpecScore присваивает ID на основе slug (REQ: slug-format) и ID критериев приёмки, которые сохраняются при переименованиях, рефакторингах и передаче между агентами.

Жизненный цикл контролируется, а не подразумевается

В OpenSpec жизненный цикл спецификации определяется расположением файла: specs/ (текущие), changes/ (предложенные), archive/ (завершённые). В SpecScore жизненный цикл — это контролируемое поле статуса: Draft → Under Review → Approved → Implementing → Stable → Deprecated — валидируется линтером, переключается командой specscore feature change-status из git-хуков или CI.

Код прослеживается до спецификаций

OpenSpec не имеет механизма трассируемости. В SpecScore есть аннотации specscore: в комментариях кода и трейлеры Verifies: в коммитах. Запустите specscore code refs и получите детерминированный ответ на вопрос «какой код реализует это требование?»

Без зависимости от среды выполнения

OpenSpec требует Node.js 20.19+. SpecScore — это единый бинарный файл на Go: без среды выполнения, без node_modules. Работает в проектах на Go, Rust, Python, Java без добавления Node в инструментарий.

Компонуемая иерархия артефактов

Спецификации OpenSpec плоские, организованные по доменам. SpecScore имеет типизированную иерархию: идеи продвигаются в функции, функции содержат требования и критерии приёмки, планы ссылаются на критерии приёмки, задачи ссылаются на планы. Все связи доступны для машинной навигации через CLI.

Когда что использовать.

Начните с OpenSpec, если...

Вы используете Cursor, Copilot или других не-Claude агентов и хотите интеграцию «из коробки».
Вы впервые добавляете спецификации в существующую кодовую базу и хотите минимум трений.
Ваша команда ценит гибкость схемы больше, чем контроль.

Используйте SpecScore, если...

Вам нужен контроль качества спецификаций — линтер находит структурные пробелы до того, как агенты потратят на них токены.
Вам нужна трассируемость кода к спецификациям — «какой код реализует это требование?» даёт детерминированный ответ.
Вы строите крупную систему с множеством функций, подфункций и переходов жизненного цикла.
Вы хотите ноль зависимостей от среды выполнения — один бинарный файл, Node.js не требуется.
Вам нужны гейты качества спецификаций в CI — specscore spec lint завершается с ненулевым кодом при ошибках, как ESLint или go vet.

Они не взаимоисключающие.

SpecScore может проверять файлы spec.md OpenSpec. Команды, начавшие с OpenSpec, могут добавить слой контроля качества SpecScore без миграции — проверяйте уже имеющиеся спецификации, добавляйте трассируемость, когда она понадобится, контролируйте жизненный цикл, когда команда вырастет.

OpenSpec — отличная стартовая площадка. SpecScore — ограждающие рельсы.

Другие сравнения.

Тот же формат рядом с другими инструментами разработки по спецификациям:

Все вместе, на одной странице: лучшие инструменты разработки по спецификациям в 2026 году.

Это сравнение основано на публично доступной документации и исходном коде. Что-то неверно или устарело? откройте issue с исправлением. Хотите, чтобы мы сравнили SpecScore с другим инструментом? запросите его.