GitHub Spec Kit против Kiro и Claude Code: рабочие процессы SDD

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

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

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

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

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

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

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

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

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

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

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

Выполнение задач – Как инструмент разбивает работу на ревьюемые срезы? Могут ли задачи выполняться параллельно? Предотвращает ли он взрыв из пятидесяти задач?

Контрольные точки ревью – Есть ли естественные человеческие шлюзы между specify, plan, tasks и implement? SDD без ревью — это просто более медленное vibe coding.

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

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

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

GitHub Spec Kit

GitHub Spec Kit — это открытый CLI-набор инструментов, который создает каркас для spec-driven цикла в вашем репозитории и передает выполнение любому кодинг-агенту, которым вы уже пользуетесь. CLI specify создает шаблоны, slash-команды и стандартную структуру папок. Типичные команды следуют последовательности constitution-specify-clarify-plan-tasks-implement, с явным шагом clarify для разрешения неоднозначностей до начала работы над архитектурой.

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

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

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

AWS Kiro

Kiro — это spec-driven 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 и готовы принять spec-нативную IDE. Это сильный вариант для корпоративных команд, сред, ориентированных на 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 (или эквивалент), который определяет ваш чек-лист specify-plan-implement и загружается по запросу.

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

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

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

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

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

Рабочий процесс, который он принуждает, тесно соответствует пятифазному циклу, покрытому в Рабочий процесс Spec-Driven Development от требований до кода: мозговой штурм дорабатывает грубую идею в ревьюированный документ дизайна, writing-plans разбивает его на маленькие проверяемые задачи, subagent-driven-development диспатчит новый сабагент на каждую задачу с двухэтапным ревью, а test-driven-development принуждает к строгому циклу red-green-refactor, прежде чем что-либо считается готовым. Эта последняя часть строже, чем большинство SDD-навыков Claude Code стараются быть — Superpowers явно удаляет код, написанный до того, как для него существовал проваливающийся тест.

В отличие от локального для репозитория навыка, который вы пишете сами, Superpowers не только для Claude Code. Он выпускает манифесты плагинов для Claude Code, Cursor, Codex, Gemini CLI, GitHub Copilot CLI, Devin, Factory Droid и нескольких других агентов, поэтому одна и та же методология следует за вами между обвязками, а не живет в одной папке .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.

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

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

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

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

Какой настройкой SDD вам пользоваться?

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

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

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

Одиночный разработчик, 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, а не заменяет их.

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

Что на самом деле определяет успех

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

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

Если вы все еще выбираете между SDD и неструктурированным промптингом для данной фичи, прочитайте Spec-Driven Development против Vibe Coding. Сравнение инструментов в этой статье имеет значение только тогда, когда вы решили, что фича заслуживает спецификации вообще.

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

Заключение

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

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

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

• Документация GitHub Spec Kit – официальное справочное руководство по рабочему процессу Spec Kit
• Superpowers Quickstart: Install, Workflow, and Tryout – открытый пакет навыков, принуждающий к методологии от мозгового штурма до TDD через Claude Code, Cursor, Codex и других агентов
• Martin Fowler об инструментах SDD – анализ Kiro, Spec Kit и Tessl