Обзор инструментов и свой процесс

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

За один только 2026 год в мире SDD-инструментов случилось вот что. Spec Kit перевёл команды на навыки и удалил старый ключ --ai. OpenSpec в версии 1.0 (январь 2026) пересобрал весь процесс и сменил команды с /openspec:proposal на /opsx:propose. Agent OS в версии 3 перестал писать спецификации сам и отдал эту работу режиму планирования агента. Tessl, который в 2025 году был примером «спецификации как исходника», теперь называет себя платформой для того, чтобы давать агентам недостающий контекст. Выученные наизусть команды устаревают за полгода.

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

Дата проверки

Факты об инструментах сверены с их репозиториями на GitHub 6 октября 2026 года. Сайты kiro.dev и tessl.io из нашей среды недоступны, поэтому о том, чего нет в репозиториях, урок говорит осторожно и с пометкой «общеизвестно» или «по статье Бёккелер». Перед выбором инструмента проверьте его README заново.

Как оценивать инструмент: шесть вопросов

В уроке SDD.1.1 были три уровня по Биргитте Бёккелер: spec-first, spec-anchored, spec-as-source. Её статья «Understanding Spec-Driven-Development: Kiro, spec-kit, and Tessl» — лучшая отправная точка для этого урока: она разбирает три инструмента на реальных задачах и честно говорит о цене — многословии, ложном чувстве контроля, параллелях с model-driven development. Прочитайте оригинал целиком; ниже только то, что нужно для нашей карты.

К любому инструменту задайте шесть вопросов:

1. Уровень. Что происходит со спецификацией после реализации: выбрасывается, развивается вместе с кодом или остаётся единственным исходником?
2. Артефакты. Какие файлы, в каких папках, в каком формате? Обычный markdown в репозитории или что-то своё?
3. Агенты. С какими агентами работает? Привязан ли к своей IDE, облаку или модели?
4. Лицензия и данные. Открытый код или продукт? Где хранятся спецификации, нужна ли учётная запись?
5. Цена процесса. Сколько шагов и документов на правку в одну строку? Есть ли короткий путь?
6. Как проверено. Вы видели это в репозитории и документации или прочитали в чьём-то сравнении?

Последний вопрос важнее, чем кажется. В README OpenSpec есть раздел «How we compare», где про Kiro сказано: «you’re locked into their IDE and limited to Claude models». А README самого Kiro на октябрь 2026 перечисляет IDE, CLI, веб и мобильный клиент. Сравнение от конкурента — реклама, и оно стареет быстрее, чем вы его прочитаете.

Kiro

Проверено по репозиторию kirodotdev/Kiro. KiroKiroEN Kiro (AWS)Платформа агентной разработки Amazon: среда разработки, CLI, веб и мобильный клиент. Режим спецификаций ведёт фичу через требования, дизайн и задачи; steering-файлы хранят правила проекта. Исходный код продукта закрыт; публичный репозиторий kirodotdev/Kiro — трекер ошибок и идей. — продукт Amazon. README описывает его как платформу агентной разработки, которая помогает планировать, строить и ревьюить софт и «превращать промпты в исполняемые спецификации». Сам репозиторий — публичный трекер ошибок и идей: исходников продукта в нём нет, внизу README — «All Rights Reserved». Поверхностей пять: IDE, CLI, Web (задачи в облачных песочницах), Mobile и Kiro Crew — открытое постоянное рабочее пространство. Из возможностей, связанных с SDD:

• Specs — структура для требований, проектных решений и задач реализации;
• Requirements Analysis — поиск противоречий, двусмысленностей и пробелов в требованиях до кода;
• проверка корректности через property-based testing — требования превращаются в исполняемые свойства и проверяются на сгенерированных входах;
• Steering — соглашения проекта, которые агент учитывает всегда (steering-файлыsteering-файлы (управляющие документы проекта)EN steering filesТермин Kiro: markdown-файлы с постоянным контекстом проекта — назначение продукта, стек и соглашения, структура кода. Агент учитывает их в каждой задаче. В cc-sdd лежат в .kiro/steering/ (по умолчанию product.md, tech.md, structure.md). Близкий аналог — CLAUDE.md и AGENTS.md.);
• хуки на события агента, Agent Skills, MCP, права доступа, файл .kiroignore и контрольные точки с откатом.

