Урок 16.1. Обзор Spec Kit, философия SDD и история проекта

Зачем это нужно

В уроке 2.8 Spec Kit уже появлялся как канонический baseline для Spec-Driven Development: harness, который проводит агента по цепочке constitution -> specify -> clarify -> plan -> tasks -> analyze -> implement. Этот модуль - систематический разбор Spec Kit по официальной документации: установка, процессы, справочник команд, механизмы кастомизации, работа в существующих проектах и экосистема сообщества.

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

• понять, что Spec Kit дает разработчику сегодня - ведь за год проект вырос из SDD-тулкита в расширяемый каркас процессов;
• зафиксировать философию Spec-Driven Development: что считается «спекой», что она дает агенту и чем отличается от написания кода по промпту;
• ориентироваться в истории проекта: многие решения документации (пять примитивов, каталоги, opt-in расширения) объясняются именно эволюцией.

Этот урок отвечает на все три вопроса. Остальные уроки модуля предполагают, что ментальная модель Spec Kit из этого урока усвоена.

Основная идея

Spec Kit дает coding-агенту структурированные процессы, в которых намерение (intent) и подтверждения (evidence) опережают реализацию. Три независимые точки входа:

Это независимые точки входа, а не обязательные фазы. SDD входит в ядро; багфикс и оценка идей - bundled opt-in расширения. Оценка может работать автономно: решение продолжить не запускает реализацию автоматически.

Ключевая формула ядра SDD:

Specify -> Plan -> Tasks -> Implement -> Converge

Каждая фаза производит Markdown-артефакт, который питает следующую. Вместо ad-hoc промптов агент получает структурированный контекст: шаблоны, чек-листы качества и кросс-артефактный анализ идут «из коробки».

Что такое Spec Kit: четыре столпа

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

Spec-driven по умолчанию

Ядро - процесс SDD: Specify -> Plan -> Tasks -> Implement -> Converge. Вы определяете, что строить, до того, как строить. Каждая фаза оставляет артефакт; артефакты собираются по насыщенным шаблонам, снабжены чек-листами качества и проверяются на кросс-консистентность (команда /speckit.analyze).

Любой coding-агент

38 интеграций: Copilot, Gemini, Codex, Kilo Code, Zed, Claude, Forge, Kiro и другие. Переход между агентами - одна команда. Привязки к конкретному инструменту нет: specify init с выбранным агентом развернет нужные файлы команд и структуру каталогов; если агента нет в списке, интеграция generic - запасной путь для любого инструмента. Подробно - в уроке 16.10.

Настройка под себя

157 расширений сообщества от 90+ авторов, 33 пресета (дата среза: 2026-10-03). Ядро можно тюнинговать пресетами, расширять расширениями, оркестрировать workflow-ами и упаковывать все это в бандлы - или заменить процесс целиком. Сам процесс живет в этих строительных блоках, поэтому нет привязки даже к SDD - и даже к разработке ПО: среди процессов сообщества есть AIDE (7-шаговый жизненный цикл), Canon (baseline-driven workflows), Product Forge (продуктовый SDD), FX->.NET (миграция), MAQA (мультиагентная оркестрация с QA-воротами) и Fiction Book Writing - написание романов, от story bible до отправки издателю.

Интеграция в организацию

Работает офлайн, за файрволами, на Windows, macOS и Linux. Организация может хостить собственные каталоги, курировать, какие интеграции, расширения, пресеты, workflows и бандлы видят ее команды. Расширения вроде CI Guard и Architecture Guard добавляют ворота соответствия и governance поверх существующего процесса.

Статистика экосистемы на дату среза (2026-10-03): 130K+ звезд GitHub, 270+ контрибьюторов, 38 интеграций, 157 расширений, 33 пресета, 7 friends-проектов.

Философия Spec-Driven Development

Spec-Driven Development меняет роли: десятилетиями код был королем, а спецификации - строительными лесами, которые выбрасывали, когда начиналась «настоящая работа». SDD переворачивает это: спецификации становятся исполняемыми (executable) - они напрямую порождают работающие реализации, а не просто направляют их.

