design-taste-frontend

Skill design-taste-frontend — это практический workflow для выразительных landing pages, portfolios и redesign-интерфейсов. Его центральная идея — не начинать с заранее выбранного визуального шаблона. Перед написанием кода агент должен прочитать brief и определить тип страницы: лендинг SaaS, consumer-лендинг, агентский сайт, портфолио разработчика или дизайнера, redesign с сохранением основы или redesign с полной сменой направления, а также editorial/blog-страницу. Затем учитываются слова о настроении, референсы, предполагаемая аудитория, уже существующие брендовые материалы и тихие ограничения вроде доступности, регулируемой отрасли или доверительного сценария. В результате сначала формируется короткий Design Read: для кого делается страница, каким языком она должна говорить и к какой эстетической семье относится. Если из brief нельзя уверенно понять направление и возможны существенно разные решения, источник рекомендует задать один уточняющий вопрос, а не угадывать. После чтения brief skill предлагает зафиксировать три параметра: DESIGN_VARIANCE, MOTION_INTENSITY и VISUAL_DENSITY. Они описывают соответственно степень симметрии или асимметрии, интенсивность движения и визуальную насыщенность. Базовая комбинация равна 8/6/4, но она меняется под контекст: спокойный или editorial-проект получает меньшую вариативность и меньше движения, премиальный consumer-сценарий — умеренные значения, а экспериментальный creative-сайт — более высокую вариативность и motion. Для лендинга, портфолио и redesign предусмотрены отдельные ориентиры. Эти параметры нужны не как декоративные настройки, а как общий фильтр для решений о композиции, плотности и анимации: в последующих секциях нельзя незаметно перейти к другой логике. Для фундамента источник разделяет реальные дизайн-системы и эстетические направления. Если brief явно относится к Microsoft, Material, IBM Carbon, Shopify Polaris, Atlassian, GitHub Primer, GOV.UK, USWDS или другой перечисленной системе, рекомендуется пользоваться официальным пакетом этой системы и не воспроизводить её токены вручную. В одном проекте следует держаться одной системы. Если речь идёт об эстетике, а не о пакете, предлагаются честные нативные реализации: CSS для glassmorphism, CSS Grid для bento-композиции, нативный CSS для brutalism, serif и свободного пространства для editorial, моноширинной типографики для dark-tech и layered gradients или SVG для aurora. Для Apple Liquid Glass отдельно отмечено, что официального web-пакета liquid-glass.css нет: веб-реализация является приближением на backdrop-filter, границах и подсветках и должна так называться. Архитектурные рекомендации ориентированы на обычный React или Next.js с Server Components по умолчанию. Глобальное состояние разрешено только в Client Component-провайдере, а интерактивные листья с Motion, scroll listeners или pointer physics должны быть изолированы. В качестве обычного стека названы Tailwind v4, Motion из motion/react и next/font либо self-hosted @font-face с font-display: swap. Для локального состояния достаточно useState или useReducer; непрерывные значения мыши, scroll progress и физики не следует проводить через React state. Для иконок предпочтительны уже поддерживаемые библиотеки, причём внутри дерева нужно сохранять одну иконографическую семью и не рисовать SVG-пути вручную. Перед импортом сторонней библиотеки нужно проверить package.json, а не предполагать, что зависимость уже есть. Правила pre-flight помогают не свести дизайн к набору одинаковых карточек. На странице выбирается одна акцентная палитра и соблюдается единая логика скруглений; случайные AI-purple gradients и неуместные glow-эффекты не должны появляться по умолчанию. Карточки применяются только там, где elevation действительно показывает иерархию, иначе предпочтительны границы, разделители и свободное пространство. Для desktop hero должен помещаться в начальный viewport: заголовок ограничен двумя строками, подзаголовок — двадцатью словами и несколькими строками, а CTA должны быть видны без прокрутки. Навигация должна оставаться однострочной и не превышать разумную высоту. В bento-сетке число ячеек равно числу реальных элементов, а повторяющиеся layout-семейства, длинная цепочка одинаковых split-блоков и избыточные eyebrow-лейблы ограничиваются. Доступность и состояния считаются частью готового интерфейса, а не последующим украшением. Для интерактивных элементов нужны loading, empty и error-состояния, а контраст текста кнопок, полей, placeholder, focus ring и сообщений об ошибках должен соответствовать WCAG AA. Label ставится над input, placeholder не заменяет label, ошибка находится под полем. CTA не должен переноситься на desktop, а две разные подписи с одним намерением не следует размножать по странице. Мобильный fallback для каждой многоколоночной секции фиксируется прямо в компоненте. Практический результат этого skill — не универсальная библиотека компонентов, а дисциплина чтения brief, выбора уместной системы, сборки композиции и финальной проверки. Источник прямо ограничивает область landing pages, portfolios и redesign и не заявляет этот workflow как готовое решение для dashboard, data table или многошагового product UI.