Зачем это нужно
Быстрый старт (урок 16.3) показывает SDD на учебном примере. Но у большинства читателей возникает практический вопрос: как это выглядит в живом проекте - где агенты, где люди, где обычная автоматизация, и что из этого обязательно? Документация Spec Kit отвечает кейс-стади самой себя: разработка Spec Kit сочетает агентную работу с конвенциональной delivery, и все воркфлоу публичны.
Этот урок важен еще и потому, что задает калибровку ожиданий: проект явно разделяет «агентная работа» и «детерминированная автоматизация», показывает человеческие ворота на каждом переходе и подчеркивает, что это практика одного проекта, а не предписанный рецепт.
Основная идея
Собственная разработка Spec Kit combines агентную и конвенциональную работу: агенты оценивают запросы фич, помогают делать существенные изменения и исследуют баг-репорты. Там, где процессы Spec Kit подходят, проект использует сам Spec Kit (догфудинг). При этом детерминированные тесты и релизы остаются обычными GitHub Actions, а решения «продолжать или мержить» принимают мейнтейнеры - люди.
Карта SDLC проекта
Традиционные стадии располагают практики проекта вдоль жизненного цикла:
Это карта, а не обязательная последовательность. Работа может начаться там, где требуют исходный материал и цель: запрос фичи - в planning, существующее изменение - в testing, баг-репорт - в maintenance. Стадии могут перекрываться, повторяться или пропускаться; один issue с фичей может питать оценку, фиксировать требования и нести дизайн-обсуждение. Стрелки показывают один привычный путь, а не обязательные переходы. Обратная связь из maintenance информирует следующий цикл planning.
Кто делает работу
Три режима - иллюстрация того, как здесь делается работа; это не исчерпывающая таксономия, и стадия может комбинировать режимы.
Обычная автоматизация. Скрипты и боты следуют предопределенным правилам: гоняют проверки, предлагают обновления зависимостей, публикуют релизы. Они не интерпретируют запросы фич и не выбирают дизайн.
Агентная автоматизация. Coding-агент интерпретирует контекст и производит оценку, SDD-артефакты, предлагаемое изменение или тест-отчет. Это может происходить через команду Spec Kit, вызванную контрибьютором, собственного агента контрибьютора или workflow репозитория, запущенный меткой. Запуск агента на GitHub Actions не превращает его рассуждение в детерминированный скрипт.
Человеческая работа. Люди формулируют issue, обсуждают подходы, пишут и правят изменения, ревьюят подтверждения - с помощью агента или без. Мейнтейнеры вешают метки для запуска workflow репозитория и решают, продолжать или мержить. Эти передачи - человеческие решения, а не доказательство, что каждый текст написал человек.
Обозначения дальше по уроку: агентная работа отмечается звездочкой (★), человеческие вклады - иконкой человека.
Стадии в деталях
1. Planning: оценка запросов фич
Фича входит в planning через форму feature request: проблема, предлагаемое решение, альтернативы, компонент, сценарии использования. Issue стартует с меткой needs-triage; его создание не запускает агента автоматически.
★ Когда на запрос фичи вешают метку оценки, агентный workflow feature-assess поднимает Specify CLI из checkout, ставит bundled-расширение assess (урок 16.7) и проходит его стадии: intake, research, define, shape, decide. Агент постит на issue свои подтверждения и вердикт go, needs-clarification или kill. Это агентный workflow, использующий сам Spec Kit.
Человеческое: контрибьюторы формулируют запрос; мейнтейнеры решают, запускать ли оценку и что делать с вердиктом. Вывод go информирует решение по планированию, но не открывает автоматически PR фичи и не запускает SDD.
2. Requirements: фиксация намерения
Контрибьюторы могут зафиксировать ранние требования прямо в issue: формулировка проблемы, сценарии использования, критерии приемки - и уточнять намерение в обсуждении. Для ограниченного изменения этого может хватить; оно не обязано превращаться в SDD spec.md.
★ Для существенных изменений контрибьюторы могут развернуть требования командами ядра SDD против конституции проекта. Spec Kit применял это к себе в исторической работе над бандлером: коммит содержит конституцию и спецификацию фичи для команды specify bundle. Это свидетельство SDD-догфудинга для той фичи; работа над бандлером отдельна от нынешнего feature-assess workflow. Гайд для контрибьюторов просит тестировать релевантные изменения через SDD, оставляя мелким фиксам обычный issue/PR-процесс. Сгенерированные артефакты specs/ обычно gitignore-ятся; коммит сохраняет исторический снапшот.
3. Design: выбор подхода в нужном масштабе
Предлагаемое решение и альтернативы из формы фичи засеивают дизайн-обсуждение; контрибьюторы и мейнтейнеры доуточняют подход в ревью PR. Отдельный SDD-план не требуется для каждого issue. Крупные изменения требуют предварительного обсуждения и согласия с мейнтейнерами. Когда решения должны служить многим изменениям, репозиторий держит дизайн-документы: CLI, integration, workflow-step.
★ Снапшот SDD-работы бандлера иллюстрирует глубокий путь: его план, исследование, модель данных, контракты и задачи сделали дизайн выполнимым через /speckit.plan и /speckit.tasks. Это показывает, где применялся сам Spec Kit - без предъявления такой детальности как нормы для каждого изменения.
4. Development: проверяемые изменения
Реализация бандлера добавила specify bundle после зафиксированной SDD-работы - конкретная фича, ведомая спецификацией. Остальные ограниченные изменения идут через обычный процесс issue, PR, ревью, тесты.
Контрибьюторы могут реализовывать и править изменения напрямую или с помощью агента. Мейнтейнеры ревьюят PR и его подтверждения, даже если изменение предложено агентом.
★ Контрибьюторы могут использовать собственных агентов независимо от workflow репозитория. Поскольку такая работа может быть не видна в diff, политика контрибуций требует раскрывать инструмент, модель, настройки/режим и степень AI-помощи. Коммиты и комментарии, authored агентами, требуют собственной атрибуции; известные bug-fix и community-catalog workflow исключены - их агентская идентичность самоочевидна. Раскрытие дает происхождение (provenance), но не снижает планку проверки и ревью.
5. Testing: проверка и намерения, и поведения
★ Работа бандлера включает convergence-проход, дописавший пропущенную задачу - пример того, как SDD-процесс сверяет реализацию с намерением, вместо того чтобы считать первый проход финальным. Workflow bug-test использует агента для выбора релевантных тестов, но сами тест-команды выполняются детерминированно.
Параллельно обычные GitHub Actions гоняют на PR и push в main Python-тесты с Ruff, Markdown-lint документации со ShellCheck для шелл-скриптов и CodeQL. Агентная конвергенция дополняет эти независимые проверки, а не заменяет их.
Человеческое: контрибьюторы прикладывают тесты и репродукшн-подтверждения; мейнтейнеры оценивают, закрывают ли патч и подтверждения заявленную потребность - не только «зеленые ли проверки».
6. Deployment: публикация без агента
Репозиторий использует обычные GitHub Actions: вручную диспатчимый release-trigger ставит версию, создает тег и открывает release PR; тег запускает конвенциональный GitHub Release; отдельный workflow собирает и публикует на PyPI; изменение в docs/ на main триггерит деплой DocFX. delivery-конвейер детерминирован - без агента и без команд Spec Kit.
Мейнтейнеры выбирают момент релиза и версию (вместо автоматического патч-инкремента), позже диспатчат публикацию PyPI и ревьюят release PR.
7. Maintenance: исследовать, чинить, учиться
Репортеры дают наблюдаемое и ожидаемое поведение и шаги воспроизведения через форму баг-репорта. Мейнтейнеры триажируют, выбирают, когда запрашивать каждый агентный шаг, и ревьюят предлагаемый фикс и тест-подтверждения до мержа. Репорты могут возникать до или после релиза; вновь найденная потребность может питать следующий цикл planning, а не вливаться в ремонт.
★ Репозиторий держит отдельные агентные workflow bug-assess, bug-fix и bug-test на issue. Они разделяют диагностику, remediation и верификацию с контролируемыми людьми передачами; фикс предлагается draft-PR на ревью мейнтейнеров. Сегодня эти workflow проекта не используют bundled-расширение bug (урок 16.6), хотя оно дает пользователям соответствующий процесс assess-fix-test; переход workflow на расширение - направление будущей работы, а не текущая возможность.
И агентные, и обычные workflow работают на GitHub Actions - меняется то, интерпретирует ли агент подтверждения и предлагает ли изменение. Dependabot еженедельно предлагает PR обновления pip и Actions-зависимостей; это обычная автоматизация, не агентный workflow.
Расширяемость и практика сообщества
Расширяемость пронизывает весь SDLC: проект не только использует процессы, но и строит, и дистрибутирует их. Команда шипит бандлы assess и bugfix - каждый сочетает расширение с возобновляемым Spec Kit workflow и воротами человеческого ревью - и пресет lean, демонстрирующий альтернативную нарезку core-руководств SDD. Это собственные extensions, presets, workflows и bundles Spec Kit (уроки 16.11-16.15), а не GitHub Actions проекта.
★ Помимо основной доставки фич, агентные workflow community-сабмишенов (расширения, пресеты, бандлы) валидируют метаданные заявки и предлагают изменения каталогов в draft-PR на ревью мейнтейнеров.
Каталожное обнаружение не аудирует и не одобряет код сообщества: пользователи обязаны ревьюить сторонние компоненты перед использованием.
От SDLC к agentic SDLC: хронология
Агентные практики наслаивались на существующий SDLC, а не заменяли обычные проверки и релизы. История коммитов показывает, как смешивались режимы; ниже - выбранные вехи (★ - агентные вехи, включая использование SDD), а не исчерпывающий changelog.
| Месяц | Что изменилось |
|---|---|
| Август 2025 | Автоматизация GitHub Release |
| Сентябрь 2025 | Деплой документации; гайд контрибуций начал требовать раскрытия AI-помощи, включая агентов контрибьюторов |
| Октябрь 2025 | Markdown-lint в PR и проверках main |
| Февраль 2026 | Dependabot - еженедельные PR обновлений; CodeQL; Pytest CI; Ruff в Python CI |
| Май 2026 | ★ Сабмишены расширений и пресетов получили валидацию каталогов и draft-PR |
| Июнь 2026 | ★ Агентный workflow bug-assess; ★ фича бандлера прошла через SDD-процесс Spec Kit (спецификация, план, задачи); конвенциональный workflow публикации PyPI; ShellCheck в CI |
| Июль 2026 | ★ Bug-fix - агентный workflow с человеческой передачей; ★ bug-test - отдельная стадия верификации; ★ сабмишены бандлов получили автоматизацию каталогов |
| Август 2026 | ★ Workflow feature-assess начал использовать расширение assess на запросах фич |
| Сентябрь 2026 | Раскрытие AI стало требовать агент, модель, настройки и степень; руководство контрибуций добавило атрибуцию для agent-authored коммитов и комментариев |
Это не был переход от обычной автоматизации к агентам. Тесты, lint, сканирование и публикация оставили повторяемую работу в GitHub Actions; раскрытие сделало агентов контрибьюторов видимыми. Проект добавил агентные каталог- и баг-workflow для ограниченных задач, прогнал существенную фичу через SDD и затем подключил assess к оценке запросов. Это отдельные добавления, а не шаги, обязательные для каждого issue.
В сумме проект получил выбор. Для фич assess информирует человеческое решение по запросу; существенная реализация может пройти SDD для спецификации и планирования, как бандлер. Автоматической передачи между процессами нет. Малое изменение остается в issue и PR; баг движется через контролируемые людьми оценку, ремонт и верификацию. Код все равно проходит обычные проверки и ревью мейнтейнеров; вердикты на issue и каталог-предложения имеют собственные человеческие ворота.
Практика, а не рецепт
Для публичного open-source проекта новый issue - недоверенный ввод, а не разрешение запускать агента. Мейнтейнер активирует каждый принадлежащий репозиторию агентный workflow меткой и решает, когда работа двигается; контрибьюторы могут приносить собственных агентов - при раскрытии и ревью. Это сознательные границы данного проекта, а не внутренние пределы Spec Kit.
Закрытый проект с другой моделью доверия мог бы автоматизировать больше передач между оценкой, спецификацией, реализацией и тестированием, сохраняя права, подтверждения и ревью, соразмерные риску. Продакшн-микс Spec Kit - не предписанный рецепт: команды могут внедрять агентов в разных местах, с процессами Spec Kit или без. Микс может меняться вместе с потребностями проекта.
Здесь «агентный» не значит «без людей»: контрибьюторы по-прежнему приносят проблемы, требования и изменения; мейнтейнеры рулят направлением продукта и ревьюят подтверждения. Обычная автоматизация держит повторяемые проверки и публикацию; агенты помогают с ограниченной работой, требующей интерпретации. Разделение нацелено на то, чтобы человеческое время уходило на суждения, хотя хронология показывает внедрение, а не измеренную экономию времени.
Практика
- Составьте для своего проекта (или команды) таблицу из трех колонок: «обычная автоматизация», «агентная автоматизация», «человеческие решения» - по стадиям SDLC. Сравните с этим уроком: где у вас лишняя автоматизация там, где нужно суждение?
- Найдите в таблице-хронологии месяц, когда проект впервые использовал SDD на себе. Какие артефакты той работы упомянуты и почему они сохранены в коммите, хотя
specs/обычно игнорируется? - Сформулируйте, какие именно передачи в вашем процессе должны остаться человеческими воротами, а какие можно доверить агенту - по образцу стадий 1 и 7 этого урока.
Краткое резюме
Agentic SDLC Spec Kit - это наслоение агентных практик на обычный жизненный цикл, с человеческими воротами на каждом переходе. Агенты оценивают запросы фич (через собственное расширение assess), исследуют баги (bug-assess/bug-fix/bug-test) и делали существенную фичу (бандлер) через полный SDD. Тесты, lint, сканирование и релизы остались детерминированными GitHub Actions; раскрытие AI-помощи делает агентов контрибьюторов проверяемыми.
Главное из урока:
- три режима работы - обычная автоматизация, агентная автоматизация, человеческая работа - могут комбинироваться на одной стадии;
- автоматической передачи между процессами нет: вердикт
goне открывает PR,assessне запускает SDD; - SDLC - карта, а не конвейер: работа начинается там, где находится исходный материал;
- использование процессов на себе (догфудинг) доказано публичными артефактами, но не является нормой для каждого изменения;
- границы доверия проекта - сознательный выбор, не пределы инструмента.
Вопросы для самопроверки
- Чем агентная автоматизация отличается от обычной в терминах этого урока? Почему «запуск на GitHub Actions» не делает workflow детерминированным?
- Опишите путь запроса фичи от формы до вердикта. Какие решения на этом пути остаются за людьми?
- Что требовала политика раскрытия AI-помощи к сентябрю 2026? Какие workflow освобождены от раскрытия и почему?
- Как работа над бандлером доказывает догфудинг SDD? Какие артефакты это подтверждают?
- Почему workflow bug-assess/fix/test проекта не считаются использованием расширения
bug? - Почему новый issue в публичном репозитории называют «недоверенным вводом»? Как это влияет на автоматизацию передач?
Что дальше
Процессы показаны в динамике; теперь - систематический справочник. Урок 16.5 разбирает все агентные команды /speckit.* ядра SDD: аргументы, артефакты, выход, условия обязательности и вариации вызова.