Ядро философии - четыре принципа:

→ intent-driven: спецификация определяет «что» до «как»
→ насыщенное создание спецификаций: guardrails и организационные принципы
→ многошаговая проработка вместо one-shot генерации кода из промпта
→ сильная опора на возможности моделей в интерпретации спецификаций

Что из этого следует практически:

• Intent-driven. Спека отвечает на вопрос «что должно получиться и почему», а не «какими функциями это написать». Технические решения фиксируются позже, в plan.md, и не подменяют требования.
• Guardrails. Спецификация пишется не в пустоту: конституция проекта задает принципы, шаблоны навязывают структуру, чек-листы не дают пропустить пользовательские сценарии и граничные случаи.
• Многошаговость. Путь от идеи к коду разбит на фазы, каждая из которых проверяема человеком. One-shot промпт «напиши мне X» так не работает: агент заполняет пробелы собственными предположениями.
• Роль модели. SDD рассчитан на сильные модели, способные читать длинные спецификации и удерживать ограничения. Процесс организован так, чтобы эта способность использовалась, а не разбазаривалась.

Три сценария разработки

Документация SDD фиксирует три сценария применения:

Границы того, что предписывает SDD

Важная оговорка документации: Spec Kit не предписывает, как команда сохраняет или изменяет spec.md, plan.md и tasks.md после смены требований. Модели хранения спецификаций разобраны в уроке 16.8, workflow эволюции в существующих проектах - в уроке 16.18.

Когда компоненты открывают интерфейсы внешним потребителям, документация рекомендует Contract-Driven Development: договориться об observable-обязательствах сторон до реализации каждой из них - независимо от архитектуры и раскладки репозитория. Это тоже урок 16.18.

Экспериментальные цели

Проект позиционирует SDD как исследовательскую программу. Цели экспериментов:

• Независимость от технологий. Создавать приложения на разных стеках; подтвердить гипотезу, что SDD - процесс, не привязанный к конкретным технологиям, языкам и фреймворкам.
• Enterprise-ограничения. Демонстрировать разработку mission-critical приложений с учетом организационных ограничений: облачные провайдеры, корпоративные стеки, дизайн-системы, комплаенс.
• Ориентация на пользователей. Строить приложения для разных когорт и предпочтений; поддерживать спектр подходов - от vibe-coding до AI-native разработки.
• Творческие и итеративные процессы. Валидировать параллельную проработку реализаций; давать устойчивые workflow итеративной разработки фич; расширять процессы на апгрейды и модернизацию.

История проекта

Spec Kit начинался как тулкит, делающий спецификации отправной точкой AI-ассистированной разработки. С первого полного check-in проект описывал три способа применения SDD (те же, что в таблице выше): greenfield, творческое исследование и brownfield. Все три вели от durable-артефактов планирования к реализации через последовательность Specify -> Plan -> Tasks -> Implement.

Эти пути и ядро последовательности остались, но проект вырос в расширяемый harness для coding-агентов, процессов delivery и иной структурированной работы.

Управление проектом

История включает два периода стюардства.

Основатели: август 2025 - январь 2026. Den Delimarsky и John Lam задумали Spec Kit и придали ему первую форму. Den сделал initial commit 21 августа 2025 и вел репозиторий первые месяцы. Этот период установил узнаваемую форму: Specify CLI, агентское scaffolding, конституции проектов и процесс specification -> plan -> tasks -> implementation. SDD сразу позиционировался для greenfield, параллельного исследования и brownfield - без привязки к одному агенту или сценарию.

Комьюнити-стюардство: январь 2026 - настоящее время. Manfred Riem стал lead-мейнтейнером 22 января 2026; переход стал публично виден, когда глобальная запись CODEOWNERS сменилась на @mnriem 23 февраля. Фокус мейнтейнерской команды сместился с построения композируемой модели к ее использованию - к выпуску законченных first-party процессов. Сдвиг не был последовательным для сообщества: модульная система расширений началась как контрибуция, и участники Adopt-или каждое новое примитив по мере появления.

