Итоговый проект: провести задачу через весь продакшн-процесс с ИИ

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

Если рабочей задачи нет — NDA, нет доступа к системе, между работами — возьми выдуманный продукт и придумай ему одну фичу. Четыре готовых варианта:

• Трекер привычек без регистрации и уведомлений. Аудитория: те, кого раздражают все существующие трекеры и кто хочет разобраться в своих паттернах, а не получать ачивки.
• Музыкальный девайс или инструмент, который уже существует: синтезатор, драм-машина, педаль. Аудитория: музыканты, которым нужен понятный экран настроек и понятная инструкция, а не форум.
• Сервис доставки готовой еды на неделю. Аудитория: люди, которые не хотят думать об ужине каждый день, но не готовы есть одно и то же.
• Виртуальный ассистент, который помогает планировать день и готовиться к встречам. Аудитория: те, у кого календарь полон, а к встречам они приходят с пустой головой.

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

Тема длинная, потому что она заменяет собой месяц наблюдения за тем, как это делают в команде. Читать её целиком не обязательно.

• Старт. Ты никогда не проходил задачу от вводных до передачи целиком. Делай только «стартовую» версию каждого этапа — она отмечена в тексте. Два вечера, если Figma MCP уже настроен и вводные готовы. Настройку и выдуманные вводные считай отдельным вечером.
• Полная версия. Все восемь этапов до handoff и обвязки, которая остаётся команде. Неделя рабочими вечерами.

Под каждым этапом есть блок «Как это выглядит» — форма артефакта, который должен получиться. Сверяйся с ним: так проще понять, достаточно ли того, что вышло у тебя.

Если эти слова тебе знакомы — пропускай. Если нет — вот всё, что понадобится дальше, без учебника.

• Позиционирование — одно предложение о том, для кого продукт и чем он отличается от остальных. Внутренняя формулировка для команды, не слоган.
• Ключевые сообщения — три мысли, которые продукт повторяет везде: на сайте, в интерфейсе, в письмах. Если их больше пяти, их нет.
• Тон голоса — то, как продукт говорит. Записывается парами «так — да / так — нет», а не прилагательными.
• Стайл-гайд — записанные правила визуала: палитра, типографика, свет, настроение картинок. В этом проекте он существует в виде фиксированной части промпта.
• Дизайн-система — библиотека компонентов и токенов (цветов, отступов, радиусов), из которых собирают продукт. Её нельзя ломать, но можно расширять.
• Брендбук — документ, где записана айдентика и правила её применения. Твой главный источник вводных.
• Spec — спецификация задачи: сценарии, критерии приёмки, что вне скоупа. По ней собирают и по ней проверяют.
• Handoff — передача результата разработчику: компоненты, состояния, поведение, крайние случаи.

• Этап 0. Вводные — собрать всё, что уже существует: брендбук, дизайн-система, тексты, ограничения, кто принимает решение.
• Этап 1. Смысл — задача через результат для пользователя и бизнеса, критерии приёмки.
• Этап 2. Стратегия — сверка задачи с тем, что продукт уже обещает; памятка голоса из живых текстов.
• Этап 3. Визуал — новые ассеты внутри системы: стайл-гайд из брендбука, компоненты из библиотеки, расширение там, где её не хватает.
• Этап 4. Тексты — тексты фичи по памятке голоса, матрица состояний, локализация.
• Этап 5. Сборка — фича на токенах системы, по spec, с отдельным ревьюером.
• Этап 6. Проверка — эвристики, симуляция пользователя, ревью ролями, живой человек из команды.
• Этап 7. Передача — handoff, презентация решения, обновление системы, обвязка, которая остаётся команде.

Порядок важен: результат каждого этапа — вводная для следующего. Тексты без стратегии расползутся по тону, экран без текстов заполнится «Lorem ipsum» и дефолтами модели, а презентация, собранная до проверки, покажет версию, которую ты уже переделал.

Это самый важный этап, и на нём в реальных командах теряют больше всего времени. Прежде чем что-то делать, собери всё, что уже существует, и дай агенту к этому доступ:

