GitHub Spec Kit против Kiro и SDD-процессов Claude Code

Разработчики, сравнивающие решения на базе Спецификации-Ориентированной разработки (SDD) в 2026 году, как правило, не спрашивают, какая модель самая умная. Они интересуются, какой рабочий процесс позволит поддерживать ИИ-агента в нужном направлении, не погружая команду в бюрократическую суету.

GitHub Spec Kit, AWS Kiro и пользовательские рабочие процессы Claude Code реализуют одну и ту же общую идею — требования, проектирование, задачи, реализация, валидация — но различаются по переносимости, глубине интеграции и степени enforce (принудительности) процесса.

Если вам сначала нужны концепции, прочитайте Что такое Спецификация-Ориентированная разработка? и инструмент-нейтральное руководство Рабочий процесс Спецификации-Ориентированной разработки в кластере документации Архитектура приложений. Это сравнение находится в хабе ИИ-инструменты для разработчиков наряду с обзорами ассистентов и руководствами по рабочим процессам.

SDD становится категорией инструментов

Спецификация-Ориентированная разработка перестала быть бумажной практикой в конце 2025 года. Теперь каждый крупный вендор ИИ-кодирования предоставляет свою версию цикла «спецификация-планирование-реализация», а растущий список независимых инструментов конкурирует за то, сколько структуры они добавляют вокруг этого цикла.

Сравнение, которое действительно важно, — это не «какой инструмент побеждает», а глубина процесса versus переносимость. Kiro интегрирован. Spec Kit переносим. Рабочие процессы Claude Code легко кастомизируются. Плохие спецификации делают любого агента хуже, независимо от того, какую обёртку вы выберете. Хорошие спецификации переносятся между инструментами.

Как сравнивать настройки SDD

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

Переносимость — могут ли спецификации храниться как обычный markdown в вашем репозитории и работать с агентом, который вам предпочтителен в следующем квартале? Или они привязаны к одной IDE, одному облаку или одному проприетарному формату?

Трение при настройке — сколько времени проходит от «я хочу попробовать SDD» до рабочего цикла «спецификация-план-задачи»? Каркасы CLI, установка IDE или создание собственных slash-команд имеют разную энергию активации.

Качество спецификаций — помогает ли инструмент писать точные требования и критерии приёмки, или он в основном генерирует длинные документы? Структура полезна. Объём — нет.

Выполнение задач — как инструмент дробит работу на проверяемые слайсы? Могут ли задачи выполняться параллельно? Устойчив ли он к взрыву из пятидесяти пунктов задач?

Чекпоинты ревью — есть ли естественные человеческие вентили (gates) между этапами спецификации, планирования, задач и реализации? SDD без ревью — это просто медленный вайб-кодинг (vibe coding).

Заземление в репозитории — читает ли рабочий процесс конвенции проекта, записи решений, ADR (Архитектурные решения), AGENTS.md и существующий код перед планированием? Агенты без заземления переизобретают архитектуру, потому что они никогда не видят проверенное намерение за предыдущими выборами.

Командное сотрудничество — могут ли несколько человек проверять одни и те же артефакты спецификаций в pull request’ах? Можно ли миксовать агентов, не переписывая процесс?

Привязка (Lock-in) — что вы потеряете, если через шесть месяцев смените редактор, модель или облачного вендора?

GitHub Spec Kit

GitHub Spec Kit — это open-source CLI-набор инструментов, который выстраивает цикл спецификации-ориентированной разработки в вашем репозитории и передаёт выполнение тому кодирующему агенту, который вы уже используете. CLI specify размещает шаблоны, slash-команды и стандартную структуру папок. Типичные команды следуют последовательности конституция-спецификация-уточнение-план-задачи-реализация, с явным этапом уточнения для разрешения двусмысленности до начала архитектурной работы.

Определяющее преимущество Spec Kit — независимость от агента. Официальная документация позиционирует его как инструментарий, работающий с Claude Code, GitHub Copilot, Cursor, Gemini CLI, Codex и десятками других агентов. Вы пишете спецификации один раз в markdown, коммитите их как код и меняете исполнителя, не переписывая процесс. Это делает Spec Kit рекомендованным по умолчанию для команд, которые хотят SDD без ставки на одного вендора.

Компромиссы реальны. Spec Kit может создавать большое дерево артефактов — конституция, спецификация, план, задачи, контракты — что окупается на фичах, занимающих несколько сессий, но кажется тяжёлым для небольшой правки CLI. Потоки на Hacker News регулярно сравнивают эти накладные расходы с водопадной бюрократией. Spec Kit также слабее, если вы хотите полностью интегрированную IDE, где спецификации, задачи и реализация живут в одной руководимой среде. Он накладывает процесс поверх вашего существующего редактора, а не заменяет его.

