Website Cloner: чужой сайт → работающий клон

Лиза получила от заказчика ссылку и одну фразу: «хочу так же». Первая мысль — наснимать скриншотов и сверстать похоже на глаз. Через день выясняется, что «похоже» и «так же» — разные вещи: отступы гуляют, шрифт не тот, а шапка при прокрутке ведёт себя совсем иначе.

Навык clone-website делает другое: он превращает чужую страницу в работающий проект на Next.js, а не в картинку. Ты даёшь одну ссылку или сразу несколько — навык снимает с живой страницы точные значения стилей, скачивает настоящие изображения, шрифты и тексты и собирает из этого компоненты, которые проходят npm run build.

Включается он сам, когда ты пишешь ассистенту «склонируй этот сайт», «пересобери эту страницу», «сделай пиксель-в-пиксель клон» или «разбери этот сайт». Ссылки идут аргументами: /clone-website https://example.com.

У навыка два соседа, с которыми его легко перепутать:

• reverse-engineering-unicorn разбирает бизнес чужого продукта и выдаёт разбор словами, а не код;
• frontend-design придумывает новый интерфейс, а не повторяет существующий.

Границы навык объявляет сам, до первого запроса. В объёме: внешний вид, структура компонентов, взаимодействия, адаптивность и демонстрационные данные. Вне объёма: настоящий бэкенд, авторизация, живые данные, SEO и аудит доступности.

Компромисс: ты получаешь точность там, где она видна снаружи, и не получаешь ничего внутри. Лиза узнает об этом в тот момент, когда заказчик спросит: «а форма-то работает?»

Большинство навыков в этой экосистеме самодостаточны: поставил — работает. clone-website устроен иначе, и README предупреждает об этом первым же блоком со значком внимания. Этот блок — не примечание мелким шрифтом, а половина инструкции.

Навыку нужны две вещи, которых в пакете нет:

1. Браузерный MCP — Chrome, Playwright, Browserbase или Puppeteer. Это глаза и руки навыка: снимки экрана, точные значения стилей из getComputedStyle(), прокрутка, клики, наведение. Если доступно сразу несколько, предпочтение отдаётся Chrome MCP. В этой экосистеме условие закрывают qe-browser (Vibium) из @dzhechkov/skills-qe или browser-qa из @dzhechkov/skills-ecc. Без браузера навык не работает вообще — не хуже, а никак.
2. Готовый scaffold — проект Next.js 16 + React 19 + Tailwind v4 + shadcn/ui, в котором npm run build уже проходит. Это место, куда навык кладёт результат.

Лиза попробовала запустить клонирование на пустой папке и получила остановку на первом же шаге — и это правильное поведение. Шаг Pre-Flight проверяет предусловия до того, как потрачена хоть минута: есть ли браузерный MCP, разбираются ли переданные ссылки, открываются ли они, проходит ли сборка базового проекта. Заодно он создаёт каталоги docs/research/, docs/research/components/, docs/design-references/ и scripts/.

Если сайтов несколько, Pre-Flight готовит отдельные папки под каждый — например docs/research/example.com/, — чтобы находки одного сайта не перемешались с находками другого.

Компромисс: пакет не тащит за собой браузер и шаблон проекта, поэтому он лёгкий и не навязывает тебе свою версию Next.js — но первый запуск требует получаса подготовки, которого не требует ни один другой навык.

Установка занимает одну строку. Лиза выполняет её в корне того самого проекта Next.js, который подготовила в прошлой секции:

npx @dzhechkov/skills-website-cloner init

После этого в Claude Code появляется команда, и первый запуск выглядит так: /clone-website https://example.com. Ссылок можно передать несколько через пробел.

У пакета пять команд, и init — та, что выполняется по умолчанию:

1. init — раскладывает навык и команду в .claude/;
2. update — обновляет уже разложенные файлы;
3. remove — убирает их;
4. list — показывает, что установлено;
5. doctor — проверяет установку: все ли файлы на месте, лежит ли SKILL.md там, где его ждут.

Два флага стоит запомнить до первого запуска, а не после. --dry-run показывает, что будет сделано, ничего не меняя, — Лиза начинает с него всегда, потому что ставит навык в чужой рабочий проект. --force перезаписывает существующие файлы без вопросов; он нужен, когда ты сознательно возвращаешь файлы к состоянию пакета. Есть ещё --help и --version.

Где посмотреть первоисточник: страница пакета на npm и исходники в репозитории.

Компромисс: установка через npx не требует ничего глобального и всегда берёт свежую версию, но она же и не фиксирует версию сама — если тебе нужна воспроизводимость, версию придётся назвать явно.