1. Брендбук и стайл-гайд — файлом. Коннектор к Google Drive подходит, только если брендбук лежит одним Google-документом: длинный PDF через коннектор модель может не найти или прочесть не целиком.
2. Дизайн-система — через Figma MCP (тема «Вайбкодинг: интерфейсы») и репозиторий с токенами, если он есть.
3. Живые тексты продукта: 20–30 реальных строк из интерфейса, писем, соцсетей. Из них ты соберёшь памятку голоса на этапе 2.
4. Ограничения: что менять нельзя (знак, основной цвет, шрифт), юридические требования, языки, устройства.
5. Кто принимает решение и как выглядит «принято».

Что нужно до старта. Подключённый Figma MCP. Удалённый Figma MCP формально работает на любом плане, но на бесплатном Starter и на View/Collab-местах это до 20 вызовов в месяц — на проект не хватит. Для реальной работы нужно Dev- или Full-место на платном плане (200 вызовов в день, на Enterprise — 600); чтобы агент не только читал, но и менял файл, нужно Full-место. Агенту давай ссылки на конкретные фреймы и компоненты, а не на всю библиотеку целиком. Если платного места нет, запасной путь — экспортировать переменные дизайн-системы плагином в JSON и отдавать агенту этот файл.

Попроси агента провести аудит и записать результат в 00-audit.md:

Вот брендбук (приложить или дать доступ через коннектор), ссылка на дизайн-систему в Figma и 25 реальных текстов из продукта (вставить). Собери аудит на одну страницу: какие правила айдентики записаны явно, какие видны только по факту использования, где брендбук и живой продукт расходятся, каких компонентов и состояний в системе нет. Ничего не предлагай менять — только опиши, что есть

Если вводных нет (выдуманный продукт): создай их сам за вечер, и с этого момента они — закон. Бриф в диалоге (тема «Брифы с ИИ»): модель задаёт вопросы по одному, в конце оформляет структуру. Стайл-гайд на пять строк как фиксированная часть промпта (тема «Персонажи и стиль», раздел «Стайл-гайд как промпт-система»): палитра в hex, типографика словами, свет, настроение. Десять строк «живого» текста — заголовок, две кнопки, пустое состояние, ошибка, письмо — в выбранном тоне. Мини-система: кнопка, поле, карточка с двумя состояниями в Figma или в коде через веб-агент. Этого хватает, чтобы дальше работать «внутри системы».

У меня есть только общая идея продукта: [одно-два предложения]. Задай мне по одному вопросу за раз, чтобы вместе собрать бриф: что это, для кого, какую проблему решает, чем отличается от существующих альтернатив. В конце оформи всё по структуре: цель, целевая аудитория, конкуренты, тон и стиль, обязательные элементы, ограничения

Стартовая версия: аудит на полстраницы (или бриф плюс стайл-гайд на пять строк) и список ограничений.

Как это выглядит. Типичный аудит живого продукта: в брендбуке записаны знак, палитра и шрифты; тон голоса нигде не записан, но по текстам читается — короткие фразы, на «вы», без восклицательных знаков. В системе нет одного-двух компонентов, которые нужны твоей фиче, и нет какого-то состояния: пусто, «мест нет», ошибка оплаты. И почти всегда есть расхождение вроде «на сайте кнопки скруглены на 8 px, в брендбуке — на 4». Это и есть вводные для всех следующих этапов.

Задача формулируется не «сделать раздел», а через результат для пользователя и для бизнеса, с критериями, по которым потом судить (тема «Вайбкодинг: интерфейсы», раздел про spec-driven development). Это спецификация, и она пишется до первого экрана:

Вот аудит продукта (вставить) и задача: [описание]. Оформи 01-spec.md: для кого и зачем, пользовательские сценарии, критерии приёмки (что должно работать, чтобы задача считалась закрытой), что сознательно не входит в скоуп, какие ограничения из аудита нужно соблюсти. Отдельно — список вопросов, на которые нужен ответ от владельца задачи до начала работы

Вопросы из последнего пункта задай живому человеку — продакту, руководителю, себе, если продукт выдуманный, — и запиши ответы в spec. Модель может предложить ответы, но решение здесь не её.