Spec Kit подходит командам, которые уже имеют предпочтительного ИИ-ассистента для кодирования и хотят стандартизированный каркас SDD поверх него. Он особенно силён для greenfield-фич, компаний, использующих несколько агентов, и для всех, кто отказывается от привязки к редактору.

AWS Kiro

Kiro — это IDE от AWS со спецификациями в основе, построенная на форке VS Code / Code OSS. Там, где Spec Kit привносит SDD в ваш существующий стек, Kiro предполагает, что SDD заслуживает созданной под это среды. Промпт генерирует структурированные артефакты — обычно requirements.md в нотации EARS-стиля, design.md и tasks.md с упорядоченной по зависимостями последовательностью — прежде чем агенты пишут производственный код.

Руководимый опыт — главная продающая точка Kiro. Требования, дизайн и задачи — это объекты первого класса в UI рядом с вашим кодом, а не файлы, которыми вы управляете через отдельный CLI. Kiro также предоставляет Agent Hooks (хуки агентов), событийные автоматизации, которые могут обновлять тесты, документацию или связанные артефакты при изменении реализации. Этот двунаправленный цикл — то, что Spec Kit не обеспечивает из коробки: спецификации Spec Kit остаются статичными, пока человек не обновит их.

Ценой является глубина интеграции взамен переносимости. Kiro работает внутри своего редактора, использует модели на базе AWS Bedrock и тарифицируется по кредитной модели с раздельными планами. Корпоративные команды, уже работающие на инфраструктуре AWS, часто находят это приемлемым. Отдельные разработчики и команды, использующие несколько редакторов, — возможно, нет. У Kiro также есть шероховатости, типичные для более новой IDE — совместимость расширений, неожиданные повороты в рабочих процессах и обычный вопрос «мне действительно нужен ещё один редактор?».

Kiro подходит разработчикам, которые хотят самый руководимый опыт SDD и готовы принять IDE, ориентированную на спецификации. Это сильный вариант для корпоративных команд, сред, heavily (много) использующих AWS, и для всех, кто переходит с Amazon Q Developer и хочет дисциплину спецификаций без ручной сборки цепочки инструментов. Если сегодня вы живёте в стандартном VS Code и любите свою текущую настройку, Kiro требует большей смены, чем Spec Kit.

Пользовательские команды и скиллы в Claude Code

