design-mirror

Design Mirror — официальный skill Bright Data для разбора визуального языка публичного сайта и аккуратного переноса найденных принципов в уже существующий frontend. Он предназначен для случаев, когда нужно понять, почему референсный интерфейс выглядит определённым образом, а затем применить похожее визуальное направление к своему коду, не копируя чужой текст, разметку или функциональность. Владелец прямо описывает этот skill как инструмент для design inspiration and learning: результатом должен быть перенос визуальных решений, а не клонирование исходного сайта. Рабочий процесс начинается со сбора двух представлений референса. Screenshot нужен для визуального анализа, а HTML scrape — для структурного разбора CSS. Для захвата предусмотрены отдельные shell-скрипты: один сохраняет PNG, второй получает HTML и CSS. Оба действия выполняются через Bright Data Web Unlocker, поэтому перед запуском нужны BRIGHTDATA_API_KEY и BRIGHTDATA_UNLOCKER_ZONE. Эти переменные не являются содержимым каталога и должны быть предоставлены в окружении запуска. Без доступа к Web Unlocker полный сценарий capture не считается выполненным; при этом сам skill отдельно допускает ограниченный разбор по скриншоту, если JavaScript-рендеринг оставил HTML почти пустым. На этапе визуального анализа skill предлагает последовательно зафиксировать основные свойства интерфейса: первичный, вторичный и акцентный цвета; фоны страницы, карточек и поверхностей; основной и приглушённый цвет текста; семейства шрифтов и иерархию размеров от заголовка до подписи; ширину контейнера, сетку, боковую панель и ритм раскладки; радиусы карточек и тип тени; форму кнопок, навигацию, липкое позиционирование, прозрачность и размытие; общий характер светлой, тёмной, минималистичной, корпоративной или другой визуальной системы. Это не список обязательных эффектов: каждый пункт нужно выводить из доступного screenshot и публичного CSS, а не добавлять по шаблону. HTML-анализ дополняет картинку. Из style-блоков и inline-стилей извлекаются публично объявленные CSS custom properties, импорты шрифтов, настройки Tailwind, если они видны в исходнике, и повторяющиеся классы, по которым можно понять шкалу отступов. После этого формируется карта токенов: цвета поверхностей и границ, типографика, базовый шаг spacing, радиусы, тени, blur и градиенты. Такая карта нужна до изменения собственного кода: она помогает отделить наблюдаемые свойства референса от случайных деталей одной страницы и не размазывать разрозненные значения по компонентам. Перед применением нужно определить архитектуру проекта, который будет изменён: React, Vue или plain HTML; Tailwind, CSS Modules, styled-components, Emotion или обычный CSS; расположение глобальных стилей и список компонентов, которым действительно требуется restyle. Skill рекомендует сначала применить базовые цвета, типографику и spacing, а затем последовательно обновлять кнопки, карточки, навигацию и другие элементы. Для Tailwind используются его конфигурация и CSS-переменные, для обычного CSS — блок :root, для CSS-in-JS — существующая theme-конфигурация. Существующая структура и функциональность должны сохраняться; меняются визуальные свойства, а не поведение приложения. Изменения должны быть хирургическими, поэтому не следует переписывать весь интерфейс ради сходства с одной страницей. Практические сценарии включают разбор лендинга перед редизайном, извлечение дизайн-токенов из публичного референса, согласование цветов и типографики в существующем UI, настройку формы карточек и кнопок, а также перенос общего layout-ритма на несколько внутренних страниц. Если страниц несколько, homepage используется как источник общих токенов, а отдельные разделы проверяются только при необходимости. Если референс построен на Material, shadcn или другой компонентной системе, сначала определяется эта система; затем принимается решение, нужно ли адаптировать её тему или достаточно взять визуальные токены. Если CSS минифицирован или скрыт, полноценное структурное извлечение ограничено, и надёжнее фиксировать только то, что видно на screenshot. Ограничения важны для безопасного использования. Публичная доступность страницы не означает разрешение копировать её контент, брендинг, уникальную графику или рабочие функции. Skill требует уважать условия использования сайтов, на которые смотрит capture, и использовать найденные цвета, размеры, шрифты, формы и другие токены как визуальное вдохновение. Он не обещает автоматического pixel-perfect клонирования: качество зависит от screenshot, доступности HTML/CSS, корректности карты токенов и того, насколько хорошо эти токены сочетаются с существующей компонентной библиотекой. Перед массовым применением нужно проверить desktop/mobile, состояния hover и режимы темы. Для страницы с неполным HTML результатом следует явно отделять наблюдение от предположения и не выдавать визуальную оценку за факт, найденный в CSS. Таким образом, design-mirror полезен не как генератор нового UI с нуля, а как воспроизводимый порядок исследования и точечного restyle: capture публичного референса, извлечение дизайн-языка, карта токенов, проверка архитектуры текущего приложения и постепенное применение без поломки поведения. Его сильная сторона — соединение screenshot-анализа с CSS-источником; его естественный предел — отсутствие достоверных данных там, где сайт закрыт, динамически отрисован, минифицирован или требует недоступных credentials.