Стартовая версия: один сценарий, три критерия приёмки, список «вне скоупа».

Как это выглядит. Spec на фичу — сценарий из трёх-четырёх шагов («выбрать → оплатить → получить подтверждение»), три-пять проверяемых критериев приёмки («не больше трёх экранов», «состояние „нет мест“ показывается до оплаты», «письмо приходит в течение минуты»), явный список того, что вне скоупа, и один-два открытых вопроса владельцу задачи с ответами.

Стратегия у продукта уже есть, даже если она нигде не записана. Твоя работа — вытащить её из живого продукта и проверить, не противоречит ли ей новая задача. Памятка голоса собирается из реальных текстов (тема «Написание контента и UX-текстов», раздел про голос бренда как систему):

Вот 25 реальных текстов из продукта (вставить). Собери из них памятку голоса: 3–4 принципа с расшифровкой, 5–7 пар «так — да / так — нет» из этих же текстов, словарь терминов продукта, правила про «ты/вы», эмодзи и восклицательные знаки. Отметь тексты, которые выбиваются из общего тона

Затем одна проверка: «Вот памятка голоса, позиционирование продукта и spec новой фичи. Где они противоречат друг другу?» Если противоречий нет — хорошо. Если есть — это разговор с владельцем задачи до, а не после сборки.

Если вводных нет: позиционирование в одно предложение, три ключевых сообщения и тон парами «да / нет» собираются из брифа (тема «Брейншторминг с ИИ»). Конкурентов ищи моделью с включённым поиском (тема «Поиск и ресерч контента»), а не по памяти модели.

На основе брифа (вставить) собери стратегический документ: позиционирование в одно предложение, три ключевых сообщения, тон голоса — 3–4 принципа, к каждому пара «так — да / так — нет», и короткая таблица сравнения с тремя реальными конкурентами с источниками

Стартовая версия: три сообщения и три пары «да / нет».

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

Здесь ты не придумываешь стиль, а работаешь внутри уже принятого. Три правила:

1. Стайл-гайд берётся из брендбука, а не пишется заново. Попроси модель перевести брендбук в фиксированную часть промпта: «Вот брендбук (приложить). Собери из него фиксированную часть промпта для генерации изображений: палитра в hex, свет, композиция, что запрещено». Если вводных нет — эта часть у тебя уже написана на этапе 0.
2. Интерфейсные элементы — только из дизайн-системы. Кнопки, поля, карточки для новой фичи собираются из существующих компонентов через Figma MCP, а не рисуются заново. Токены, а не hex-коды на глаз.
3. Там, где системы не хватает, её расширяют, а не обходят. Компонент или состояние, которого нет в системе, всплывёт в аудите почти наверняка. Правильный ход — спроектировать его в логике системы, назвать по её конвенциям и добавить в библиотеку с описанием, чтобы следующий дизайнер его нашёл (тема «AI-first дизайн-системы»).

Открой дизайн-систему по ссылке (Figma MCP) и брендбук (приложить). Мне нужен компонент [название] для [фича]. Предложи его в логике системы: какие существующие токены и компоненты переиспользовать, как назвать по конвенциям библиотеки, какие состояния нужны. Ничего не создавай, пока я не подтвержу

Новые ассеты — баннеры кампании, иллюстрации для раздела, продуктовые изображения — генерируются по стайл-гайду и проверяются на нейрослоп относительно бренда (тема «Нейрослоп»): не «красиво ли», а «опознал бы это как наш продукт человек, который видел сайт». Продуктовая серия и промо — разные задачи: продуктовая про точность, промо про ощущение.

Продуктовый кадр: точность

Промо: ощущение

Промпт

Используй стайл-гайд: Палитра: глубокий оливковый #3E4A3D, тёплый молочный #F4EFE6, медный акцент #D98E4A. Свет: мягкий северный свет из окна, без жёстких теней. Композиция: сверху или в 3/4, много воздуха. Материалы: матовая керамика, лён, светлое дерево. Настроение: спокойное, неторопливое. Запрещено: глянец, градиенты, неон, текст на изображении. Продуктовый кадр: коробка набора еды на неделю с тремя открытыми контейнерами, вид сверху, нейтральный фон, каждое блюдо хорошо видно.