Claude Code не предоставляет единого официального продукта SDD таким образом, как Spec Kit или Kiro. Если вы новичок в самом инструменте, начните с руководства по установке и конфигурации Claude Code} для настройки, разрешений и локальных бэкендов. Сам паттерн SDD живёт в пользовательских командах, скиллах и локальных markdown-шаблонах репозитория, которые поддерживают разработчики. Anthropic влила старые файлы .claude/commands/*.md в механизм Skills, так что устойчивый паттерн — это SKILL.md (или эквивалент), который определяет ваш чек-лист «спецификация-план-реализация», загружаемый по требованию.

Этот подход самый лёгкий и самый подверженный кастомизации. Вы можете перенести трёхфайловую раскладку в стиле Kiro, отразить фазы Spec Kit с помощью slash-команд или придумать минимальный рабочий процесс, подходящий для одного репозитория. Claude Code читает CLAUDE.md для постоянного контекста проекта и тянет скиллы, когда задача совпадает. Эта прогрессивная дисклозура (раскрытие) сохраняет сессии сфокусированными, не загружая полную конституцию при каждом промпте.

Минус — дисциплина. Ничто не заставляет вас проходить через вентили уточнения или ревью, если вы сами не построите эти вентили. Потоки на Reddit и Hacker News о «спецификации-ориентированной разработке внутри Claude Code» полны разработчиков, которые скопировали чей-то чужой скилл, запустили его один раз и вернулись к неструктурированному промптингу, когда скилл показался медленным. SDD в Claude Code работает, когда вы относитесь к скиллам как к коду — версионированному, проверяемому и поддерживаемому, — а не как к одноразовой загрузке промпта.

Для серьёзной реализации прочитайте Claude Skills и SKILL.md для разработчиков} и закодируйте ваши фазы как скиллы с явными чекпоинтами ревью. SDD в Claude Code — правильный выбор, когда вы уже живёте в Claude Code, хотите максимальную гибкость и будете поддерживать рабочий процесс сами. Для шага с вентилями ревью конкретно, сабагенты в Claude Code могут выполнять независимый проход ревью с изолированным контекстом для сгенерированного кода перед тем, как вы вмержите задачу — это лёгкая замена роли верификации, которую нативно обеспечивают Agent Hooks в Kiro.

Superpowers: Упакованная версия DIY-стек скиллов

Если ручная сборка того стека скиллов звучит как именно та проблема дисциплины, о которой предупреждает таблица выше, Superpowers} стоит посмотреть. Это open-source пакет скиллов — брейншторминг, написание планов, субагент-ориентированная разработка, разработка, управляемая тестами, запросы код-ревью и горстка поддерживающих скиллов — распространяемый как устанавливаемый плагин, а не то, что вы пишете с нуля. Он напрямую нацелен на ограничение «качество полностью зависит от дисциплины автора»: скиллы срабатывают автоматически и предназначены как обязательный рабочий процесс, а не как опциональные предложения, которые агент может пропустить.

Рабочий процесс, который он强制执行, тесно соответствует пятифазному циклу, покрытому в Рабочий процесс Спецификации-Ориентированной разработки: от требований к коду}: брейншторминг дорабатывает черновую идею в проверенный документ дизайна, writing-plans дробит её на маленькие верифицируемые задачи, субагент-ориентированная разработка диспетчирует свежего сабагента на каждую задачу с двухступенчатым ревью, а TDD (разработка, управляемая тестами)强制执行 строгий цикл «красный-зелёный-рефакторинг», прежде чем что-либо считается готовым. Эта последняя часть строже, чем большинство SDD-скиллов в Claude Code обычно заботятся о ней — Superpowers явно удаляет код, написанный до того, как для него существовал падающий тест.

В отличие от локального скилла репозитория, который вы пишете сами, Superpowers не только для Claude Code. Он предоставляет манифесты плагинов для Claude Code, Cursor, Codex, Gemini CLI, GitHub Copilot CLI, Devin, Factory Droid и нескольких других агентов, так что одна и та же методология следует за вами через различные обвязки (harnesses), а не живёт в одной папке .claude/skills/. Это делает его серединой между написанием собственного скилла для Claude Code и принятием более тяжёлого, специфичного для IDE инструмента, как Kiro: вы получаете категоричный,强制执行 цикл, не отказываясь от своего редактора или не привязываясь к формату спецификаций одного вендора.

Superpowers подходит разработчикам, которые в принципе любят подход скиллов Claude Code, но постоянно соскальзывают обратно к неструктурированному промптингу, потому что ничего не强制执行 вентили ревью. Он хуже подходит, если у вас уже есть проект-специфичный SDD-скилл, настроенный под ваш стек — в этом случае вы обмениваете небольшое количество кастомизации на большее количество强制执行 церемоний.

BMAD, OpenSpec и другие рабочие процессы

Не каждая команда хочет дерева артефактов Spec Kit или IDE Kiro. Два альтернативных варианта постоянно всплывают в сравнениях 2026 года.

OpenSpec (Fission AI) берёт на себя изменение-центрированный подход с меньшим количеством генерируемых файлов, чем у Spec Kit. Сообщественные бенчмарки сообщают о значительно меньшем использовании токенов для сопоставимых задач ценой меньшей предварительной структуры. OpenSpec склонен побеждать, когда вы модифицируете существующую кодовую базу и хотите проверяемые спецификации без планового этапа на 800 строк. Он конкурирует со Spec Kit по переносимости больше, чем с Kiro по интеграции IDE. Смотрите быстрый старт OpenSpec} для шагов установки, цикла explore-propose-apply-archive и граблей, которые чаще всего всплывают на Reddit.

BMAD-METHOD (сообщество) двигается в противоположном направлении — мультиагентные, ролевые рабочие процессы, моделирующие персоны владельца продукта, архитектора, разработчика и ревьюера. BMAD может быть мощным на крупных greenfield-проектах, где явное разделение ролей помогает. Это также тяжело. Команды часто сообщают, что церемония окупается только тогда, когда боль координации уже остра.

Tessl рассматривает спецификацию как буквенный исходник генерируемого кода, помечая вывод как производный и отговаривая от ручных правок. Это самая сильная позиция «спецификация-как-источник» среди мейнстримных инструментов, но Tessl остаётся в бете и несёт самый высокий продукт-lock-in в группе.

Spec Kitty и другие сообщественные каркасы сидят между OpenSpec и Spec Kit по весу. Они заслуживают внимания, если вы хотите шаблоны, не принимая полную цепочку инструментов GitHub.

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

Какой набор SDD вам следует использовать?

Нет универсального победителя. Правильная настройка зависит от того, кто вы, что строите и сколько структуры вы действительно будете поддерживать.

Отдельный разработчик, существующая кодовая база, маленькие фичи. Начните с скиллов Claude Code или OpenSpec. Напишите короткий блок требований, минимальный список задач и один чекпоинт ревью. Не устанавливайте полное дерево Spec Kit для изменения в пятьдесят строк.

Хотите подход скиллов Claude Code, но постоянно пропускаете собственные вентили ревью. Установите Superpowers вместо написания кастомного скилла с нуля. Вы отказываетесь от некоторой проект-специфичной настройки в обмен на强制执行 цикл брейншторм-план-реализация-ревью, который не зависит от вашей дисциплины в тот день.

Отдельный разработчик, greenfield-фича, несколько сессий. Spec Kit или хорошо поддерживаемый SDD-скилл в Claude Code. Вам нужны стойкие артефакты больше, чем руководство IDE за ручку.

Небольшая команда, микс редакторов. Spec Kit. Обычные markdown-спецификации в Git, проверяемые в pull request’ах, исполняемые любым агентом, который предпочитает каждый разработчик.

Корпоративная команда, AWS-нативная, давление комплаенса. Kiro. Руководимые артефакты, трассируемость требований и хуки, которые держат документацию и тесты ближе к реализации.

Регулируемая среда. Kiro или Spec Kit плюс ваш собственный чек-лист валидации — не одни лишь скиллы Claude Code, если вы явно не закодируете вентили комплаенса. Инструментарий не заменяет аудиторские следы. Он только делает их легче производить.

Существующая кодовая база, brownfield-изменение. OpenSpec или лёгкий рабочий процесс Claude Code. Полная церемония Spec Kit на каждый багфикс будет ощущаться как водопад. Зарезервируйте более тяжёлую структуру для кросс-секционных фич.

Greenfield-продукт, много агентов. Spec Kit. Переносимость важнее, чем полировка IDE, когда Copilot, Claude Code и Cursor могут коснуться одного репозитория.

Командам, экспериментирующим с мультиагентной оркестрацией, также следует посмотреть на Oh My OpenCode Agents} для паттернов разделения ролей между агентами — это дополняет SDD-артефакты, а не заменяет их. Если ваша команда запускает терминал-ориентированный агент, а не интегрированный в IDE, практическое руководство по OpenCode CLI показывает более лёгкую, промпт-уровневую версию той же дисциплины «план-перед-реализацией» — полезной, когда полное дерево Spec Kit — это больше церемоний, чем требует задача.

Практическая таблица решений

Что действительно определяет успех

Выбор инструментов менее важен, чем качество артефактов. Файл требований Kiro с размытыми критериями приёмки произведёт тот же дрейф, что и небрежный промпт в Claude Code. План Spec Kit, который перечисляет пятьдесят избыточных задач, будет ощущаться как водопад, независимо от того, какой агент его реализует.

Практики, которые переносятся через каждую настройку, скучны и эффективны. Держите спецификации маленькими, чтобы их можно было проверить за один присест. Явно записывайте нецели (non-goals). Дробите задачи на диффы, которые человек может прочитать. Валидируйте по критериям приёмки перед мериджем. Обновляйте спецификацию, когда реализация обнаруживает лучший путь.

Если вы всё ещё выбираете между SDD и неструктурированным промптингом для конкретной фичи, прочитайте Спецификация-Ориентированная разработка vs Вайб-кодинг. Сравнение инструментов в этой статье имеет значение только после того, как вы решили, что фича заслуживает спецификации вообще.

Плохие спецификации делают каждого агента хуже. Хорошие спецификации переносятся между инструментами.

Заключение

GitHub Spec Kit, Kiro и рабочие процессы Claude Code — три ответа на один и тот же вопрос: как держать ИИ-агентов выровненными между сессиями — с разными ставками на переносимость versus интеграцию. Spec Kit оптимизируется под агент-независимый markdown в вашем репозитории. Kiro оптимизируется под руководимую IDE, нативную для спецификаций, с агентами на базе AWS. Скиллы Claude Code оптимизируются под hackable, лёгкие рабочие процессы, которые успешны только тогда, когда вы их поддерживаете.

Выбирайте самую мелкую настройку, которая всё ещё устраняет двусмысленность для текущей фичи. Добавляйте структуру, когда появляется боль координации, а не когда блог-пост вам говорит об этом. Разработчики, которые получают выгоду от SDD в 2026 году, — это не те, у кого самая elaborated (сложная) цепочка инструментов. Это те, кто пишет спецификации, достойные реализации, — а затем позволяет тому инструменту, который они выбрали, выполнять против них.

Полезные ссылки

• Документация GitHub Spec Kit — официальный справочник рабочего процесса Spec Kit
• Superpowers Quickstart: Установка, Рабочий процесс и Пробный запуск} — open-source пакет скиллов,强制执行 методология от брейншторма до TDD для Claude Code, Cursor, Codex и других агентов
• Martin Fowler об инструментах SDD — анализ Kiro, Spec Kit и Tessl