Общеизвестно, но не проверено нами по документации Kiro. Спецификации фичи лежат в .kiro/specs/<фича>/ тремя файлами — requirements.md, design.md, tasks.md, а steering-файлы — в .kiro/steering/. Требования пишутся как истории с критериями приёмки в нотации EARSEARS (шаблоны формулировок требований)EN Easy Approach to Requirements SyntaxНесколько шаблонов предложения для требования: «Система должна …», «Когда <событие>, система должна …», «Пока <состояние>, …», «Если <нежелательное событие>, то …». Предложены Алистером Мавином и соавторами (Rolls-Royce, 2009). («WHEN … THE SYSTEM SHALL …», подробно — в уроке SDD.2.1). Эту раскладку косвенно подтверждает cc-sdd (о нём ниже): он совместим со спецификациями Kiro и создаёт ровно такие папки.

Как встраивается в другие инструменты. У Spec Kit есть интеграция kiro-cli, у OpenSpec — инструмент kiro: процесс любого из них можно запускать внутри Kiro.

Tessl

По статье Бёккелер (2025). TesslTesslEN TesslКомпания и платформа для «обучения» агентов контекстом: CLI tessl, реестр спецификаций с документацией библиотек, «тайлы» — пакеты навыков, правил и документов. В 2025 году исследовала уровень spec-as-source (по статье Бёккелер); на октябрь 2026 у неё есть открытый тайл spec-driven-development (MIT). — пример движения к третьему уровню, spec-as-source: человек правит спецификацию, а код генерируется из неё и вручную не редактируется. Это самая радикальная и наименее проверенная практикой идея SDD. Параллель с model-driven development, о которой шла речь в уроке SDD.1.1, здесь самая прямая.

Проверено по репозиториям организации tesslio на GitHub, октябрь 2026. README репозитория tesslio/cli называет Tessl «Agent Enablement Platform», которая даёт агентам недостающий контекст: документацию по открытым библиотекам из реестра Tessl Spec Registry и ваши внутренние документы. Ставится CLI скриптом с get.tessl.io; открытой лицензии в репозитории CLI нет, есть условия использования и политика конфиденциальности. Пакеты контекста называются тайлами (tiles). Один из них — открытый тайл tessl-labs/spec-driven-development (MIT):

• навыки requirement-gathering, spec-writer, spec-verification, work-review;
• правила spec-before-code («никакой реализации без одобренной спецификации») и one-question-at-a-time;
• установка tessl install tessl-labs/spec-driven-development кладёт файлы тайла в папку .tessl/ проекта, их читает агент, совместимый с MCP.

Спецификации в этом тайле — файлы .spec.md с YAML-шапкой, где targets указывает, какие файлы кода описывает спецификация, а ссылки [@test] ведут к тестам каждого требования. Фрагмент формата из README тайла (MIT):