Вехи

Август 2025: фундамент. История репозитория начинается 21 августа 2025. Первые релизы дали Specify CLI, переиспользуемые шаблоны и основные SDD-пути. Поддержка нескольких coding-агентов через централизованно сконфигурированное scaffolding была с самого начала - процесс не зависел от одной модели или инструмента.

Февраль-апрель 2026: строительство примитивов. Модульная система расширений пришла в феврале как контрибуция Michal Bachorik - возможности можно добавлять, не расширяя ядро. В марте появились подключаемые пресеты: шаблоны и команды стали заменяемыми и композируемыми при том же CLI-опыте. Founding-эра агентского scaffolding была переписана в архитектуру интеграций на базе реестра. Core-ассеты встроили в Python-пакет - это дало надежную офлайн- и air-gapped-инициализацию. В апреле workflow-движок получил распределенные через каталоги автоматизации и встроенные типы шагов; workflows координировали переиспользуемые шаги вместо ручного вызова команд. Следом появился каталог интеграций.

Композируемая модель описывается пятью примитивами:

• Integrations подключают Spec Kit к coding-агентам;
• Extensions добавляют возможности: команды, шаблоны, скрипты, хуки;
• Presets кастомизируют или заменяют поведение;
• Workflows автоматизируют многошаговые процессы;
• Workflow steps - переиспользуемые единицы поведения workflow.

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

Июнь-июль 2026: композиция и применение. Для core-команды июнь стал поворотом от строительства примитивов к их использованию. Каталог workflow-шагов сделал кастомные типы шагов устанавливаемыми сообществом. Затем бандлы позволили паковать расширения, пресеты, workflows и шаги в законченный setup для роли или команды - с опциональной привязкой к интеграции.

Каталоги стали мостом между примитивами и сообществом: авторы публиковали компоненты, мейнтейнеры проверяли метаданные сабмишенов и включали принятые в community-каталоги. Листинг в каталоге делает компонент видимым, но не означает аудит или одобрение его кода.

Параллельно мейнтейнеры добавили два first-party процесса (обе - bundled, opt-in):

• 5 июня, v0.9.5 - расширение bug: процесс assess -> fix -> test держит диагностику, исправление и верификацию бага раздельными и документированными.
• 17 июля, v0.13.0 - расширение assess: процесс intake -> research -> define -> shape -> decide оценивает идею до входа в SDD.

Дистрибуция расширилась: релизный конвейер добавил публикацию на PyPI, а Python присоединился к Bash и PowerShell как типу проектных скриптов.

Август 2026: первая годовщина. Spec Kit исполнился год, и 21 августа 2026 вышла версия 1.0.0. К этому моменту пять примитивов уже образовывали цельную модель, бандлы компоновали их вокруг выбранной интеграции, а обновленный README выделял отдельные quickstart-ы для SDD, багфикса и оценки идей.

Версия 1.0.0 не создавала и не замораживала модель - она дала круглый номер эволюционирующему состоянию. В посте мейнтейнера «Spec Kit Turns One - and Ships 1.0.0» версия названа «просто числом»: по мере того как агенты удешевляют адаптацию к изменениям, ценность смещается от стабильности к адаптируемости. Годовщина также подчеркнула вклад всех, кто использовал Spec Kit, оспаривал его допущения, репортил проблемы, писал код и документацию, создавал расширения и пресеты.

Сквозные темы

Историю проекта связывают несколько постоянных тем:

• Намерение впереди реализации. Спецификации фиксируют, что строить, до того как технические решения захватят работу.
• Артефакты должны быть durable. Спеки, планы и задачи остаются полезными за пределами одного промпта или сессии агента.
• Процесс не зависит от агента. Команда может сменить coding-агента, не меняя метод разработки.
• Метод подстраивается под работу. Исходные пути разработки выросли в формально композируемую модель, которую можно менять, автоматизировать или заменять.
• Кит формирует сообщество. Контрибуции влияли и на инфраструктуру проекта, и на экосистему поверх него.