Используй стайл-гайд: [вставить фиксированную часть]. Сгенерируй промо-визуал для [фича]: сцена, где человек разного типажа и возраста использует продукт [краткий сценарий] в естественной обстановке, настроение — [из принципов памятки голоса]

Если у продукта есть реальные фото — редактируй их (тема «Редактирование изображений и ретушь»), а не генерируй с нуля. Людей в промо описывай явно по типажу и возрасту (тема «Генерация изображений», раздел «Скрытый перекос в генерации людей»). Иконки и знаки: концепты генерируй, финал доводи руками до вектора (тема «Вектор, иконки и иллюстрации»).

Стартовая версия: стайл-гайд как промпт, один новый компонент в логике системы, три ассета.

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

По стайл-гайду: 60 лет, кухня

По стайл-гайду: 35 лет, обед у окна

По стайл-гайду: 25 лет, вечер

Без стайл-гайда — «чужак»

Промпт

Используй стайл-гайд: Палитра: глубокий оливковый #3E4A3D, тёплый молочный #F4EFE6, медный акцент #D98E4A. Свет: мягкий северный свет из окна, без жёстких теней. Композиция: сверху или в 3/4, много воздуха. Материалы: матовая керамика, лён, светлое дерево. Настроение: спокойное, неторопливое. Запрещено: глянец, градиенты, неон, текст на изображении. Сгенерируй промо-визуал для сервиса доставки готовой еды на неделю: сцена, где [женщина лет 60] [раскладывает контейнеры с едой на кухонном столе] в естественной обстановке, настроение — спокойная забота о себе.

Тексты фичи пишутся по памятке голоса из этапа 2 и до сборки, одним документом (тема «Написание контента и UX-текстов»). Если оставить их на усмотрение модели во время вёрстки, тон потеряется первым. Покрывать нужно все состояния, а не только счастливый путь: пусто, загрузка, ошибка, «мест нет», успех (тема «ИИ в работе над макетом», раздел про состояния). Если продукт многоязычный, тексты сразу пишутся с оговоркой про перевод: без идиом, с запасом длины.

Вот памятка голоса (вставить) и spec фичи (вставить). Составь матрицу состояний для экрана [фича] и напиши текст для каждого состояния в этом голосе. Отдельно отметь строки, которые сломаются при переводе на английский

Стартовая версия: заголовок экрана, один CTA, пустое состояние и ошибка.

Как это выглядит. Матрица состояний в 04-content.md, где у каждой ячейки есть текст, и ни одно состояние не заканчивается тупиком: «На эту субботу все места разобрали. Ближайшая свободная — 12 октября» с кнопкой на неё.

Фича собирается по 01-spec.md из этапа 1, на токенах дизайн-системы, агентом с доступом к Figma MCP и правилами проекта в CLAUDE.md (темы «Вайбкодинг: интерфейсы», «Терминальные агенты: настройка под себя»). После сборки — отдельный ревьюер с чистым контекстом, который сверяет результат со спецификацией и правилами и ничего не исправляет сам (тема «Своя обвязка»):

Реализуй фичу по 01-spec.md. Компоненты и токены — только из дизайн-системы (Figma MCP подключён), новые значения не придумывай. Тексты — из 04-content.md, состояния — все из матрицы. После реализации вызови сабагента spec-reviewer и покажи мне его список расхождений до того, как что-то исправлять

Если проект живёт в реальном репозитории команды, работа идёт в отдельной ветке, а не в основной (тема «Вайбкодинг: интерфейсы», раздел про git). Если репозитория нет, стартовая версия — мокап в разговорном UI-инструменте (тема «Дизайн-мышление до кода») или страница в веб-агенте (тема «Вайбкодинг: сайты»). Промпт там нужен другой. В Figma Make, Stitch, v0, bolt и Lovable нет папки проекта, а доступ к Figma там ограничен или требует платного плана. Поэтому всё, на что агент опирается, вкладывается прямо в сообщение:

Собери экран [фича]. Ниже — спецификация (вставить текст 01-spec.md целиком), матрица состояний и тексты (вставить 04-content.md), токены дизайн-системы (вставить имена и значения: цвета, шрифты, радиусы, отступы) и скриншоты существующих компонентов (приложить). Используй только эти токены и компоненты, новых значений не вводи; реализуй все состояния из матрицы с текстами дословно. Если чего-то не хватает — спроси, а не придумывай.

Стартовая версия: мокап экрана с двумя состояниями из матрицы.

Как это выглядит. Фича в отдельной ветке feature/[название] или живая ссылка на мокап; ревьюер нашёл расхождения со spec — все исправлены до показа команде.

Проверять нужно по критериям, а не по ощущению (тема «Оценка и критика результатов ИИ»):

• Эвристики. Прогнать экран по десяти эвристикам Нильсена с привязкой к элементам.
• Симуляция пользователя. Модель в роли человека из целевой аудитории проходит сценарий и отмечает, где непонятно. Это не заменяет живого человека, но ловит очевидное.
• Состояния и доступность. Проверка по разделам про состояния и аудит доступности из темы «ИИ в работе над макетом». На учебных проектах этот шаг пропускают чаще всего, а именно он отличает «нарисовал экран» от «спроектировал продукт».
• Другая модель. Показать результат не той модели, что его делала.

Войди в роль пользователя из целевой аудитории [описание]: [сценарий использования]. Пройди его шаг за шагом по этому экрану (вставить ссылку/скриншоты) и честно отметь, на каком шаге было непонятно, долго или неприятно, и почему

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

Найденное исправляй до следующего этапа. Список «на потом» на этой стадии превращается в «никогда».

Стартовая версия: одна эвристическая оценка и один живой человек.

Как это выглядит. Ревью ролями на типичной фиче: адвокат доступности нашёл компонент без клавиатурной навигации, бренд-пурист — восклицательный знак в письме, разработчик спросил, что показывать между отправкой формы и ответом. Все три пункта в 06-ux-review.md с пометками «исправлено» и датой.

Передача — половина работы, и ИИ снимает с неё большую часть рутины:

1. Handoff. Спецификация для разработчика по экрану и матрице состояний, с токенами и именами компонентов из системы, а не описаниями словами (тема «ИИ в работе над макетом», раздел про handoff). Если фича уже собрана агентом — ссылка на ветку плюс список того, что нужно проверить руками.
2. Презентация решения. Руководителю и команде показывается не экран, а связка «задача → принцип → решение → доказательство» с двумя вариантами и рекомендацией. Принцип тот же, что при показе клиенту (тема «Презентации и питч-деки с ИИ», раздел про показ дизайна клиенту), только возражения внутри компании обычно про сроки и приоритеты, а не про вкус. Прогоняй их заранее через роль скептика.
3. Обновление системы. Новые компоненты и состояния задокументированы в библиотеке, брендбук дополнен тем, что аудит на этапе 0 нашёл незаписанным — памяткой голоса, правилом про радиусы.
4. Что остаётся команде. prompts.md с шаблонами этого проекта, CLAUDE.md с правилами, скилл для повторяющейся процедуры и сабагент-ревьюер (тема «Своя обвязка»). Это термины Claude Code. В Cursor правила живут в .cursor/rules, в Codex — в AGENTS.md, а скиллы и сабагенты есть не во всех агентах. Следующая такая задача должна занять вдвое меньше времени — это и есть продакшн-процесс, а не разовая удача.
5. Кейс. Даже рабочий проект упаковывается в кейс по структуре из темы «Портфолио»: проблема, роль ИИ, что сделано руками, до/после, результат. Для выдуманного продукта это главный результат проекта.

Собери handoff для разработчика по [фича]: компоненты и их состояния с именами из дизайн-системы, использованные токены, поведение по нажатию, крайние случаи из матрицы состояний, что не реализовано и почему. Отдельным списком — вопросы, на которые в макете нет ответа

Стартовая версия: handoff на одну страницу и кейс на 100 слов.

Как это выглядит. Ветка передана, handoff на одну страницу, в брендбуке появилась памятка голоса, в библиотеке — новый компонент с описанием, в репозитории — CLAUDE.md и скилл для такой же задачи, по которому следующий раздел собрали за вечер.