---
name: User Authentication
description: Login and session management
targets:
  - ../src/auth/*.py
---

## Error Handling

- Invalid credentials return 401
  [@test] ../tests/auth/test_invalid_credentials.py

Заметьте: связка «требование → тест» прямо в спецификации — та же трассируемостьтрассируемостьEN traceabilityВозможность пройти по ссылкам от требования к сценарию, задаче, тесту и коду и обратно. Держится на идентификаторах (REQ-001, SC-001, T-001) и позволяет автоматически найти требования без задач и задачи без требований., которую вы делали идентификаторами в модуле SDD.2. Уровень этого тайла — скорее spec-anchored: после работы спецификации обновляются найденными требованиями, а код пишет и правит агент.

BMAD-METHOD

Проверено по репозиторию bmad-code-org/BMAD-METHOD (релиз v6.12.0 от 3 сентября 2026, MIT). BMAD-METHODBMAD-METHODEN BMad Method (Agile AI Driven Development)Открытый метод и набор навыков (bmad-code-org/BMAD-METHOD, MIT): агенты-роли аналитика, продакт-менеджера, архитектора, UX-дизайнера и разработчика, документы бриф, PRD, архитектура, спецификация, тикеты. Объём планирования подбирается под размер работы. называет себя «Agile AI Driven Development»: способ провести идею или запрос на изменение до работающего софта, «не отказываясь от мышления». Главная мысль README: процесс подбирается под размер работы — маленькие изменения идут сразу в сборку, сложные получают столько планирования, сколько нужно.

Устроен как набор навыков агента. Планирование — bmad-product-brief (бриф продукта), bmad-prd (PRD — документ требований к продукту), bmad-ux, bmad-architecture, bmad-spec («сжать любое намерение в короткий контракт»), bmad-ticket (эпики и истории); реализация — bmad-build. Есть агенты-роли: аналитик, продакт-менеджер, архитектор, UX-дизайнер, разработчик, а также обсуждения с участием нескольких агентов. Документы складываются в папку _bmad-output (по умолчанию). Ставится командой npx skills add bmad-code-org/BMAD-METHOD или через маркетплейс плагинов Claude Code и Codex; для настройки нужен uv. Документация честно пишет: для очевидной правки с низким риском BMad не нужен.

cc-sdd

Проверено по репозиторию gotalab/cc-sdd (версия 3.1.0, MIT). cc-sddcc-sddEN cc-sddОткрытый набор навыков (gotalab/cc-sdd, MIT), повторяющий процесс Kiro в других агентах: steering, затем requirements.md в нотации EARS, design.md и tasks.md в .kiro/specs/имя/, затем автономная реализация с отдельным ревьюером на каждую задачу. — «вдохновлённый Kiro» набор из 17 навыков, который приносит процесс Kiro в другие агенты: Claude Code и Codex — стабильно, Cursor, Copilot, Devin, OpenCode, Gemini CLI и Antigravity — в бете. Установка: npx cc-sdd@latest в папке проекта (по умолчанию — навыки Claude Code); есть ключ языка документов, в том числе --lang ru.

Процесс: /kiro-discovery решает, нужна ли спецификация вообще, затем kiro-spec-init → kiro-spec-requirements → kiro-spec-design → kiro-spec-tasks → kiro-impl. Файлы — в .kiro/steering/ (по умолчанию product.md, tech.md, structure.md) и .kiro/specs/<фича>/: requirements.md в формате EARS, design.md с планом структуры файлов, tasks.md с метками параллельности (P) и границами задач. kiro-impl на каждую задачу запускает свежего субагента с TDD и независимого ревьюера, если агент умеет субагентов.

Ценно, что README честно пишет, когда cc-sdd не нужен: одиночная работа, которая укладывается в одну сессию агента; прототипы и одноразовый код; задачи, где вайб-кодинг действительно быстрее. А /kiro-discovery может законно ответить «спецификация не нужна, делайте сразу». Позиция авторов: код остаётся источником истины, спецификация — контракт между частями системы.

Agent OS

Проверено по репозиторию buildermethods/agent-os (MIT). Agent OSAgent OSEN Agent OS (Builder Methods)Открытый набор команд (buildermethods/agent-os, MIT) для стандартов кода: найти их в кодовой базе, проиндексировать и подставлять агенту по ситуации. С версии 3 (январь 2026) сам спецификации не пишет, а дополняет режим планирования агента командой shape-spec. Брайана Казела в версии 3.0 (20 января 2026) сделал то, что редко делают авторы инструментов: убрал половину своих функций. В CHANGELOG сказано, что режим планирования Claude Code, расширенное мышление и улучшенные модели теперь сами справляются с тем, что раньше давали ранние версии: написание спецификаций лучше делать в режиме планирования, задачи агенты сами превращают в списки дел, оркестрацию реализации модели ведут сами.

Что осталось — стандарты кода: /discover-standards находит соглашения в кодовой базе и оформляет их в документы, /inject-standards подставляет нужные в контекст, /index-standards ведёт индекс. Плюс /plan-product (миссия, дорожная карта и стек в agent-os/product/) и /shape-spec — дополнение к режиму планирования: задаёт точные вопросы с учётом стандартов и сохраняет план в agent-os/specs/<дата-время-фича>/ (plan.md, shape.md, standards.md, references.md).

Как это у ИИ-агентов

Посмотрите на карту целиком: Spec Kit, OpenSpec, cc-sdd, BMAD и Agent OS — это прежде всего пакеты промптов (навыки и команды) плюс шаблоны, иногда с небольшой программой для детерминированных операций. Любой SKILL.md можно открыть и прочитать. Поэтому «свой процесс» — не бедная замена инструменту, а тот же механизм в миниатюре, который вы полностью контролируете.

Сравнительная таблица

Уровень указан по устройству инструмента на октябрь 2026 года; для Tessl — по статье Бёккелер и по README тайла.

Инструмент	Уровень	Артефакты	Агенты	Лицензия	Когда выбирать	Как проверено
Spec Kit	spec-first по умолчанию; spec-anchored, если команда ведёт living spec	конституция; на фичу — spec, plan, research, data-model, contracts, quickstart, tasks, чек-листы	42 интеграции	MIT	новый проект или крупная фича: нужны план, модель данных, контракты, общие принципы	репозиторий, локальный запуск (урок SDD.3.1)
OpenSpec	spec-anchored	openspec/specs/; на изменение — proposal, дельты, design, tasks	30+ (около 50 идентификаторов)	MIT	развитие существующей системы потоком небольших изменений	репозиторий, локальный запуск (урок SDD.3.2)
Kiro	папка на фичу, ближе к spec-first	требования, решения, задачи; steering	свой агент: IDE, CLI, веб, мобильный	закрытый продукт Amazon	хотите всё в одной среде и готовы к закрытому продукту	README репозитория; раскладка файлов и EARS — общеизвестно
Tessl	идея spec-as-source (по Бёккелер); тайл SDD — spec-anchored	.spec.md с targets и [@test]; тайлы в .tessl/	агенты с MCP: Claude Code, Cursor и др.	CLI — условия использования; тайл SDD — MIT	эксперименты; если уже пользуетесь реестром Tessl	README tesslio; об идее spec-as-source — по статье
BMAD-METHOD	spec-first/spec-anchored: бриф, PRD и архитектура живут как контекст	бриф, PRD, UX, архитектура, спецификация, тикеты в _bmad-output	агенты с навыками; плагины для Claude Code и Codex	MIT, товарный знак BMad Code	большая инициатива с ролями: продукт, архитектура, UX	README и документация
cc-sdd	spec-first на фичу; «код — источник истины»	.kiro/steering/; .kiro/specs/<фича>/ с requirements (EARS), design, tasks	8 агентов, Claude Code и Codex стабильно	MIT	нужен процесс в стиле Kiro в своём агенте, длинная автономная реализация	README и документация
Agent OS	сам спецификации не пишет; дополняет режим планирования	стандарты; agent-os/product/, agent-os/specs/<дата-фича>/	Claude Code, Cursor, Antigravity и др.	MIT	много проектов с общими стандартами кода	README и CHANGELOG
Свой процесс	какой договоритесь; обычно spec-first или living spec	specs/ с шаблонами, CLAUDE.md, свои команды	любой	ваша	начало работы, маленькая команда, учебный проект	—

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

Свой минимальный процесс

Многим командам хватает четырёх вещей: папки со спецификациями, шаблонов, файла памяти агента и нескольких промптов-команд. Agent OS 3.0 по сути признал то же самое. Всё, что для этого нужно знать, вы уже прошли: формат спецификации — в SDD.2.1, план — в SDD.2.2, задачи и принципы — в SDD.2.3, файл памяти, навыки и режим планирования — в SDD.1.2. Осталось собрать это в процесс.

Что лежит в репозитории

school/
├── CLAUDE.md                     # или AGENTS.md: правила проекта и раздел «Как мы работаем со спецификациями»
├── docs/glossary.md              # глоссарий школы: русский термин → имя в коде
├── scripts/new_spec.py           # создаёт папку новой фичи из шаблонов
├── specs/
│   ├── principles.md             # своя «конституция»: тесты сначала, единый язык, простота
│   ├── _templates/
│   │   ├── spec.md               # формат курса: Контекст, истории, REQ-…, SC-…, Вне рамок, Открытые вопросы
│   │   ├── plan.md
│   │   └── tasks.md
│   ├── 001-enrollment/           # уже сделанная фича
│   └── 002-waitlist/             # текущая фича: spec.md, plan.md, tasks.md
└── .claude/
    └── commands/                 # свои слэш-команды: spec-new, spec-plan, spec-tasks, spec-do

Раздел в файле памяти

Полный пример CLAUDE.md для школы — в уроке SDD.1.2. Для процесса достаточно добавить короткий раздел:

## Как мы работаем со спецификациями
- Фича живёт в specs/NNN-имя/: spec.md (что и зачем), plan.md (как), tasks.md (задачи).
- Принципы — specs/principles.md. Исключение из принципа — только с обоснованием в plan.md.
- Без одобренного человеком spec.md код не пишем.
- Порядок: /spec-new → ревью → /spec-plan → ревью → /spec-tasks → /spec-do по одной задаче, коммит после каждой.
- Поведение изменилось — сначала правим spec.md, потом код (живая спецификация).

Свои команды-промпты

В Claude Code свою слэш-команду кладут файлом в .claude/commands/<имя>.md — так устроены команды OpenSpec — или навыком .claude/skills/<имя>/SKILL.md — так устроены навыки Spec Kit (пример навыка write-spec — в уроке SDD.1.2). Слова после команды подставляются вместо $ARGUMENTS. Вот .claude/commands/spec-new.md:

---
description: Написать спецификацию новой фичи по шаблону курса
---
Фича: $ARGUMENTS

1. Код не пиши. Прочитай CLAUDE.md, docs/glossary.md и specs/principles.md.
2. Придумай короткое имя латиницей через дефис и выполни `python scripts/new_spec.py <имя>`.
3. Заполни spec.md по шаблону: требования REQ-…, сценарии SC-… «Дано / Когда / Тогда»
   со строкой «Требования:», раздел «Вне рамок».
4. Чего не знаешь — не придумывай: [УТОЧНИТЬ: вопрос] в «Открытые вопросы».
5. В конце задай мне не больше пяти вопросов с вариантами ответа и остановись.

Остальные команды устроены так же: spec-plan читает одобренный spec.md и пишет plan.md с проверкой по принципам; spec-tasks пишет tasks.md с идентификаторами, ссылками на REQ и метками параллельности; spec-do берёт одну задачу, сначала пишет тест по сценарию, потом код, запускает python -m pytest -q и останавливается для ревью и коммита.

Скрипт вместо CLI

Детерминированные операции лучше отдавать программе, а не модели, — один из уроков OpenSpec, где проверку формата и слияние умеет делать CLI. В своём процессе таких операций одна: создать папку со следующим номером из шаблонов. Двадцать строк Python:

"""Создаёт папку новой фичи в specs/ по шаблонам: specs/NNN-<имя>/{spec,plan,tasks}.md.

Запуск из корня репозитория:  python scripts/new_spec.py waitlist
"""
import re
import sys
from datetime import date
from pathlib import Path

SPECS = Path("specs")
TEMPLATES = SPECS / "_templates"
FILES = ("spec.md", "plan.md", "tasks.md")


def next_number(specs: Path) -> int:
    """Следующий свободный номер: ищем папки вида 001-имя и берём максимум + 1."""
    numbers = [int(m.group(1)) for p in specs.iterdir()
               if p.is_dir() and (m := re.match(r"(\d{3})-", p.name))]
    return max(numbers, default=0) + 1


def main(name: str) -> None:
    if not re.fullmatch(r"[a-z0-9]+(-[a-z0-9]+)*", name):
        sys.exit(f"Имя фичи — латиница в нижнем регистре через дефис, а не «{name}»")
    feature = SPECS / f"{next_number(SPECS):03d}-{name}"
    feature.mkdir()
    for file in FILES:
        text = (TEMPLATES / file).read_text(encoding="utf-8")
        text = text.replace("[FEATURE]", name).replace("[DATE]", date.today().isoformat())
        (feature / file).write_text(text, encoding="utf-8")
        print(f"создан {feature / file}")
    print(f"Дальше: заполните {feature / 'spec.md'} с агентом в режиме планирования")


if __name__ == "__main__":
    if len(sys.argv) != 2:
        sys.exit("Использование: python scripts/new_spec.py <имя-фичи>")
    main(sys.argv[1])

Вывод в репозитории, где уже есть specs/001-enrollment/ (запущено 6 октября 2026 года):

$ python scripts/new_spec.py waitlist
создан specs/002-waitlist/spec.md
создан specs/002-waitlist/plan.md
создан specs/002-waitlist/tasks.md
Дальше: заполните specs/002-waitlist/spec.md с агентом в режиме планирования
$ python scripts/new_spec.py "Лист ожидания"
Имя фичи — латиница в нижнем регистре через дефис, а не «Лист ожидания»

Чем такой процесс уступает инструментам? Нет готовых проверок вроде /speckit-analyze или openspec validate, нет слияния дельт — живую спецификацию придётся поддерживать дисциплиной и ревью. Чем выигрывает? Формат ваш (REQ и SC означают то же, что в курсе), шагов ровно столько, сколько нужно, и вы понимаете каждую строку.

Как выбирать и не гнаться за модой

flowchart TD
Q1{"Правка на один-два файла<br/>в одну сессию агента?"} -->|да| A1["режим планирования агента,<br/>без инструмента"]
Q1 -->|нет| Q2{"Живая система,<br/>поток небольших изменений?"}
Q2 -->|да| A2["OpenSpec или свой процесс<br/>с живой спецификацией"]
Q2 -->|нет| Q3{"Новый проект или большая фича:<br/>нужны план, модель данных, контракты?"}
Q3 -->|да| A3["Spec Kit или свой процесс<br/>с полным набором документов"]
Q3 -->|нет| A4["свой минимальный процесс"]
A3 -.-> R["несколько ролей, PRD для людей → BMAD-METHOD;<br/>всё в одной среде → Kiro;<br/>процесс Kiro в своём агенте → cc-sdd;<br/>общие стандарты кода → Agent OS"]

Грубая схема выбора; последний узел — уточнения для особых случаев

Правила, которые переживут любую смену моды:

1. Начните без инструмента. Две-три фичи по своему минимальному процессу покажут, где вам больно: забывается план, расходятся спецификация и код, теряется картина текущего поведения. Инструмент берут под конкретную боль.
2. Пробуйте на одной настоящей фиче с ограничением по времени. Не на «hello world» и не на всём проекте сразу. Запишите, сколько документов вы реально прочитали, сколько раз возвращали агента, сколько заняло ревью.
3. Держите спецификации в markdown в своём репозитории. Тогда смена инструмента — это смена шаблонов и команд, а не потеря знаний.
4. Сверяйте факты с первоисточником и датой. README, CHANGELOG, исходники навыков. Сравнения от авторов инструментов и восторженные посты — не первоисточник.
5. Размер процесса — по размеру задачи. Это говорят даже сами инструменты: у Spec Kit есть короткий путь, у BMAD — «правильный размер», у cc-sdd — «спецификация не нужна». Тяжёлый процесс на мелкой правке — бюрократия, о которой говорили в уроке SDD.1.1.

В индустрии

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

Практика

Часть 1. Соберите свой процесс

Делайте в учебном репозитории онлайн-школы из прошлых уроков (или в новом пустом).

1. Создайте specs/_templates/ с тремя шаблонами. В spec.md — разделы формата курса: Контекст, Пользовательские истории, Требования (REQ-…), Сценарии (### SC-… со строкой «Требования:»), Вне рамок, Открытые вопросы. В plan.md и tasks.md — разделы из уроков SDD.2.2 и SDD.2.3. В заголовках оставьте метки [FEATURE] и [DATE].
2. Создайте specs/principles.md с тремя-пятью принципами (тесты сначала, имена из глоссария, деньги в копейках, время параметром now).
3. Сохраните скрипт из урока в scripts/new_spec.py и запустите python scripts/new_spec.py waitlist.
4. Добавьте в CLAUDE.md раздел «Как мы работаем со спецификациями» и команду .claude/commands/spec-new.md (для другого агента — его аналог: AGENTS.md и формат команд или навыков этого агента).
5. Закоммитьте.

Ожидаемый результат: скрипт печатает три строки «создан specs/00N-waitlist/…» (номер зависит от того, есть ли уже папки фич), в репозитории появились specs/_templates/, specs/principles.md, specs/00N-waitlist/ с тремя файлами, scripts/new_spec.py, обновлённый CLAUDE.md и .claude/commands/spec-new.md. В новой сессии агента команда /spec-new видна в списке команд.

Часть 2. Проведите фичу

Возьмите маленькую фичу, которая расширяет правила Набора: напоминание об оплате — через 24 часа после записи, если запись всё ещё «ожидает оплаты», студенту уходит письмо, что через сутки запись отменится. Пройдите цикл /spec-new → ревью → план → задачи → реализация по одной задаче. Запишите для себя три числа: сколько документов вы прочитали целиком, сколько раз возвращали агента к спецификации, сколько минут ушло на ревью markdown и сколько на ревью кода. Эти числа пригодятся в уроке SDD.4.1.

Упражнения

1. Определите уровень по Бёккелер: (а) Spec Kit, где команда завела правило «папки фич не меняем»; (б) OpenSpec; (в) свой процесс, где после каждого изменения поведения сначала правят spec.md; (г) спецификация, из которой генератор при каждой сборке заново пишет enrollment.py, а сам файл помечен «не редактировать».

Разбор

(а) Spec-first: спецификация каждой фичи остаётся историческим документом, текущее поведение по ней не восстановить (в терминах Spec Kit это модель flow-forward). (б) Spec-anchored: дельты вливаются в актуальные спецификации. (в) Spec-anchored — та же идея, что living spec в Spec Kit, только без инструмента. (г) Spec-as-source: человек правит только спецификацию, код — продукт генерации.

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

Разбор

(а) Режим планирования агента и, может быть, один файл spec.md; любой инструмент здесь дороже самой задачи (об этом прямо пишет и cc-sdd). (б) OpenSpec или свой процесс с живыми спецификациями по возможностям: нужна одна актуальная картина поведения и маленькие дельты на каждое изменение. (в) Кандидаты — Spec Kit (план, модель данных, контракты, конституция) или BMAD-METHOD (роли, PRD, архитектура, тикеты); выбирать стоит пробой на одной настоящей фиче, а не по звёздам на GitHub.

3. Коллега пишет в чат: «Kiro не подходит, он работает только в своей IDE — так написано в README OpenSpec». Как проверить и что ответить?

Разбор

Утверждение взято из раздела сравнения в README конкурента — это реклама, а не первоисточник. Первоисточник — README и документация самого Kiro. На 6 октября 2026 года README репозитория kirodotdev/Kiro перечисляет IDE, CLI, Web, Mobile и Kiro Crew. Ответ: «по их собственному README есть ещё CLI и веб; давай проверим, подходят ли они нам по лицензии и данным — продукт закрытый». Записывайте дату проверки рядом с фактом.

4. Ваш свой процесс хорошо работает, но через полгода появилась боль: «как сейчас работает отмена записи?» — ответ размазан по specs/001-enrollment/, specs/004-waitlist/ и specs/009-cancel-email/. Что взять из OpenSpec, не переходя на него?

Разбор

Разделить «текущее» и «изменения». Завести specs/current/enrollment.md — живую спецификацию возможности, а папки фич считать изменениями. В шаблон фичи добавить раздел «Что меняется в текущей спецификации» с подразделами «Добавлено / Изменено / Удалено» (та же дельта), а в определение готовности — шаг «перенести изменения в specs/current/ и проверить git diff specs/current/». Если ручное слияние начнёт ошибаться — это сигнал, что пора попробовать сам OpenSpec: у него проверку и слияние умеет делать программа.

Проверь себя

Проверь себя6 вопросов·

1 Что о Kiro подтверждает его публичный репозиторий kirodotdev/Kiro на октябрь 2026 года?

Исходный код Kiro открыт под лицензией MITРепозиторий — трекер ошибок и идей, исходников продукта в нём нетKiro работает только как IDEKiro генерирует код из спецификации без участия агента

2 Что изменилось в Agent OS 3.0 (январь 2026)?

Добавлен собственный генератор кода из спецификацийНаписание спецификаций передано режиму планирования агента, оркестрация реализации убрана, фокус — на стандартах кодаПроект закрыт и стал платнымСпецификации перенесены в облако

3 Какой инструмент в статье Бёккелер служит примером уровня spec-as-source?

KiroSpec KitTesslOpenSpec

4 В каком формате пишет требования cc-sdd (requirements.md)? Ответьте аббревиатурой.

5 Что снижает риск привязки к инструменту SDD? Выберите все верные.Можно выбрать несколько ответов

Спецификации — обычный markdown в вашем репозиторииШаблоны и формат документов под вашим контролемСпецификации хранятся только в облаке поставщикаПроцесс описан в CLAUDE.md или AGENTS.md, а не только в голове инструмента

6 Команда впервые пробует SDD. Какой первый шаг разумнее всего?

Выбрать инструмент с наибольшим числом звёзд и внедрить его во всех проектахПровести две-три фичи по своему минимальному процессу и посмотреть, где больноСначала описать спецификациями всю существующую системуДождаться, пока рынок инструментов устоится

Проверить ответы

Итоги

• Любой инструмент SDD оценивайте по шести вопросам: уровень, артефакты, агенты, лицензия и данные, цена процесса, как проверено. Сравнения от авторов инструментов — реклама с датой годности.
• Kiro — закрытый продукт Amazon с режимом спецификаций и steering-файлами; Tessl от идеи spec-as-source пришёл к платформе контекста для агентов и открытому тайлу SDD; BMAD-METHOD — роли и документы от брифа до тикетов; cc-sdd — процесс Kiro в других агентах; Agent OS — стандарты кода поверх режима планирования.
• Почти все они — пакеты промптов, шаблонов и небольших программ. Спецификации в markdown в своём репозитории — главная страховка от привязки.
• Минимальный процесс — specs/ с шаблонами в формате курса, принципы, раздел в CLAUDE.md, несколько команд-промптов и скрипт для детерминированных шагов. С него стоит начинать, а инструмент брать под конкретную боль.

Дальше: модуль SDD.4, урок «Полный цикл с агентом: от спецификации к коду» — сквозной практикум на записи на потоки онлайн-школы: конституция, спецификация, уточнения, план, задачи, реализация по задачам и проверка, с режимом планирования, субагентами, хуками и коммитом после каждой задачи.