Лиза сначала представила себе привычный порядок: изучаем сайт целиком, потом верстаем целиком. Навык устроен не так, и разница здесь принципиальная.

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

Фаз пять, и они не строго последовательные:

1. Разведка — снимки экрана, шрифты, цвета, обязательный проход по поведению страницы;
2. Фундамент — шрифты, токены цветов, типы, иконки, скачанные ассеты;
3. Спецификации и отправка — точные значения CSS по каждой секции, файл спецификации, строители в отдельных рабочих деревьях git;
4. Сборка страницы — всё собирается вместе в src/app/page.tsx;
5. Визуальная сверка — снимки клона против оригинала, секция за секцией.

Внахлёст идут именно фазы 3 и 4: строители работают параллельно в своих ветках, пока разведка продолжается. Фаза 2 — исключение, о ней отдельно в седьмой секции.

Зачем такая сложность. Прямая выгода — время: ты не ждёшь окончания разведки, чтобы начать стройку. Непрямая, и она важнее: каждый строитель получает свою маленькую задачу с полным описанием и не соревнуется с другими за один и тот же файл — каждый сидит в своём рабочем дереве git.

Компромисс: параллельность экономит часы, но за неё платят слиянием веток и разбором конфликтов; после каждого слияния сборку приходится проверять заново.

Лиза открыла оригинал, сняла две длинные страницы целиком — на 1440 пикселях и на 390 — и решила, что разведка закончена. Она закончена ровно наполовину: сайт это не картинка, а живая штука, и половина его поведения на снимке не видна.

Поэтому в разведке есть отдельный обязательный этап — проход по поведению. Он идёт после снимков и до всего остального, и состоит из четырёх проходов:

1. Прокрутка — медленно сверху вниз. Меняется ли шапка и на какой высоте? Появляются ли блоки с анимацией? Переключается ли что-то само по мере прокрутки? Есть ли залипание блоков (scroll-snap)? Работает ли библиотека плавной прокрутки — например Lenis, её выдаёт класс .lenis?
2. Клики — по каждой кнопке, вкладке, карточке. Что меняется, что открывается? Для вкладок нажимается каждая, и содержимое каждой записывается отдельно.
3. Наведение — на кнопки, карточки, ссылки, картинки: цвет, масштаб, тень, подчёркивание, прозрачность.
4. Ширины — 1440, 768 и 390. Где колонки превращаются в столбик, где пропадает боковая панель, около какой ширины это происходит.

Всё найденное складывается в docs/research/BEHAVIORS.md — это справочник поведения, к которому потом обращается каждая спецификация. Карта секций страницы сверху вниз ложится в docs/research/PAGE_TOPOLOGY.md и служит планом сборки.

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

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

Лиза увидела блок с боковым списком и панелями справа: пункт слева подсвечен, справа — соответствующее содержимое. Она нажала на второй пункт, содержимое сменилось — и она честно записала «вкладки, переключаются кликом». Строитель собрал вкладки. А на оригинале пункты переключались сами, по мере прокрутки, и клик был лишь запасным способом.

Это самая дорогая ошибка в клонировании: перепутанная модель взаимодействия чинится переписыванием секции, а не правкой стиля. Поэтому вопрос «чем управляется эта секция?» задают до того, как написана хоть одна строка спецификации, а ответов всего четыре: прокрутка, клик, наведение или время.

Порядок проверки не произвольный:

1. Не кликай первым. Медленно прокрути секцию и смотри, меняется ли что-то само.
2. Если меняется — это прокрутка. Разберись, чем именно она реализована: IntersectionObserver, scroll-snap, position: sticky, animation-timeline или обработчик прокрутки.
3. Только если при прокрутке ничего не происходит — начинай кликать и наводить.
4. Запиши вывод в спецификацию прямым текстом: «модель взаимодействия: прокрутка через IntersectionObserver» или «модель взаимодействия: переключение кликом с плавным изменением прозрачности».

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

Компромисс: отдельная проверка перед каждой интерактивной секцией тормозит разведку на пару минут. Ошибка на этом месте стоит переписывания компонента целиком — обмен явно в пользу проверки.

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

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

Что входит в фундамент:

