Урок 3 из 14 курса «AI-Native SDLC Playbook»: официальный курс Anthropic Academy (Антропик) на русском языке. Этот урок бесплатный.

Как только product owner одобряет intent.md, Claude принимает его и создает спецификацию требований и дизайна. Это руководствуется skills организации для бренда, безопасности, соответствия требованиям и UX.

Product owner просматривает эту спецификацию, но не пишет ее. Цель этого процесса — создать спецификацию, на основе которой команда инженеров сможет планировать работу, с отмеченными областями, вызывающими опасения.

Работа с фронтендом — самый наглядный пример. Как только intent.md принят, product owner создает макет дизайна в Claude Design (бета) на основе intent.md, итерирует макет, а затем экспортирует его в Claude Code для сборки.

Что меняется

Традиционный подход AI-нативный подход

Требования и дизайн — это отдельные фазы, выполняемые разными командами. Аналитики формализуют идею в требования, а затем дизайнеры преобразуют их обратно в дизайн. Разделение существует для обеспечения подотчетности, но оно медленное и приводит к потерям. Обе фазы происходят в рамках одной prompted сессии. Claude принимает intent.md и создает спецификацию требований и дизайна, ограниченную skills организации, с отмеченными областями, вызывающими опасения.

Начало работы

Предварительные условия: Напишите файл intent.md, содержащий политики бренда, безопасности, соответствия требованиям и UX, оформленные как skills.
Инфраструктура: Product owner с доступом к Claude. Инженерные навыки не требуются.

Как это реализовать

Product owner открывает сессию с доступными skills организации и прикрепляет файл intent.md.
Prompt product owner'а указывает на намерение, называет ограничения и требует отметить проблемные области. Сначала запустите его вручную, затем кодифицируйте как slash-команду уровня организации. Затем сделайте принятие intent.md в intent home триггером, с неинтерактивной задачей, которая запускается при слиянии, выполняет проход с загруженными skills организации и коммитит spec.md как pull request (CI/CD сценарий в Этапе 5: Развертывание охватывает всю механику). С этого момента первое участие product owner'а — это review.
Тот же product owner просматривает спецификацию на соответствие идее. Решает ли спецификация заявленную проблему, и отвечены ли открытые вопросы из intent.md или перенесены на будущее?
Сначала проработайте отмеченные проблемные области, так как это те моменты, которые аналитик эскалировал бы. Product owner решает каждую из них с ее владельцем политики до того, как спецификация будет передана инженерам.
Закоммитьте spec.md вместе с intent.md. Пара файлов фиксирует, что было запрошено и что было решено.
Product owner решает, переходят ли спецификация и намерение к сборке, консультируясь с техническим руководителем по всему, что организация классифицирует как более высокий риск. Человек из команды всегда принимает это решение, и принятие спецификации — это то, что запускает сценарий режима планирования в Этапе 3: Сборка.

Как это выглядит

Prompt:

Прочитайте прикрепленный intent.md и создайте спецификацию требований и дизайна для его интеграции в нашу существующую кодовую базу. Примените доступные вам skills, чтобы план соответствовал нашим рекомендациям по бренду, политикам безопасности и стандартам UX. Полностью задокументируйте спецификацию как spec.md, готовую для передачи команде инженеров. Четко опишите любые проблемные области, особенно там, где вы не можете удовлетворить противоречащие друг другу политики.

Вопросы управления

Вместо того чтобы конфликты политик обнаруживались на review неделями позже, действующая политика считывается и применяется во время написания спецификации. Skills организации применяются как ограничения к спецификации. Спецификация, prompt, который ее создал, и действующие версии skills — все это логируется в системе контроля версий. Product owner утверждает спецификацию и направляет отмеченные проблемные области указанным владельцам политик.

Как это измерить

Опережающий индикатор: Прошедшее время между коммитом intent.md и коммитом spec.md для одного и того же изменения (две временные метки Git), по сравнению со старым циклом требований-плюс-дизайн.
Запаздывающий индикатор: Переработка требований после начала сборки. Подсчитайте коммиты spec.md, датированные после первого коммита plan.md для того же изменения. Git log предоставит это напрямую.

Требования и проектирование