Пост В продолжение предыдущего поста.

В продолжение предыдущего поста. Давайте сравним два 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