1. Шрифты в layout.tsx — те же семейства и начертания, что на оригинале, через next/font;
2. Цвета и токены в globals.css — палитра оригинала в блоках :root и .dark, разложенная по именам shadcn там, где они подходят, и добавленная своими свойствами там, где не подходят;
3. Типы контента в src/types/ — структуры, которые ты увидел на странице;
4. Иконки — все инлайновые <svg> со страницы, без повторов, как именованные компоненты в src/components/icons.tsx;
5. Ассеты — скрипт scripts/download-assets.mjs скачивает изображения и видео в public/, пачками по четыре;
6. Контрольная сборка — npm run build обязан пройти до того, как разъедутся строители.

Лиза попробовала пропустить шаг с иконками, чтобы «добавить их потом». Потом каждый строитель нарисовал свою стрелку, и на странице оказалось четыре разных стрелки вправо.

Компромисс: последовательный этап — узкое место, через которое проходит вся работа, и ускорить его нельзя. Взамен всё, что идёт после, действительно можно делать параллельно, ничего не согласовывая.

Между разведкой и стройкой лежит один файл: docs/research/components/<имя>.spec.md. Он не украшение процесса, а договор: всё, чего в нём нет, строитель додумает сам — а додумывает он всегда мимо.

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

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

Шесть разделов, которые заполняются всегда:

• Обзор — какой файл создаётся, где лежит снимок секции, какая у неё модель взаимодействия;
• Структура DOM — что во что вложено;
• Вычисленные стили — точные значения по каждому элементу;
• Состояния и поведение — триггер, состояние «до», состояние «после», переход;
• Ассеты и текст — какие файлы из public/, какие иконки, и текст дословно с живого сайта;
• Адаптивность — что меняется на 1440, 768 и 390 и около какой ширины.

Лиза сначала писала «прочерк» в разделе про состояния для подвала — «там же ничего не происходит». Оказалось, у ссылок в подвале есть подчёркивание при наведении с плавностью в 200 миллисекунд. Прочерк ставят, только если действительно проверили.

Компромисс: заполнение шести разделов на каждую секцию — самая скучная часть работы. Она же единственная, которая делает результат воспроизводимым: спецификация переживает и сессию, и агента.

Вопрос без простого ответа: насколько мелко резать работу? Слишком крупно — строитель начинает приближать: «тут примерно шестнадцать пикселей, тут вроде полужирный». Слишком мелко — ты тонешь в согласовании кусочков.

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

Практический ориентир такой:

• секция с одним-двумя под-компонентами — один строитель на всю секцию;
• секция с тремя и более различными под-компонентами — по строителю на каждый плюс отдельный строитель на обёртку, которая их собирает;
• под-компоненты идут первыми, обёртка — после них, потому что она от них зависит.

Под-компонент — это элемент со своим оформлением, своей структурой и своим поведением: карточка, пункт меню, панель поиска.

Дальше строители расходятся по отдельным рабочим деревьям git и работают одновременно. Каждый обязан перед завершением проверить типы командой npx tsc --noEmit. Ты сливаешь их ветки по мере готовности и после каждого слияния проверяешь, что npm run build всё ещё проходит.

Лиза отдала одному агенту «секцию с преимуществами» — три разных вида карточек со своими состояниями наведения. Вернулось три карточки, похожие друг на друга, и ни одна не совпала с оригиналом.

Компромисс: мелкое дробление даёт точность, но увеличивает число веток, слияний и конфликтов. Правило 150 строк — это найденная опытом середина, а не закон природы.

Все ветки слиты, сборка зелёная. Лиза уже открыла переписку с заказчиком, чтобы отчитаться о готовности. Навык на этом месте прямо запрещает объявлять клон готовым. Сборка доказывает, что код компилируется; она ничего не говорит о том, похож ли результат на оригинал.

Сначала фаза сборки страницы: компоненты собираются в src/app/page.tsx — порядок секций по карте топологии, слои по глубине, липкие элементы, поведение уровня страницы (залипание при прокрутке, появление блоков, плавная прокрутка). Затем npm run build должен пройти начисто.

После этого — визуальная сверка. Она устроена как сравнение двух колонок:

1. Открой оригинал и клон рядом или сними их на одинаковой ширине;
2. Пройди сверху вниз, секция за секцией, на 1440;
3. Повтори на 390;
4. Проверь все взаимодействия: прокрути страницу, нажми каждую кнопку и вкладку, наведи на интерактивные элементы; убедись, что плавная прокрутка ощущается как на оригинале и переходы шапки работают.

Ключевой приём — при расхождении не бросайся править компонент. Сначала открой спецификацию этой секции и посмотри, что в ней написано. Если значение в спецификации неверное — виновата разведка: замерь заново браузером, поправь спецификацию, потом компонент. Если значение верное, а компонент другой — виноват строитель, правится только компонент.

