«Кастомизация без форка»: GitHub Spec Kit разложил настройку SDD на пресеты, расширения, бандлы и рабочие процессы

Четыре слоя вместо форка

Материал выходит как продолжение более ранней статьи Microsoft «Spec-Driven Development: A Spec-First Approach to AI-Native Engineering»: там разбирались принципы и жизненный цикл SDD, здесь — следующий шаг, адаптация процесса к стандартам, доменам, инструментам и требованиям управления в крупной инженерной организации. Основной тезис сформулирован прямо: форк инструментария под каждую команду фрагментирует опыт и удорожает обновления, поэтому нужен стабильный ядро с явными точками расширения.

Экосистема расширений GitHub Spec Kit (репозиторий github/spec-kit) разделена на четыре дополняющих друг друга слоя: пресеты меняют существующее поведение, расширения добавляют новые возможности, бандлы пакуют переиспользуемые наборы, а рабочие процессы автоматизируют повторяемые процессы. Сам Spec Kit проводит идею SDD через прослеживаемую цепочку артефактов — от принципов проекта и спецификаций функций до планов, задач, кода и тестов.

Пресеты, расширения, бандлы

Пресеты — это складывающиеся в стек переопределения шаблонов, команд, подсказок и терминологии с приоритетным порядком: они адаптируют результаты работы SDD — спецификации, планы, задачи, чек-листы и конституции, — не изменяя ядро. Документация уточняет механику: команда `specify preset add` ставит пресет из каталога, по URL или из локального каталога, а флаг `--priority N` задаёт приоритет разрешения — по умолчанию 10, и меньшее значение означает более высокий приоритет. Поэтому организация может совместить базовый стандарт с отраслевыми, технологическими и проектными надстройками.

Расширения вводят поведение за пределами встроенного жизненного цикла: доменные команды, интеграции, контроль качества, шаблоны, скрипты и хуки. Примеры в статье — команда проверки безопасности, гейт валидации доступности, интеграция с внутренней системой управления работой и сценарий разбора багов. Ставятся они командой `specify extension add`, а при поиске доступен фильтр `--verified`, показывающий только проверенные расширения.

Бандлы собирают пресеты, расширения и рабочие процессы в одну версионируемую устанавливаемую единицу и не добавляют собственного поведения во время выполнения: это слой распространения и композиции над примитивами. Описание бандла — манифест `bundle.yml`; установка разрешает объявленные компоненты по закреплённым версиям, проверяет единственную точку конфликта между бандлами (активную интеграцию) и применяет компоненты идемпотентно с полным отслеживанием происхождения, чтобы набор можно было так же чисто обновить или удалить.

Рабочие процессы и человеческие проверки

Рабочие процессы превращают отдельные возможности в повторяемые процессы: они связывают команды, подсказки и скрипты, включают точки, где требуется человек, поддерживают условные ветки и циклы и умеют останавливаться и продолжаться на время проверки.

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

Каталоги как граница безопасности

Расширяемость полезна только тогда, когда команды могут найти и проверить то, что устанавливают, поэтому в статье предложены два слоя каталогов. Корпоративный каталог контролируется организацией, проходит проверку, доступен для установки и получает самый высокий приоритет разрешения, становясь источником по умолчанию для одобренных пресетов и расширений; общественный каталог полезен для изучения и вдохновения, но по умолчанию оставлен только для обнаружения.

Разделение описано именно как граница безопасности: смотреть можно широко, а установка остаётся привязанной к проверенным источникам. Автор предупреждает, что запись в каталоге подтверждает формат и метаданные, но не является проверкой кода на безопасность и не означает одобрения; корпоративный каталог при этом может требовать соблюдения стандартов вклада, происхождения, защиты от инъекций в подсказки и документированного владельца.

Слоёная конституция и как это внедрять

Тот же принцип слоёв предложено применить к конституции проекта, чтобы не заставлять каждую команду писать инженерные принципы с нуля: базовый уровень организации с неотменяемыми ожиданиями, отраслевой и технологический оверлей с правилами под конкретный домен, платформу, язык или архитектуру и правки команды для точечных исключений. Стандартные правила при этом применяются автоматически, когда команда готовит новую конституцию, а сама команда может добавлять или переопределять отдельные пункты.

Единственный конкретный пример расширения, приведённый в статье, — видимость и оптимизация расхода токенов: расширение собирает использование после каждого запуска, показывает тренды и подсказывает оптимизацию при превышении порогов, не меняя основной жизненный цикл SDD. Тот же шаблон, по словам автора, подходит для проверок доступности, обзоров безопасной разработки, управления зависимостями, качества документации и проверки состояния сервисов.

Практические рекомендации статьи: начать с базового уровня конституции и контролей, применять пресеты для политики и терминологии, расширения — для новых возможностей, каждое из которых остаётся сфокусированным, документированным, версионируемым и независимо тестируемым; проверять владельца, источник, права, подсказки, скрипты и практику обновлений до разрешения установки; упаковывать проверенные комбинации в бандлы и автоматизировать только то, что понято. Итоговое правило — держать кастомизацию модульной, а ядро нетронутым: это сохраняет возможность обновления, делает происхождение видимым и не даёт локальным улучшениям превратиться в долгие форки.