Проект легко превращается в россыпь чатов и картинок, из которой через месяц не собрать ни кейс, ни процесс. Заведи папку до начала работы и складывай в неё результаты по ходу.

project/
  00-audit.md            что есть: брендбук, система, тексты, расхождения (или бриф, если продукт выдуманный)
  00-constraints.md      что менять нельзя, языки, устройства, юридические требования
  01-spec.md             задача, сценарии, критерии приёмки, что вне скоупа, ответы на открытые вопросы
  02-voice.md            памятка голоса из живых текстов; позиционирование и три сообщения
  03-visual/
    styleguide.md        фиксированная часть промпта: палитра в hex, типографика, свет, настроение
    assets/              новые изображения: продуктовые, промо, иллюстрации
    system-additions.md  новые компоненты и состояния, добавленные в дизайн-систему
  04-content.md          все тексты одним документом, включая матрицу состояний
  05-build/              ссылка на ветку, мокап или страницу; скриншоты ключевых экранов
  06-ux-review.md        найденные проблемы: что принято, что отклонено и почему, что исправлено
  07-handoff.md          спецификация для разработчика
  07-case.md             кейс и ссылка на презентацию
  prompts.md             рабочие промпты по этапам — с пометкой, в каком инструменте
  log.md                 журнал решений: что пробовал, что не сработало, что сделал руками

Два последних файла — самые ценные. prompts.md показывает, как ты думаешь, log.md — где именно был нужен человек.

Оценивать проект по ощущению «вроде получилось» бесполезно. Пройди рубрику сам, потом отдай её вместе с артефактами модели, которая в проекте не участвовала, и сравни. Расхождение на два уровня — повод посмотреть на это место ещё раз.

Проект готов, когда нет ни одной единицы, а хотя бы по двум критериям стоит три. Единица — не провал, а точный адрес темы, которую нужно перечитать.

Фича передана и принята, система стала богаче, а не грязнее, и у команды осталось то, чем она воспользуется в следующий раз. Если через месяц похожую задачу делают по твоим шаблонам — проект закончен правильно. Для выдуманного продукта: кейс можно показать незнакомому человеку, и он за 30 секунд поймёт, что за продукт, что ты сделал и где был нужен именно ты.

Вот брендбук (приложить) и spec новой фичи (вставить). Найди, где они противоречат друг другу, и сформулируй три вопроса владельцу задачи — продакту или руководителю, — которые нужно закрыть до начала работы

Вот 25 реальных текстов из продукта (вставить). Собери памятку голоса: принципы, пары „так — да / так — нет“ из этих же текстов, словарь терминов, правила про „ты/вы“ и восклицательные знаки

Вот памятка голоса (вставить) и матрица состояний экрана [фича] (вставить). Напиши текст для каждого состояния так, чтобы ни одно не заканчивалось тупиком — везде есть следующий шаг

Прогони этот экран (вставить ссылку/скриншоты) по 10 эвристикам Нильсена и укажи 5 самых критичных нарушений с привязкой к конкретным элементам

Сыграй роль руководителя, который считает [фича] лишней и хочет решить задачу одной кнопкой. Я покажу презентацию решения по слайдам — задавай к каждому самый неудобный вопрос

Вот рубрика самооценки (вставить таблицу) и артефакты моего проекта (приложить файлы и скриншоты). Ты не участвовал в проекте. Оцени его по каждому критерию от 1 до 3 с одним предложением обоснования, ссылаясь на конкретный артефакт. Там, где данных для оценки не хватает, — так и скажи

У меня выдуманный продукт: [одно из четырёх описаний]. Задай мне по одному вопросу за раз, чтобы собрать бриф и придумать одну фичу размером в один экран, которая задевает и визуал, и тексты, и передачу разработчику

Проведи аудит дизайн-системы под задачу [описание]: какие компоненты и состояния есть, каких не хватает, где значения в макетах расходятся с токенами. Результат запиши в 00-audit.md, ничего не меняй

Собери handoff по экрану [ссылка на фрейм]: компоненты и состояния с именами из системы, токены, поведение, крайние случаи, вопросы без ответа в макете