Это вопрос к самому себе, а не к коду: где именно я ошибся — когда смотрел или когда строил? Ответ на него не даёт одной и той же ошибке повториться в следующих секциях.

Компромисс: сверка — самый нудный этап и её всегда хочется сократить до «ну вроде похоже». Ровно она отделяет пиксель-в-пиксель от «клиент заметил через неделю».

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

Самая дорогая стоит отдельно и названа в тексте прямо: перепутать прокрутку с кликами. Это переписывание секции целиком, а не правка стиля — потому что меняется не оформление, а способ, которым секция живёт.

Остальные двенадцать по убыванию неприятности:

• снять только состояние по умолчанию — вкладки, которые не открывали, и шапку, которую не прокручивали;
• не заметить наложенные картинки: фон-акварель плюс мокап поверх — это два изображения, а не одно;
• построить HTML-мокап там, где на оригинале видео, Lottie или canvas;
• писать «похоже на text-lg» вместо измеренного значения;
• собирать всё одним большим коммитом вместо проверяемых шагов;
• отправлять строителя к документу вместо того, чтобы вложить описание в задание;
• пропустить скачивание ассетов — без настоящих картинок и шрифтов клон выглядит подделкой при любом идеальном CSS;
• дать строителю слишком широкую задачу;
• смешать в одном задании несвязанные секции — призыв к действию и подвал это разные компоненты;
• проверить только настольную ширину;
• забыть про библиотеку плавной прокрутки: обычная прокрутка ощущается иначе, и это замечают сразу;
• отправить строителя без файла спецификации.

Видишь закономерность? Почти все они — один и тот же поступок: сэкономить минуту на извлечении и заплатить часами на переделке.

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

За каждым навыком стоит человек, и в этом пакете это записано явно. clone-website — импортированный навык: он пришёл из открытого проекта JCodesMore/ai-website-cloner-template под лицензией MIT, и авторские права на исходный навык принадлежат его автору.

Что «импортированный» значит на практике:

1. из первоисточника взят только файл SKILL.md — ни одного скрипта апстрима в пакет не переносили;
2. основные инструкции сохранены как есть; добавлены метка уровня доверия и якоря разделов, которые не меняют смысла, а делают текст навигируемым;
3. происхождение записано машиночитаемо в sources.json: первоисточник, путь к файлу, лицензия, атрибуция и перечень изменений;
4. там же в optional_deps названы те самые два предусловия — браузерный MCP и scaffold, — с пометкой, что они нужны при работе, но в пакет не входят;
5. канонизация в этот монорепозиторий выполнена по правилу ADR-0001 — решению о том, как чужие навыки попадают в общий дом.

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

Если у тебя стоит dz, отдельный установщик не нужен: навык ставится точечным выбором dz init --select clone-website, а посмотреть карточку навыка можно командой dz info clone-website.

Компромисс: импорт вместо собственной разработки дал зрелый навык сразу и с честной атрибуцией, но развитие первоисточника от тебя не зависит — обновления приходят извне.

Дальше Лиза уходит в тень, а решения принимаешь ты. Заказчик прислал две ссылки: лендинг с длинной прокруткой и страницу с ценами. Твой прогон — от Pre-Flight до отчёта.

Ориентир по шагам, а не инструкция: проверь предусловия и разбери ссылки; разложи находки по отдельным папкам вида docs/research/<имя сайта>/, чтобы два сайта не перемешались; сними страницы целиком на 1440 и 390; пройди по поведению всеми четырьмя проходами; собери фундамент; дальше — цикл «извлёк — написал спецификацию — отправил строителя — слил ветку», секция за секцией; собери страницу; сверься с оригиналом.

Закрывается прогон отчётом, и его состав задан навыком:

1. сколько секций построено;
2. сколько компонентов создано;
3. сколько файлов спецификаций написано — это число обязано совпадать с числом компонентов;
4. сколько ассетов скачано: изображения, видео, SVG, шрифты;
5. результат npm run build;
6. итоги визуальной сверки, включая оставшиеся расхождения;
7. известные пробелы и ограничения.

Обрати внимание на третий и седьмой пункты. Совпадение числа спецификаций и компонентов — простая арифметическая проверка того, что ни один строитель не ушёл без договора. А седьмой пункт требует назвать то, что не получилось: отчёт без раздела ограничений — это не отчёт, а обещание.

Компромисс: честный отчёт снимает с тебя половину будущих претензий, потому что расхождения названы тобой, а не найдены заказчиком. Но он же требует признать вслух то, что хотелось бы не заметить.