Зачем это нужно
Уроки 16.3-16.7 разобрали три first-party процесса Spec Kit. Гайд кастомизации начинается ключевой фразой: это стартовые точки, а не пределы. Можно сохранить встроенный SDD, добавить багфикс или оценку, адаптировать процесс под организацию - или принести полностью другой процесс.
Проблема новичка: у Spec Kit четыре строительных блока (extensions, presets, workflows, bundles) плюс project-local оверрайды, и неочевидно, какой блок для какой задачи. Этот урок - карта выбора. Детальный разбор каждого блока - в уроках 16.12-16.15; здесь - логика выбора и порядок резолюции, связывающий все блоки в одну систему.
Основная идея
Выбор блока определяется целью изменения:
| Цель | Блок |
|---|---|
| Добавить новую команду, возможность или процесс | Extension |
| Интегрировать внешний инструмент или сервис | Extension |
| Изменить формат или терминологию спек, планов, задач | Preset |
| Привить организационные/регуляторные стандарты к существующим шаблонам | Preset |
| Дистрибутировать переиспользуемые доменные шаблоны | Presets для оверрайдов; extensions для шаблонов при новых командах |
| Разовая подгонка шаблона в одном проекте | Project-local override |
| Автоматизировать многошаговый процесс | Workflow |
| Развернуть законченный role-based setup одной операцией | Bundle |
Расширения: добавить возможности
Расширения расширяют что Spec Kit умеет: команды, шаблоны, скрипты и хуки. Они добавляют доменные процессы, внешние интеграции или фазы разработки за пределами ядра.
specify extension search
specify extension add <extension-name>
Примеры: интеграция с Jira, post-implementation код-ревью, трассируемость тестов V-Model, диагностика здоровья проекта. Bundled-расширения bug (урок 16.6) и assess (урок 16.7) - first-party примеры. Каталог расширений сообщества - урок 16.19; управление и конфигурация - урок 16.12.
Пресеты: изменить работу процесса
Пресеты переопределяют шаблоны и команды, поставляемые ядром и установленными расширениями. Они кастомизируют артефакты и инструкции, не требуя нового тулинга.
specify preset search
specify preset add <preset-name>
Сценарии: потребовать регуляторную трассируемость, навязать test-first порядок задач, добавить ворота security-ревью в планы, локализовать workflow. Пресеты адаптируют методологию к Agile, Kanban, Waterfall, jobs-to-be-done, domain-driven design; демо pirate-speak показывает, как глубоко можно сменить терминологию. Пресеты наслаиваются с приоритетами - разбор композиции в уроке 16.13.
Project-local оверрайды и резолюция
Для разовой кастомизации одного проекта кладите оверрайд шаблона в .specify/templates/overrides/ вместо создания переиспользуемого пресета. Дефолтный порядок замены:
1. Project-local overrides (.specify/templates/overrides/)
2. Установленные пресеты (в порядке приоритета)
3. Установленные расширения (в порядке приоритета)
4. Core-шаблоны Spec Kit (.specify/templates/)
Шаблоны резолвятся в момент необходимости: берется первый матч. Команды устроены иначе - установка расширений и пресетов материализует файлы команд в каталог активной интеграции; агенты не пересобирают стек при каждом вызове. Удаление перекрывающего компонента восстанавливает уцелевший слой команд через reconciliation.
Без кастомизаций действуют дефолты ядра. Авторитетный гайд по путям, приоритетам и композиции prepend/append/wrap - справочник пресетов, урок 16.13.
Бандлы: role-based наборы
Бандл пакует курированный набор расширений, пресетов, workflows и workflow-шагов в один версионируемый setup для роли или команды. Манифест bundle.yml пинит компоненты и может нацеливаться на интеграцию; интеграция-агностичный бандл наследует активную интеграцию проекта.
specify bundle search
specify bundle info <bundle-id>
specify bundle install <bundle-id>
Перед установкой смотрите info - он показывает резолвленный набор компонентов. Примеры манифестов в репозитории - наборы для продакт-менеджера, бизнес-аналитика, security-исследователя и разработчика. Обновления, удаление, каталог-политики, offline-ограничения и публикация - урок 16.15.
Автоматизация и шаринг
Четвертый блок - workflows: автоматизация многошаговых процессов цепочками команд, промптов и shell-шагов с человеческими чекпойнтами. Полный справочник - урок 16.14; напомним, что first-party бандлы assess и bugfix сами построены как «расширение + resumable workflow + ворота ревью» (урок 16.4).
Шаринг кастомизаций: компоненты сообщества поддерживаются независимо. Ревьюйте исходный код до установки и используйте на свое усмотрение. Гайд сообщества (урок 16.19) - как находить компоненты и публиковать свои.
Практика
- Сформулируйте три реальные кастомизации для своего проекта (например: терминология ГОСТ, интеграция с трекером, ворота security-ревью) и определите по таблице урока подходящий блок для каждой.
- Сделайте project-local оверрайд любого core-шаблона в
.specify/templates/overrides/и проверьте порядок резолюции: оверрайд применился; после удаления файла вернулся core-шаблон. - Найдите в
specify bundle searchбандл для своей роли и изучите его набор черезspecify bundle info- без установки.
Краткое резюме
Кастомизация Spec Kit - выбор правильного блока: extensions добавляют возможности (новые команды и процессы), presets меняют работу существующего (шаблоны, терминология, стандарты), workflows автоматизируют многошаговость, bundles развертывают все сразу для роли. Разовая подгонка - project-local оверрайд без создания пресета. Стек резолюции шаблонов: оверрайды -> пресеты -> расширения -> ядро; команды материализуются в каталог интеграции и reconciliation-ятся при изменениях.
Главное из урока:
- три first-party процесса - стартовые точки, не пределы: процесс можно адаптировать или заменить целиком;
- блок выбирается целью: «добавить» - extension, «изменить существующее» - preset, «упаковать» - bundle;
- оверрайды проекта - самый дешевый способ разовой кастомизации, без дистрибуции;
- шаблоны резолвятся лениво, команды материализуются - это ключевая разница двух стеков;
- компоненты сообщества независимы: ревью до установки обязательно.
Вопросы для самопроверки
- Перечислите четыре строительных блока и по одному критерию выбора для каждого.
- Чем пресет отличается от расширения, когда речь о дистрибуции доменных шаблонов? Почему различие «с новыми командами / без новых команд» важно?
- Опишите порядок резолюции шаблонов. Почему project-local оверрайд побеждает пресет?
- Почему команды не пересобирают стек при каждом вызове? Что происходит при удалении перекрывающего компонента?
- Что пинит манифест
bundle.yml? Что наследует интеграция-агностичный бандл? - Какие_first-party процессы сами построены на блоках кастомизации? Как именно?
Что дальше
Первый блок подробно: урок 16.12 - жизненный цикл расширений (поиск, установка из каталога/URL/локальной директории, приоритеты, enable/disable), модель доверия каталогов и конфигурация хуков.