Пять паттернов Spec-Driven Development: OpenSpec, Superpowers и Spec Kit

Команда Spec Coding опубликовала сравнительный анализ трёх подходов к спецификационной разработке (SDD) — OpenSpec, Superpowers и GitHub Spec Kit. Статья примечательна тем, что написана авторами собственного инструмента, поэтому оценивает конкурентов через призму практических паттернов, а не рейтингов.

Главный тезис

Полезный вопрос не «какой инструмент лучше», а «какой артефакт существует до начала кода, кто его утверждает и как финальный diff доказывает, что код следует этому артефакту». Три инструмента решают одну задачу разными словами: заставить AI-ассистента работать по спецификации, а не по чат-промпту.

Когда какой путь выбирать

Пять паттернов SDD

1. Создавай долговечный артефакт до реализации

OpenSpec организует изменение вокруг proposal → specs → design → tasks. Spec Kit выстраивает lifecycle: principles → spec → plan → tasks → implementation. Superpowers сначала извлекает спецификацию из диалога, затем планирует и кодит.

Практическое правило: до генерации кода у фичи должен быть хотя бы один файл с целью, non-goals, критериями приёмки, владельцем и требованиями к доказательствам. Чат-транскрипт не считается — его нельзя ревьюить потом.

2. Разделяй продуктовый интент и техплан

Spec Kit явно разделяет «что и зачем» (specification) от «как реализуем» (plan). OpenSpec аналогично отделяет proposal/specs от design/tasks. Это важно, потому что AI-кодинг быстро сворачивает продуктовую неопределённость в реализационные решения: модель выбирает схему БД и границы API до того, как команда договорилась о поведении.

Уровни артефактов:

3. Не добавляй церемонию без нужды

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

Минимальная версия — одностраничный spec packet. Максимальная — constitution, requirements, technical design, task breakdown, migration plan, risk register, test evidence.

4. Декомпозируй задачи до проверяемых единиц

Superpowers особенно силён в идее, что план должен быть достаточно ясным для реализации без выдумывания контекста. Хороший таск — не просто «добавить retry», а:

Task: add timeout retry to refund worker
Write scope:
  - src/billing/refund-worker.ts
  - src/billing/refund-worker.test.ts

Acceptance:
  - timeout once → retry with same idempotency key
  - timeout twice → keep pending status, no duplicate refund_id

Evidence:
  - test: refund_timeout_replay
  - log query: duplicate_refund_attempts remains zero

5. Сделай evidence частью процесса

Все три проекта пытаются сократить разрыв между «ассистент выдал код» и «команда может доверять изменению». Спецификация не должна заканчиваться на реализации — она должна определять, какие доказательства ожидает ревьюер: тесты, имена фикстур, логи, скриншоты, проверки контрактов.

Цепочка артефактов:

ticket.md → spec.md → design.md → tasks.md → tests + evidence.md → PR review

Если любое звено отсутствует — команда должна понимать почему. Если AI-сгенерированный PR не может отследить свои изменения до задачи и критерия — PR не готов.

Что позаимствовать у каждого инструмента

Рекомендуемая структура репозитория

Авторы предлагают макет, который работает без привязки к конкретному инструменту:

/specs
  /active
    refund-retry/
      spec.md
      design.md
      tasks.md
      evidence.md
  /archive
    2026-05-11-refund-retry/
/templates
  feature.spec.md
  api-contract.spec.md
  ai-coding-review.md
/docs
  engineering-principles.md

Резюме

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