Шесть недель назад я поставил @fission-ai/openspec на brownfield TypeScript-кодовую базу, которую три инженера правили два года. Вчера отгрузил изменение в четырнадцать файлов за девяносто минут из двухсотстрочной спеки. Без мерж-конфликтов. Без эскалаций ревью. PR-описание состояло из proposal и шестидесятистрочной spec-дельты; код-дифф был её следствием. Сеньор, который ревьюил, не читал код — он прочитал spec-дельту и одобрил.
Эта фраза два года назад прозвучала бы как маркетинг. В мае 2026 это третья неделя подряд, когда я отгружаю что-то таким способом, и я начал думать, что магия не в OpenSpec. Магия в том, что у методологии наконец-то появился инструмент, относящийся к её собственным заявлениям всерьёз.
Это четвёртый пост в дуге, которую я веду. Контекст-инжиниринг был рантайм-дисциплиной. Spec-driven development был design-time-философией. Evals был слоем верификации. Каждый из этих постов указывал вперёд на вопрос, на который я не ответил: но как ты на самом деле гоняешь это в реальной кодовой базе, с реальными людьми, во вторник? OpenSpec — первый инструмент, который отвечает на этот вопрос честно.
Тезис жёстче, чем людям удобно. OpenSpec — первый spec-driven фреймворк, относящийся к спекам так, как Git относится к коду: filesystem-state-machine с ветками, изоляцией и атомарными мержами. Это не фича. Это вся причина, по которой он работает.
Что такое OpenSpec, если по существу
OpenSpec — это open-source CLI от Fission-AI, основанный Tabish Bidiwale, запущенный через Y Combinator в начале этого года, сидящий на пятидесяти тысячах GitHub-звёзд примерно за шесть месяцев после релиза. NPM-пакет — @fission-ai/openspec. TypeScript, требует Node 20.19+, последняя стабильная — v1.3.1 (21 апреля 2026 — около месяца назад на момент написания).
Фрейминг основателя стоит цитировать, потому что он прорезает три года LLM-хайпа одним предложением:
Генерация кода теперь дешёвая. Корректность — всё ещё дорогая.
Это весь диагноз. Бутылочное горлышко отгрузки AI-фич в 2026 — не возможности модели. Opus 4.7 и Codex 5.5 могут произвести рабочую реализацию из почти любой хорошо сформированной спеки. Бутылочное горлышко — добраться до хорошо сформированной спеки, держать её стабильной между сессиями, изолировать параллельные изменения и мержить их обратно в источник истины без загрязнения. Это системная задача, не задача про промптинг.
OpenSpec решает её так, как решал бы backend-инженер — файловой системой, без БД, markdown’ом везде, и воркфлоу, мапящимся почти один-в-один на Git Flow. Канонический layout:
project_root/
└── openspec/
├── AGENTS.md # поведенческие правила для любого AI-инструмента
├── project.md # глобальный контекст — стек, конвенции, ограничения
├── specs/ # Источник истины — текущее поведение системы
│ ├── auth-login/spec.md
│ ├── payment-checkout/spec.md
│ └── ...
└── changes/ # изолированная рабочая зона для in-flight предложений
├── add-oauth-login/
│ ├── proposal.md # "почему" и "что"
│ ├── design.md # технический подход
│ ├── tasks.md # чек-лист реализации
│ └── specs/ # spec-дельты: ADDED / MODIFIED / REMOVED
└── archive/
└── 2026-04-12-add-rate-limiting/
└── ...Две директории несут всю модель. specs/ — текущее состояние мира, источник истины системы, организованный по capability. changes/ — in-flight рабочая зона; каждое предложение — своя папка, полностью изолированная, со своей дельтой против текущих спек. Когда изменение одобрено и применено, его дельты мержатся обратно в specs/, а папка proposal’а переезжает в changes/archive/[date]-[name]/. Архив неизменяем. Всё. Это весь контракт файловой системы.
Всё остальное — CLI, slash-команды, интеграции с AI-инструментами — это интерфейс над этим контрактом. Можно удалить каждый JavaScript-файл в node_modules и у тебя всё ещё будет когерентная SDD-кодовая база, потому что методология живёт в структуре директорий, не в инструменте.
Машина состояний из четырёх фаз
CLI экспонирует небольшой набор slash-команд, перемещающих изменение через четыре фазы. Внутри AI-инструмента вроде Claude Code или Cursor ты набираешь команду, AI делает работу; ты ревьюишь.
| Фаза | Команда | Файлы созданные / изменённые | Что происходит downstream |
|---|---|---|---|
| 1. Propose | /opsx:propose <feature> | openspec/changes/<feature>/ с proposal.md, design.md, tasks.md, дельтами specs/ | Существует новая изолированная рабочая зона; в источнике истины ничего не изменилось |
| 2. Define | openspec validate | Новых файлов нет; репортит ошибки синтаксиса спек / сценариев | Статический анализ spec-дельты до того, как написан хоть какой-то код |
| 3. Implement | /opsx:apply | Изменения исходного кода, чекбоксы задач отщёлкнуты | AI исполняет tasks.md строго против согласованной спеки; ты ревьюишь код-диффы и spec-дельты вместе |
| 4. Archive | /opsx:archive | specs/ обновлён мержем дельт; proposal переехал в changes/archive/[date]-<feature>/ | Источник истины отражает новое состояние системы; архивированный proposal — постоянная история |
Конкретный end-to-end:
Ты: /opsx:propose add-dark-mode
AI: Создано openspec/changes/add-dark-mode/
✓ proposal.md (обоснование, критерии успеха)
✓ design.md (theme-контекст, CSS-переменные, персистенс)
✓ tasks.md (8 задач по 3 компонентам)
✓ specs/theme/spec.md (ADDED: 4 сценария)
Ты: openspec validate
✓ Все сценарии корректно сформированы
✓ Конфликтов с существующими спеками нет
Ты: /opsx:apply
AI: ✓ 1.1 Добавить theme context provider
✓ 1.2 Создать toggle-компонент
✓ 2.1 Добавить CSS-переменные для тёмной палитры
...
Ты: /opsx:archive add-dark-mode
✓ Спеки смержены в openspec/specs/theme/
✓ Proposal заархивирован в openspec/changes/archive/2026-05-21-add-dark-mode/Весь цикл, от «я хочу тёмную тему» до «тёмная тема в main со спекой» — одна терминальная сессия. Спека — долговечный артефакт; код — её следствие. Архив — история.
Почему filesystem-as-state-machine — правильный выбор
Хитрость здесь не в CLI. Хитрость в том, что кто-то наконец сел и спросил: как выглядел бы Git, если бы Git версионировал поведение, а не код? И потом реализовал это без БД, без сервиса, без централизованного сервера — просто файлами в директории и машиной состояний из четырёх команд.
Маппинг один-в-один с интуициями, которые у каждого backend-инженера уже есть.
| Понятие Git | Эквивалент OpenSpec | Заметки |
|---|---|---|
Ветка main | openspec/specs/ | Источник истины; текущее состояние мира |
| Feature-ветка | openspec/changes/<feature>/ | Изолированная рабочая зона; не загрязняет main, пока не смержена |
| Дифф | Spec-дельта (ADDED / MODIFIED / REMOVED сценарии) | Ревьюается как текст, история по строкам |
| Мерж | /opsx:archive | Атомарный; дельты применены, proposal переехал в историю |
git log | openspec/changes/archive/ | Append-only история каждого изменения с сохранённым обоснованием |
| Pre-commit hook | openspec validate в CI | Ловит криво сформированные спеки до того, как они попадут в ревью |
Как только видишь маппинг, любой другой SDD-инструмент выглядит недо-спроектированным. GitHub Spec Kit тяжеловесен и жёсток; он навязывает фазовые гейты и инлайн-правит source-of-truth спеки по ходу, что означает: конкурентные предложения от двух инженеров столкнутся на одном файле. AWS Kiro привязывает к Kiro IDE и в частности к моделям Claude — норм, если ты уже AWS-shop, фатально иначе. Tessl — пуристская позиция («код реконструируется из спеки»), философски чистая и операционно болезненная — у большинства реальных кодовых баз есть код, написанный руками, который должен сосуществовать с генерируемым. BMAD, Antigravity от Google, и горстка других SDD-фреймворков, отгружающихся в 2026, делают разные ставки, но почти все предполагают greenfield — новый проект, пустой репо, чистый лист.
Brownfield — это где работа на самом деле. Каждая команда, которую я уважаю, отгружает в кодовую базу, которую правили годами, люди, ушедшие из компании, с конвенциями, которые не совпадают с README, в директориях, названных по продуктам, которые переименовали дважды. Вся архитектура OpenSpec построена под эту реальность. Директорию specs/ можно ретрофитнуть на существующий проект — есть даже документированный режим retrofitting, где ты просишь AI обратно-инженерить спеки из существующего кода, производя базовую документацию для систем, которые её никогда не имели. Это настоящее раскрытие. Не «spec-driven с первого дня» — spec-driven с третьего года.
Backend-архитектор, читающий это, должен заметить, что OpenSpec на самом деле отгружает workflow-engine поверх content-addressed store, и адресует файловая система. Всё это умещается на USB-флешке. Нет сервиса, который надо эксплуатировать, нет consensus-протокола для дебага, нет API для версионирования. Это самая лёгкая возможная реализация настоящей идеи, и поэтому он уже выигрывает SDD-экосистему.
Форма PR меняется downstream от этого. В старом мире ревьюер открывает PR, видит 600-строчный дифф, скроллит, надеется, что в середине ничего важного не прячется, и аппрувит. В OpenSpec-форме PR тело состоит из proposal.md + design.md + spec-дельта. Ревьюер читает шестьдесят строк спеки, задаёт один вопрос по неоднозначному сценарию и аппрувит. 600-строчный код-дифф проглядывается как sanity-check — это следствие согласованного изменения, не само изменение. Это и есть изменение воркфлоу, на которое Spec-Driven Development указывал; OpenSpec — первый инструмент, который реально доставляет это на brownfield-команде.
Как это бьёт по дизайну компонентов
OpenSpec описывают и демонстрируют преимущественно backend-leaning инженеры, что заслонило кое-что, что стоит сказать: это негромко-отличный frontend-инструмент.
Причина в layout’е файлов. Каждая поведенческая capability получает свою папку под openspec/specs/. Для component-heavy frontend это мапится в:
openspec/specs/
├── ui-button/spec.md
├── ui-form-field/spec.md
├── auth-login-form/spec.md
├── checkout-cart/spec.md
├── nav-language-switcher/spec.md
└── ...Каждый spec.md содержит сценарии в формате GIVEN / WHEN / THEN — например, для формы логина:
СЦЕНАРИЙ: Пользователь с включённым 2FA отправляет валидные креды
GIVEN у пользователя включён 2FA
AND пользователь отправил валидный email и пароль
WHEN форма отправлена
THEN сервер возвращает OTP-вызов
AND форма переходит в состояние ввода OTP
AND поля email/пароль задизейблены
СЦЕНАРИЙ: Отправка формы с невалидным форматом email
GIVEN поле email содержит "not-an-email"
WHEN пользователь блюрит поле
THEN поле показывает inline-валидационную ошибку
AND кнопка submit остаётся задизейбленнойЭто не новый формат. Это та же форма данных, которую твои Playwright-тесты уже используют. Та же форма данных, которую play-функции Storybook уже используют. Та же форма данных, в которой твоя QA-команда уже пишет user stories. Причина, по которой большинство frontend-команд не пишут спеки, — не в том, что формат незнаком — в том, что у формата не было канонического дома. OpenSpec даёт ему дом.
Что это раскрывает для frontend:
- A11y, i18n, design tokens и responsive-ограничения становятся first-class spec-контентом вместо разбросанных комментариев. «Кнопка должна достигать минимум touch-target 44×44 на мобиле» перестаёт быть сообщением в Slack и становится сценарием, ревьюируемым, когда ревьюится спека.
- Дизайнер может отгрузить UX-предложение как spec-дельту, пока инженер отгружает data-layer-предложение как отдельную spec-дельту. Эти два никогда не трогают один файл. Они мержатся независимо в
specs/. Мерж-конфликта нет, потому что нет shared mutable state — каждое предложение изолировано by design. - Рефакторы компонентов перестают быть «я переписал форму» и становятся «я MODIFIED два сценария и ADDED один». Ревьюеры видят, какое поведение изменилось. Если сценарий не изменился — поведение не изменилось, и ревьюер может доверять реализации.
Где это напрягается — и я продавал бы тебе что-то, если бы не сказал — это на сильно визуальной работе. Тайминг анимации, layout-as-art, микро-интеракции, зависящие от движения и цветовых решений: эти не вписываются чисто в GIVEN / WHEN / THEN. По-прежнему нужны visual-regression evals, screenshot-диффы, design-system stories. OpenSpec не заменяет это. Но он означает, что поведенческий слой — что этот компонент делает, когда, кому, с каким исходом — имеет канонический дом, и значит, перестаёт драться за пространство с визуальным слоем.
Tell frontend-архитектора здесь — что
GIVEN / WHEN / THENбайт-в-байт та же форма данных, которую твой Playwright-спек уже использует. Ты не учишь новый формат. Ты учишь куда положить тот, что у тебя есть, чтобы он перестал быть осиротевшим в папке, которую никто не читает.
Это также то место, где дисциплина evals встречается с OpenSpec естественно. Каждый сценарий в спеке — механически — это eval-вход. Пайплайн, читающий openspec/specs/**/spec.md, извлекающий сценарии и гоняющий их как Playwright-тесты против развёрнутого превью — проект на выходные. Как только он существует, спека перестаёт быть aspirational — она верифицируется на каждом PR, и любое расхождение между спекой и реализацией — это CI-падение, не эскалация ревью.
Контекст-инжиниринг под другим именем
В первый раз, когда я читал доки OpenSpec, у меня было конкретное ощущение узнавания старой идеи в новой одежде.
Доки прямо говорят: «Когда использование контекста превышает 40%, перформанс AI значительно деградирует, и прошлые требования забываются». Это не открытие OpenSpec; это известное свойство long-context LLM в 2026, и это вся причина, по которой контекст-инжиниринг — дисциплина, которая важна. Интересно, что OpenSpec с этим делает.
Воркфлоу OpenSpec, в рантайме, — это load-on-demand стратегия контекста. Когда AI начинает сессию, он читает три файла: openspec/project.md (глобальный стек, конвенции, ~200 строк), openspec/changes/<active>/tasks.md (текущий фокус, ~50 строк) и конкретные openspec/specs/<capability>/spec.md файлы, на которые ссылается задача (~100 строк каждый). Это примерно 500–1,000 токенов курируемого, плотного контекста — не 50,000 токенов «вот весь репо, разбирайся».
Каждая проблема, которую идентифицирует контекст-инжиниринг — разжижение контекстного окна, hot/warm/cold тиринг, экономика токенов, стратегия эвикции, planning context vs execution context — здесь решается layout’ом директорий. Hot-тир — это tasks.md. Warm-тир — это упомянутые spec.md-файлы. Cold-тир — это остальной specs/ и весь archive/, доступный для загрузки по требованию, но не оплачиваемый по дефолту. Ты не конфигурируешь контекстный пайплайн. Ты используешь инструмент, у которого правильный пайплайн вшит в его файловую структуру.
Есть также история про память. Plan mode исчезает, когда модель перезапущена; история разговора испаряется между сессиями; даже лучшая long-context модель не помнит, что ты решил во вторник на прошлой неделе. Спеки решают это без церемоний: это файлы, версионируемые, долговечные, тривиально загружаемые. «Память» OpenSpec-проекта — это директория specs/. «Мышление» OpenSpec-проекта — это директория changes/. Каждая ограничена, инспектируема, переживает рестарты. Это то, что любой agent-фреймворк, который я использовал, пытался построить из векторных хранилищ и KV-кэшей, а OpenSpec отгружает это как .md-файлы в папке.
Здесь есть более тонкое свойство, которое я пару недель учился ценить. Поскольку OpenSpec-спеки написаны в GIVEN / WHEN / THEN, каждый сценарий естественно eval-shaped. Можно сделать scrape всего дерева specs/, считать каждый сценарий тест-кейсом, и кормить их eval-харнес как канонические критерии корректности. Ты не пишешь evals отдельно — они и есть спека, в достаточно структурированной форме, чтобы быть машинно извлекаемыми. Это унификация, за которую я топил в конце eval-поста, и OpenSpec — первый инструмент, который добирается туда побочно, а не через церемонию.
AI-архитектор уже знает, что здесь происходит: это load-on-demand context engineering, надевший CLI-шапку. Интересная вещь в том, что это учит дисциплине инженеров, не знающих, что она им нужна. Через полгода инженер, ежедневно использующий OpenSpec и никогда не читавший статью про контекст-инжиниринг, будет контекст-инженером, по привычке, никогда не услышав термина.
Практическая заметка про модели. OpenSpec работает с двадцатью пятью+ AI-инструментами, но не работает одинаково хорошо со всеми. Спеки — это markdown, требующий рассуждения для качественного производства — называние capability, декомпозиция задач, написание сценариев, покрывающих краевые случаи — и дешёвые модели производят поверхностные спеки. Консенсус сообщества, совпадающий с тем, что я видел в двух продакшен-кодовых базах: Opus 4.7 или Codex 5.5 для propose и apply. Меньшие модели справляются с archive и validate. Если подключишь Haiku-tier модель к /opsx:propose, получишь спеки, которые выглядят правдоподобно и пропускают третий краевой случай, каждый раз. Плати за рассуждение там, где рассуждение важно.
Пять правил, которые я заработал, отгружая с OpenSpec
Пронумерованы, потому что заработаны в двух продакшен-кодовых базах за шесть недель, не выведены со страницы доков.
1. openspec validate блокирует CI с первого дня, не «потом». Валидация — это spec-эквивалент type-check. Без неё криво сформированные сценарии проскальзывают в specs/, и через неделю у тебя «спека», которая на самом деле непарсимая проза, а твой spec-to-eval пайплайн молча пропускает половину. Добавь openspec validate как обязательный шаг в pre-commit hook и как блокирующую CI-проверку в первый день, когда внедряешь инструмент. Не во второй. В первый.
2. project.md короткий и конкретный, не длинный и aspirational. Это глобальный контекст, который каждый агент читает первым, на каждой сессии. Кэп — 200 строк. Назови стек («Next.js 16, Tailwind 5, Postgres, Drizzle ORM»). Назови конвенции («мы используем Result-типы, не throw»). Назови отрицания («не использовать any в TypeScript; не eval; не прямой DB-доступ из хендлеров»). Пропусти маркетинг. Пропусти team mission statement. Агент — не твой инвестор.
3. Архив неизменяем. Никогда не редактируй openspec/changes/archive/*. Относись к нему как к Git-истории. Если прошлое решение надо пересмотреть — пишешь новый proposal, который его перекрывает; новый proposal ссылается на старый, и архив растёт. День, когда кто-то отредактирует архивированный proposal «просто опечатку поправить» — это день, когда история становится ненадёжной, а через несколько месяцев ты дебажишь регрессию и архив тебе врёт. Не надо.
4. Ревьюй spec-дельту, не код-дифф. Это изменение воркфлоу с наивысшим рычагом, которое я сделал в 2026, и мне потребовалось три недели его интернализировать. Тело PR должно быть proposal’ом, design-summary и spec-дельтой — это то, что читают люди. Код-дифф — это в лучшем случае sanity-check. Если spec-дельта правильная и код проходит validator и evals, код правильный; если spec-дельта неправильная, код тоже неправильный, но код был неправильным, потому что спека была неправильной, и починка кода без починки спеки лишь откладывает баг. Ревьюеры, которые читают spec-дельту первой, отгружают код лучше, чем ревьюеры, читающие код первым.
5. Не используй OpenSpec для исследовательской работы. Это та же оговорка, что в Spec-Driven Development, с двойной силой. Нельзя заспецировать то, чего ещё не понимаешь. Если ты в research-фазе — выясняешь, сработает ли подход, набрасываешь формы API, учишься модам отказа — пиши код руками, читай вывод, потом извлекай спеку из того, что сработало. Spec-after, не spec-first. Ошибка, которую делают новые adopter’ы, — хвататься за OpenSpec на первом дне research-spike. Так и получаются пятидесятистрочные спеки на штуку, которая через два дня окажется тремя разными штуками. Используй его для известной работы, не для неизвестной.
Где это всё-таки ломается
Честный учёт. Я продавал бы тебе инструмент, не методологию, если бы остановился на правилах.
- Сильно визуальная / animation-heavy работа не вписывается в
GIVEN / WHEN / THENчисто. Сохраняй visual-regression-сьют. OpenSpec — для поведенческого слоя, не эстетического. - Research-фаза кода по-прежнему лучше пишется руками с spec-after-extraction. Не борись с этим.
- Дешёвые setup’ы моделей дают поверхностные спеки. Если твой AI-бюджет — haiku-tier по всему фронту, тебе самому придётся писать сценарии, ловящие краевые случаи, и инструмент превращается в тормоз вместо мультипликатора. Плати за high-reasoning модель там, где это важно — propose, apply, validate. Экономь на archive, если надо.
- Фрагментация экосистемы реальна. SpecKit, Kiro, BMAD, Antigravity, Tessl и OpenSpec все хотят быть SDD-фреймворком, который ты внедришь, и они не интероперируют чисто. Выбери один. Закоммить команду на него. Switching costs выше, чем доки признают; ты не просто учишь CLI, ты кодируешь всю change-дисциплину команды в форму инструмента.
- Телеметрия — opt-out, не off-by-default. OpenSpec собирает анонимизированные имена команд и версии, если не выставить
OPENSPEC_TELEMETRY=0илиDO_NOT_TRACK=1. Большинству команд это норм. Командам в регулируемых средах или с жёсткими data-handling политиками — это однострочный конфиг в shell-профиль и CI, но об этом надо знать. - Brownfield retrofitting работает, но не бесплатно. Рекламируемый воркфлоу «попроси AI обратно-инженерить спеки из твоего кода» работает — я использовал его на кодовой базе в шесть тысяч файлов — но первый проход даёт descriptive-спеки, не prescriptive. Они говорят, что код делает, не что должен делать. Потом нужен второй проход с человеком в петле, чтобы конвертировать descriptive-спеки в кодирующие реальное намерение. Планируй это. Не отгружай спеки первого прохода как источник истины.
Честная рамка: OpenSpec — правильный инструмент для девяноста процентов работы в зрелой 2026-кодовой базе, и оставшиеся десять процентов важны. Сеньорный инженер — тот, кто умеет различать.
Карьерный угол
«Покажи свой eval-сьют» — это вопрос, который я начал задавать на AI-инженерных собеседованиях в этом году. «Покажи свой OpenSpec-воркфлоу» — или SpecKit, или Kiro, но какую-то SDD-операционную модель с реальной формой — это вопрос, который к нему присоединился в последние два месяца. Качество ответа говорит о кандидате больше, чем любой другой одиночный сигнал.
Рынок ещё не запрайсил это. Инженеры, способные артикулировать когерентную spec-driven операционную модель — что живёт в project.md, а что нет, где границы изменений, как сдвигается PR-ревью, как интегрируются evals — всё ещё single-digit процент кандидатского пула, который я вижу. Премия будет компрессироваться по мере становления дисциплины стандартной практикой, тем же путём, что юнит-тестирование стандартизировалось между 2005 и 2015. Моя оценка — восемнадцать месяцев до того, как fluency в какой-то flavor SDD станет table stakes для сеньорных AI-инженерных ролей.
80/20, если не читать больше ничего: возьми продакшен AI-фичу, которой владеешь. Внедри OpenSpec на ней на этой неделе. Ретрофитни спеки для существующего поведения в два прохода — сначала descriptive, потом human-edited prescriptive. Прогони один полный proposal-to-archive цикл на реальном изменении. За неделю обнаружишь, что в твоём старом воркфлоу было три места, где ты гадал — про намерение, про скоуп, про то, кто должен что верифицировать — и OpenSpec превратил все три в файлы, на которые можно ткнуть пальцем. Это обнаружение — весь навык.
Более глубокая мысль
Урок не в том, чтобы «использовать OpenSpec». Урок в том, что когда у методологии появляется такой хороший инструмент, люди, уже понимавшие методологию, компаундят свой рычаг в десять раз, а те, кто не понимал, получают возможность выучить методологию, используя инструмент. Эта асимметрия — карьерная история инженерии 2026.
Spec-driven development был философией три года назад. Стал практикой в 2025. В 2026 становится операционной системой, и OpenSpec — самая лёгкая отгруженная на сегодня реализация этой системы. Интересный вопрос больше не «стоит ли заниматься spec-driven development?». Это «какую SDD-операционную модель я коммичу своей команде, и насколько быстро могу ретрофитнуть кодовую базу, которая у меня уже есть?»
Если хочешь глубже, курсы ниже покрывают части дисциплины, которые я преподаю чаще всего: Claude Code Mastery: Agentic Coding for Engineers — ежедневный slash-command воркфлоу внутри инструмента, лучше всего парящегося с OpenSpec, Building Agents with the Claude Agent SDK — построение агентов, потребляющих спеки как first-class входы и производящих как выходы, Building MCP Servers & AI Tool Integrations — расширение OpenSpec-воркфлоу через MCP-обслуживаемые capability, и Building LLM-Powered Apps: RAG & Agents — проводка GIVEN / WHEN / THEN сценариев из твоих спек в рабочий evals-харнес на продакшен-трафике.
