В продолжение предыдущего поста.
Давайте сравним два AI SDD фреймворка - OpenSpec и SpecKit.
Сравнивать будем в первую очередь по составу скилов, которые выстраиваются в линейный workflow по работе над фичей.
OpenSpec - вот базовый вариант:
- /opsx:propose (написание аналитики в составе: proposal, спецификация, дизайн, план)
- /opsx:apply (реализация)
- /opsx:archive (проверка выполнения плана, слияние спек при необходимости, архивация ненужного, перемещение спеки в статус "выполнено")
Просто, всего три шага, после первых двух нужно ревью со стороне человека.
Вот максимально полный вариант:
- /opsx:explore (предварительное исследование, аналог brainstorming в superpowers)
- /opsx:new (создание только proposal.md - документ с секциями "Зачем?", "Что?", "Что меняем?", "Критерий успеха?")
- /opsx:continue 3 раза - создание остальных документов: spec.md (сценарии и требования), design.md (архитектура), tasks.md (план реализации, минимум технических деталей).
- /opsx:apply
- /opsx:verify (ревью реализации)
- /opsx:archive
Тут добавляется брейнштоминг, контроль аналитики по каждому документу отдельно и шаг ревью реализации по трем критериям: полнота, корректность и консистентность с архитектурными (design.md) и code style требованиями.
Т.е. это некий аналог code-review скила, расширенный проверкой соответствия реализации и архитектуры по фиче.
Теперь SpecKit, базовый flow:
/speckit.constitution (некий аналог /init у AI агентов, выполняется один раз)
/speckit.specify (аналитика без архитектуры и плана - spec.md)
/speckit.plan (создается технический план, по сути - архитектура, разбитый на части: contracts\*, data-model.md, plan.md, quickstart.md, research.md)
/speckit.tasks (полный аналог tasks.md)
/speckit.implement (реализация)
Расширенный flow:
/speckit.constitution
/speckit.specify
/speckit.clarify (уточнение задачи, исследования)
/speckit.plan
/speckit.tasks
/speckit.analyze (ревью консистентности аналитики)
/speckit.checklist "что проверяем" (создание чек-листа для проверки реализации в каком-то разрезе: unit tests, security)
/speckit.implement
/speckit.converge (ревью реализации)
Что хочется отметить:
- названия шагов (скилов) не совпадают от слова совсем
- у SpecKit появляется /speckit.constitution, более интерактивный init проекта, позволяющий задать базовые принципы разработки, а кроме того инициализирующий шаблоны, по которым создается аналитика, адаптируя их под текущий проект.
- у SpecKit даже в базовом варианта аналитика создается пошагово с четким разделением на бизнес и техническую части, плюс план.
- набор создаваемых артефактов отличается: совпадают spec.md и tasks.md. У SpecKit файлов больше, т.к. технические документы разделены: API, схема данных, research и собственно архитектура, почему-то названная планом.
- у OpenSpec брейншторминг идет до создания спецификации, у SpecKit - после.
- у SpecKit есть шаг ревью аналитики и шаг создания evals - приемочных чек-листов
- ревью реализации есть у обоих, но OpenSpec пишет замечания и в зависимости от их критичности предлагает сразу исправить, а SpecKit на основе расхождений заводит новые таски
- у OpenSpec есть понятие архивации, которое помечает спеку как выполненную и перемещает ее в архив.
Но как раз на архивации видно ключевое отличие этих фреймворков. В OpenSpec спецификация - это дельта-спецификация.
Что это значит? Что вначале анализируется набор существующих спек в проекте, и для новой сразу же определяется что это - новая фича, изменение или удаление существующей. И на этапе архивации происходит синхронизация - правится или удаляется существующая спецификация, или добавляется новая.
Еще одно отличие - в OpenSpec важной считается только spec.md (сценарии и требования), остальные файлы архивируются - остаются в проекте, но помещаются в папку archive.
У SpecKit такого шага нет, соответственно, слияние аналитики происходит вручную и все создаваемые файлы остаются в папке со спецификацией.
Итог - workflow достаточно сильно отличается, при этом оба соответствуют всем принципам, описанным в предыдущем посте.
У каждого есть плюсы и минусы. OpenSpec проще из коробки и частично берет на себя вопрос упорядочивания фич в проекте. SpecKit заточен на контроль и детализацию.
Я лично использую OpenSpec в связке с superpowers, но об этом в следующей серии.
#ai #ai_harness #dev_workflow
1July 11, 2026 131