Страница истории фиксирует эволюцию в целом, а не каждую фичу; детали по релизам - в changelog и GitHub Releases.

Ментальная модель модуля

Свяжем историю с тем, как устроен модуль. Spec Kit сегодня - это три слоя:

1. CLI specify - терминальный инструмент: установка, инициализация проекта, управление примитивами (уроки 16.2, 16.9).
2. Агентные процессы /speckit.* - команды, которые выполняет ваш coding-агент в чате: SDD, багфикс, оценка идей (уроки 16.3-16.7).
3. Строительные блоки - extensions, presets, workflows, bundles и их инвентаризация через artifacts (уроки 16.10-16.16).

Практика

1. Откройте лендинг документации Spec Kit (https://github.github.io/spec-kit/) и самостоятельно сформулируйте ответ: какой из трех процессов (SDD, bug, assess) вам нужен в текущем проекте и почему.
2. Проверьте по разделу «История», когда появился каждый из пяти примитивов, и сопоставьте это с датами вех. Эта хронология пригодится при чтении уроков блока D.
3. Вернитесь к уроку 2.8 и сверьте введенную там цепочку фаз с формулой Specify -> Plan -> Tasks -> Implement -> Converge из этого урока: заметьте, какие quality gates (clarify, checklist, analyze) добавились в формулу официальной документации.

Краткое резюме

Spec Kit - расширяемый каркас процессов для coding-агентов, выросший из SDD-тулкита. Ядро - Spec-Driven Development: последовательность Specify -> Plan -> Tasks -> Implement -> Converge, где каждая фаза оставляет Markdown-артефакт. Параллельно идут два opt-in процесса: багфикс (assess -> fix -> validate) и оценка идей (intake -> research -> decide). Философия SDD: спецификации становятся исполняемыми, намерение опережает реализацию, проработка многошаговая, guardrails и организационные принципы встроены в шаблоны.

Главное из урока:

• три независимые точки входа: build (SDD, ядро), fix (bug, opt-in), assess (opt-in); они не обязаны идти подряд;
• Spec Kit работает с 38 агентами и не привязан ни к одному;
• пять примитивов - integrations, extensions, presets, workflows, workflow steps - делают процесс конфигурируемым, дистрибутируемым и автоматизируемым;
• версия 1.0.0 (21.08.2026) - не заморозка модели, а круглый номер: проект продолжает эволюционировать;
• статистика экосистемы (157 расширений, 33 пресета, 270+ контрибьюторов) дана на дату среза 2026-10-03.

Вопросы для самопроверки

1. Что общего и что различного у трех точек входа Spec Kit (SDD, багфикс, оценка идей)? Почему они называются независимыми?
2. Перечислите фазы ядра SDD в порядке выполнения. Какой артефакт остается после каждой фазы?
3. Что означает «спецификации становятся исполняемыми» в философии SDD? Чем это отличается от классической роли спецификаций?
4. Назовите пять примитивов композируемой модели и по одному предложению на каждый.
5. Почему версия 1.0.0 описывается как «просто число»? Какое смещение ценностей фиксирует годовщина проекта?
6. Какие три сценария разработки документировал Spec Kit с самого первого check-in?

Что дальше

Следующий шаг - поставить Spec Kit на свою машину и инициализировать первый проект. Урок 16.2 разбирает оба официальных канала установки (GitHub-исходник и PyPI), требования окружения, air-gapped-сценарий для enterprise и апгрейд CLI и файлов проекта между релизами.

Источники

• https://github.com/github/spec-kit/blob/main/docs/index.md
• https://github.com/github/spec-kit/blob/main/docs/concepts/sdd.md
• https://github.com/github/spec-kit/blob/main/docs/history.md