clone-website

Prompt file imported from hakantahta/clone-website-deneme (.windsurf/workflows/clone-website.md). Copyright stays with the author.

Clone Website — Laravel Blade Edition

You are about to reverse-engineer and rebuild the target URL provided by the user as pixel-perfect clones, output as clean Laravel Blade templates styled with Tailwind CSS v4 and made interactive with Alpine.js.

When multiple URLs are provided, process them independently and in parallel where possible, while keeping each site's extraction artifacts isolated in dedicated folders (for example, docs/research/<hostname>/).

This is not a two-phase process (inspect then build). You are a foreman walking the job site — as you inspect each section of the page, you write a detailed specification to a file, then hand that file to a specialist builder agent with everything they need. Extraction and construction happen in parallel, but extraction is meticulous and produces auditable artifacts.

The Hard Rules (read before anything else)

This project outputs Laravel Blade only. These rules are absolute and apply to every file you or any builder agent produces:

• NO React, NO Next.js, NO Vue, NO JSX/TSX, NO useState/useEffect/hooks, NO className. If you catch yourself writing a .tsx file or a className attribute, stop — you are off track.
• Every template is a .blade.php file. HTML attributes use class="...".
• All interactivity and state is Alpine.js — x-data, x-show, x-if, x-for, x-transition, x-collapse, x-cloak, x-init, x-model, x-intersect, @click, :class, :style. No jQuery, no bespoke vanilla-JS state machines when Alpine can do it.
• Output locations: reusable UI, layouts, sections, and icons go in resources/views/components/ (anonymous Blade components, <x-...>); full pages go in resources/views/pages/.
• Complete, paste-ready files only. Never emit fragments, ellipses, or "// rest of the section here" placeholders. Every file — Blade, CSS, or JS — must be the ENTIRE file and must work the instant it is saved.

Scope Defaults

The target is whatever page the target URL provided by the user resolves to. Clone exactly what's visible at that URL. Unless the user specifies otherwise, use these defaults:

• Fidelity level: Pixel-perfect — exact match in colors, spacing, typography, animations
• In scope: Visual layout and styling, component structure and interactions, responsive design, the <head>/meta markup, placeholder data where the source is server-generated
• Out of scope: Real backend / database, authentication, real-time features, accessibility audit
• Customization: None — pure emulation

If the user provides additional instructions (specific fidelity level, customizations, extra context), honor those over the defaults.

Pre-Flight

1. Browser automation is required. Check for available browser MCP tools (Chrome MCP, Playwright MCP, Browserbase MCP, Puppeteer MCP, etc.). Use whichever is available — if multiple exist, prefer Chrome MCP. If none are detected, ask the user which browser tool they have and how to connect it. This skill cannot work without browser automation.
2. Parse the target URL provided by the user as one or more URLs. Normalize and validate each URL; if any are invalid, ask the user to correct them before proceeding. For each valid URL, verify it is accessible via your browser MCP tool.
3. Verify the base project is healthy: composer install && npm install, then npm run build (Vite assets) and confirm php artisan serve boots. The Laravel + Blade + Tailwind v4 + Alpine.js scaffold should already be in place. If not, tell the user to set it up first.
4. Create the output directories if they don't exist: docs/research/, docs/research/components/, docs/design-references/, scripts/. For multiple clones, also prepare per-site folders like docs/research/<hostname>/ and docs/design-references/<hostname>/.
5. When working with multiple sites in one command, optionally confirm whether to run them in parallel (recommended, if resources allow) or sequentially to avoid overload.

Guiding Principles

These are the truths that separate a successful clone from a "close enough" mess. Internalize them — they should inform every decision you make.

1. Completeness Beats Speed

Every builder agent must receive everything it needs to do its job perfectly: screenshot, exact CSS values, downloaded assets with local paths, real text content, component structure. If a builder has to guess anything — a color, a font size, a padding value — you have failed at extraction. Take the extra minute to extract one more property rather than shipping an incomplete brief.

2. Small Tasks, Perfect Results

When an agent gets "build the entire features section," it glosses over details — it approximates spacing, guesses font sizes, and produces something "close enough" but clearly wrong. When it gets a single focused component with exact CSS values, it nails it every time.

Look at each section and judge its complexity. A simple banner with a heading and a button? One agent. A complex section with 3 different card variants, each with unique hover states and internal layouts? One agent per card variant plus one for the section wrapper. When in doubt, make it smaller.

Complexity budget rule: If a builder prompt exceeds ~150 lines of spec content, the section is too complex for one agent. Break it into smaller pieces. This is a mechanical check — don't override it with "but it's all related."

3. Real Content, Real Assets

Extract the actual text, images, videos, and SVGs from the live site. This is a clone, not a mockup. Use element.textContent, download every <img> and <video>, and extract inline <svg> elements as Blade icon components in resources/views/components/icons/. The only time you generate content is when something is clearly server-generated and unique per session.

Layered assets matter. A section that looks like one image is often multiple layers — a background watercolor/gradient, a foreground UI mockup PNG, an overlay icon. Inspect each container's full DOM tree and enumerate ALL <img> elements and background images within it, including absolutely-positioned overlays. Missing an overlay image makes the clone look empty even if the background is correct.

4. Foundation First

Nothing can be built until the foundation exists: resources/css/app.css with the target site's design tokens in @theme (colors as --color-*, fonts as --font-*, plus keyframes and custom utility classes), the base layout component (resources/views/components/layouts/app.blade.php), the Alpine bootstrap in resources/js/app.js, and global assets (fonts, favicons). This is sequential and non-negotiable. Everything after this can be parallel.

5. Extract How It Looks AND How It Behaves

A website is not a screenshot — it's a living thing. Elements move, change, appear, and disappear in response to scrolling, hovering, clicking, resizing, and time. If you only extract the static CSS of each element, your clone will look right in a screenshot but feel dead when someone actually uses it.

For every element, extract its appearance (exact computed CSS via getComputedStyle()) AND its behavior (what changes, what triggers the change, and how the transition happens). Not "it looks like 16px" — extract the actual computed value. Not "the nav changes on scroll" — document the exact trigger (scroll position, IntersectionObserver threshold, viewport intersection), the before and after states (both sets of CSS values), and the transition (duration, easing, CSS transition vs. JS-driven vs. CSS animation-timeline).

Once you know the behavior, map it to an Alpine.js implementation in the spec (see Principle 6). Examples of behaviors to watch for — these are illustrative, not exhaustive. The page may do things not on this list, and you must catch those too:

• A navbar that shrinks, changes background, or gains a shadow after scrolling past a threshold → x-data with a scroll listener in x-init, :class toggling on a scrolled boolean
• Elements that animate into view when they enter the viewport (fade-up, slide-in, stagger delays) → x-intersect or an IntersectionObserver toggling a .reveal.active class
• Sections that snap into place on scroll (scroll-snap-type) → pure CSS in app.css
• Parallax layers that move at different rates than the scroll → Alpine x-init scroll listener updating :style
• Hover states that animate (not just change — the transition duration and easing matter) → Tailwind transition/duration + hover: utilities, or @mouseenter/@mouseleave
• Dropdowns, modals, accordions with enter/exit animations → x-show + long-form x-transition (+ x-collapse for accordions), always with x-cloak
• Scroll-driven progress indicators or opacity transitions → Alpine factory in an inline <script>
• Auto-playing carousels or cycling content → x-data with x-init + setInterval
• Dark-to-light (or any theme) transitions between page sections → section-level classes
• Tabbed/pill content that cycles — buttons that switch visible card sets with transitions → x-data="{ tab: 'a' }" + x-show
• Scroll-driven tab/accordion switching — sidebars where the active item auto-changes as content scrolls past (IntersectionObserver, NOT click handlers)
• Smooth scroll libraries (Lenis, Locomotive Scroll) — check for .lenis class or scroll container wrappers

6. Identify the Interaction Model Before Building

This is the single most expensive mistake in cloning: building a click-based UI when the original is scroll-driven, or vice versa. Before writing any builder prompt for an interactive section, you must definitively answer: Is this section driven by clicks, scrolls, hovers, time, or some combination?

How to determine this:

1. Don't click first. Scroll through the section slowly and observe if things change on their own as you scroll.
2. If they do, it's scroll-driven. Extract the mechanism: IntersectionObserver, scroll-snap, position: sticky, animation-timeline, or JS scroll listeners.
3. If nothing changes on scroll, THEN click/hover to test for click/hover-driven interactivity.
4. Document the interaction model explicitly in the component spec, together with the Alpine mechanism you'll use: "INTERACTION MODEL: scroll-driven with IntersectionObserver → x-intersect" or "INTERACTION MODEL: click-to-switch with opacity transition → x-data/x-show/x-transition."

A section with a sticky sidebar and scrolling content panels is fundamentally different from a tabbed interface where clicking switches content. Getting this wrong means a complete rewrite, not a CSS tweak.

7. Extract Every State, Not Just the Default

Many components have multiple visual states — a tab bar shows different cards per tab, a header looks different at scroll position 0 vs 100, a card has hover effects. You must extract ALL states, not just whatever is visible on page load.

For tabbed/stateful content:

• Click each tab/button via browser MCP
• Extract the content, images, and card data for EACH state
• Record which content belongs to which state
• Note the transition animation between states (opacity, slide, fade, etc.) — these become x-show + x-transition in the Blade output

For scroll-dependent elements:

• Capture computed styles at scroll position 0 (initial state)
• Scroll past the trigger threshold and capture computed styles again (scrolled state)
• Diff the two to identify exactly which CSS properties change
• Record the transition CSS (duration, easing, properties)
• Record the exact trigger threshold (scroll position in px, or viewport intersection ratio)

8. Spec Files Are the Source of Truth

Every component gets a specification file in docs/research/components/ BEFORE any builder is dispatched. This file is the contract between your extraction work and the builder agent. The builder receives the spec file contents inline in its prompt — the file also persists as an auditable artifact that the user (or you) can review if something looks wrong.

The spec file is not optional. It is not a nice-to-have. If you dispatch a builder without first writing a spec file, you are shipping incomplete instructions based on whatever you can remember from a browser MCP session, and the builder will guess to fill gaps.

9. Build Must Always Stay Green

Every builder agent must verify its Blade compiles before finishing: run php artisan view:cache (compiles every template — a syntax error fails loudly) and confirm every asset and component it references actually exists. After merging worktrees, you verify npm run build (Vite) and php artisan view:cache both pass. A broken build is never acceptable, even temporarily. There is no TypeScript step — Blade has no type checker; correctness comes from view:cache compiling clean and the page rendering under php artisan serve.

Phase 1: Reconnaissance

Navigate to the target URL with browser MCP.

Screenshots

• Take full-page screenshots at desktop (1440px) and mobile (390px) viewports
• Save to docs/design-references/ with descriptive names
• These are your master reference — builders will receive section-specific crops/screenshots later

Global Extraction

Extract these from the page before doing anything else:

Fonts — Inspect <link> tags for Google Fonts or self-hosted fonts. Check computed font-family on key elements (headings, body, code, labels). Document every family, weight, and style actually used. Set them up either by self-hosting (drop the files in resources/fonts/ and declare @font-face in resources/css/app.css) or via a <link> to a privacy CDN (e.g. bunny.net) in the layout <head>. Expose each family as a --font-* token inside @theme.

Colors — Extract the site's color palette from computed styles across the page. Add the target's actual colors as --color-* tokens inside the @theme block of resources/css/app.css (e.g. --color-brand-blue: #00A0E4;). They then become Tailwind utilities automatically (bg-brand-blue, text-brand-blue). Add any colors that don't fit a semantic name as-is; arbitrary values (bg-[#0f172a]) are fine in markup for one-offs.

Favicons & Meta — Download favicons, apple-touch-icons, OG images, and the webmanifest to public/ (e.g. public/images/icons/). Wire the <link rel="icon">, <link rel="manifest">, and <meta> / Open Graph / Twitter-card tags into the <head> of the layout component, referencing files with {{ asset('...') }}.

Global UI patterns — Identify any site-wide CSS or JS: custom scrollbar hiding, scroll-snap on the page container, global keyframe animations, backdrop filters, gradients used as overlays, smooth scroll libraries (Lenis, Locomotive Scroll — check for .lenis, .locomotive-scroll, or custom scroll container classes). Add these to resources/css/app.css and note any libraries that need to be installed via npm and imported in resources/js/app.js.

Mandatory Interaction Sweep

This is a dedicated pass AFTER screenshots and BEFORE anything else. Its purpose is to discover every behavior on the page — many of which are invisible in a static screenshot.

Scroll sweep: Scroll the page slowly from top to bottom via browser MCP. At each section, pause and observe:

• Does the header change appearance? Record the scroll position where it triggers.
• Do elements animate into view? Record which ones and the animation type.
• Does a sidebar or tab indicator auto-switch as you scroll? Record the mechanism.
• Are there scroll-snap points? Record which containers.
• Is there a smooth scroll library active? Check for non-native scroll behavior.

Click sweep: Click every element that looks interactive:

• Every button, tab, pill, link, card
• Record what happens: does content change? Does a modal open? Does a dropdown appear?
• For tabs/pills: click EACH ONE and record the content that appears for each state

Hover sweep: Hover over every element that might have hover states:

• Buttons, cards, links, images, nav items
• Record what changes: color, scale, shadow, underline, opacity

Responsive sweep: Test at 3 viewport widths via browser MCP:

• Desktop: 1440px
• Tablet: 768px
• Mobile: 390px
• At each width, note which sections change layout (column → stack, sidebar disappears, etc.) and at approximately which breakpoint the change occurs.

Save all findings to docs/research/BEHAVIORS.md. This is your behavior bible — reference it when writing every component spec, and translate each behavior into its Alpine.js mechanism.

Page Topology

Map out every distinct section of the page from top to bottom. Give each a working name. Document:

• Their visual order
• Which are fixed/sticky overlays vs. flow content
• The overall page layout (scroll container, column structure, z-index layers)
• Dependencies between sections (e.g., a floating nav that overlays everything)
• The interaction model of each section (static, click-driven, scroll-driven, time-driven)

Save this as docs/research/PAGE_TOPOLOGY.md — it becomes your assembly blueprint.

Phase 2: Foundation Build

This is sequential. Do it yourself (not delegated to an agent) since it touches many files:

1. Set up fonts — self-host in resources/fonts/ with @font-face in resources/css/app.css (or add a CDN <link> in the layout <head>), then register each family as a --font-* token in @theme.
2. Build resources/css/app.css — start with @import 'tailwindcss';, add @source '../views';, then a @theme { ... } block holding the target's color and font tokens, followed by @keyframes, custom utility/component classes, and any global scroll behaviors (Lenis, smooth-scroll CSS, scroll-snap on body). Include @layer utilities { [x-cloak] { display: none; } } so x-cloak works.
3. Create the base layout component at resources/views/components/layouts/app.blade.php — a full <!DOCTYPE html> document: <head> with charset/viewport/meta/favicons (via @props with sensible defaults), @vite(['resources/css/app.css', 'resources/js/app.js']), then <body> rendering {{ $slot }}. Configure Alpine in resources/js/app.js: import Alpine from 'alpinejs', import collapse from '@alpinejs/collapse', import intersect from '@alpinejs/intersect', register the plugins, window.Alpine = Alpine, Alpine.start(). (Install these via npm if not already present.)
4. Extract SVG icons — find all inline <svg> elements on the page, deduplicate them, and save each as an anonymous Blade component under resources/views/components/icons/, named by visual function (e.g. resources/views/components/icons/search.blade.php → <x-icons.search>, arrow-right.blade.php → <x-icons.arrow-right>). Keep the raw SVG markup and let callers pass classes via {{ $attributes }}.
5. Download global assets — write and run a Node.js script (scripts/download-assets.mjs) that downloads all images, videos, and other binary assets from the page to public/. Preserve meaningful directory structure (e.g. public/images/, public/videos/).
6. Verify: npm run build passes and php artisan view:cache compiles clean.

Asset Discovery Script Pattern

Use browser MCP to enumerate all assets on the page:

// Run this via browser MCP to discover all assets
JSON.stringify({
  images: [...document.querySelectorAll('img')].map(img => ({
    src: img.src || img.currentSrc,
    alt: img.alt,
    width: img.naturalWidth,
    height: img.naturalHeight,
    // Include parent info to detect layered compositions
    parentClasses: img.parentElement?.className,
    siblings: img.parentElement ? [...img.parentElement.querySelectorAll('img')].length : 0,
    position: getComputedStyle(img).position,
    zIndex: getComputedStyle(img).zIndex
  })),
  videos: [...document.querySelectorAll('video')].map(v => ({
    src: v.src || v.querySelector('source')?.src,
    poster: v.poster,
    autoplay: v.autoplay,
    loop: v.loop,
    muted: v.muted
  })),
  backgroundImages: [...document.querySelectorAll('*')].filter(el => {
    const bg = getComputedStyle(el).backgroundImage;
    return bg && bg !== 'none';
  }).map(el => ({
    url: getComputedStyle(el).backgroundImage,
    element: el.tagName + '.' + el.className?.split(' ')[0]
  })),
  svgCount: document.querySelectorAll('svg').length,
  fonts: [...new Set([...document.querySelectorAll('*')].slice(0, 200).map(el => getComputedStyle(el).fontFamily))],
  favicons: [...document.querySelectorAll('link[rel*="icon"]')].map(l => ({ href: l.href, sizes: l.sizes?.toString() }))
});

Then write a download script that fetches everything to public/. Use batched parallel downloads (4 at a time) with proper error handling.

Phase 3: Component Specification & Dispatch

This is the core loop. For each section in your page topology (top to bottom), you do THREE things: extract, write the spec file, then dispatch builders.

Step 1: Extract

For each section, use browser MCP to extract everything:

1. Screenshot the section in isolation (scroll to it, screenshot the viewport). Save to docs/design-references/.

2. Extract CSS for every element in the section. Use the extraction script below — don't hand-measure individual properties. Run it once per component container and capture the full output:

// Per-component extraction — run via browser MCP
// Replace SELECTOR with the actual CSS selector for the component
(function(selector) {
  const el = document.querySelector(selector);
  if (!el) return JSON.stringify({ error: 'Element not found: ' + selector });
  const props = [
    'fontSize','fontWeight','fontFamily','lineHeight','letterSpacing','color',
    'textTransform','textDecoration','backgroundColor','background',
    'padding','paddingTop','paddingRight','paddingBottom','paddingLeft',
    'margin','marginTop','marginRight','marginBottom','marginLeft',
    'width','height','maxWidth','minWidth','maxHeight','minHeight',
    'display','flexDirection','justifyContent','alignItems','gap',
    'gridTemplateColumns','gridTemplateRows',
    'borderRadius','border','borderTop','borderBottom','borderLeft','borderRight',
    'boxShadow','overflow','overflowX','overflowY',
    'position','top','right','bottom','left','zIndex',
    'opacity','transform','transition','cursor',
    'objectFit','objectPosition','mixBlendMode','filter','backdropFilter',
    'whiteSpace','textOverflow','WebkitLineClamp'
  ];
  function extractStyles(element) {
    const cs = getComputedStyle(element);
    const styles = {};
    props.forEach(p => { const v = cs[p]; if (v && v !== 'none' && v !== 'normal' && v !== 'auto' && v !== '0px' && v !== 'rgba(0, 0, 0, 0)') styles[p] = v; });
    return styles;
  }
  function walk(element, depth) {
    if (depth > 4) return null;
    const children = [...element.children];
    return {
      tag: element.tagName.toLowerCase(),
      classes: element.className?.toString().split(' ').slice(0, 5).join(' '),
      text: element.childNodes.length === 1 && element.childNodes[0].nodeType === 3 ? element.textContent.trim().slice(0, 200) : null,
      styles: extractStyles(element),
      images: element.tagName === 'IMG' ? { src: element.src, alt: element.alt, naturalWidth: element.naturalWidth, naturalHeight: element.naturalHeight } : null,
      childCount: children.length,
      children: children.slice(0, 20).map(c => walk(c, depth + 1)).filter(Boolean)
    };
  }
  return JSON.stringify(walk(el, 0), null, 2);
})('SELECTOR');

3. Extract multi-state styles — for any element with multiple states (scroll-triggered, hover, active tab), capture BOTH states:

// State A: capture styles at current state (e.g., scroll position 0)
// Then trigger the state change (scroll, click, hover via browser MCP)
// State B: re-run the extraction script on the same element
// The diff between A and B IS the behavior specification

Record the diff explicitly: "Property X changes from VALUE_A to VALUE_B, triggered by TRIGGER, with transition: TRANSITION_CSS" — and note the Alpine mechanism that will drive it (a x-data boolean toggled by @click / scroll listener / x-intersect).

4. Extract real content — all text, alt attributes, aria labels, placeholder text. Use element.textContent for each text node. For tabbed/stateful content, click each tab and extract content per state.

5. Identify assets this section uses — which downloaded images/videos from public/, which icon components from resources/views/components/icons/. Check for layered images (multiple <img> or background-images stacked in the same container).

6. Assess complexity — how many distinct sub-components does this section contain? A distinct sub-component is an element with its own unique styling, structure, and behavior (e.g., a card, a nav item, a search panel).

Step 2: Write the Component Spec File

For each section (or sub-component, if you're breaking it up), create a spec file in docs/research/components/. This is NOT optional — every builder must have a corresponding spec file.

File path: docs/research/components/<component-name>.spec.md

Template:

# <component-name> Specification

## Overview
- **Target file:** `resources/views/components/sections/<component-name>.blade.php` (invoked as `<x-sections.component-name>`)
- **Screenshot:** `docs/design-references/<screenshot-name>.png`
- **Interaction model:** <static | click-driven | scroll-driven | time-driven>
- **Alpine mechanism:** <none | x-data toggle + @click | x-intersect reveal | x-data + setInterval | ...>

## DOM Structure
<Describe the element hierarchy — what contains what>

## Computed Styles (exact values from getComputedStyle → Tailwind classes)

### Container
- display: ...
- padding: ...
- maxWidth: ...
- (every relevant property with exact values; note the Tailwind utility or arbitrary value to use)

### <Child element 1>
- fontSize: ...
- color: ...
- (every relevant property)

### <Child element N>
...

## States & Behaviors

### <Behavior name, e.g., "Scroll-triggered floating mode">
- **Trigger:** <exact mechanism — scroll position 50px, IntersectionObserver rootMargin "-30% 0px", click on a tab button, hover>
- **State A (before):** maxWidth: 100vw, boxShadow: none, borderRadius: 0
- **State B (after):** maxWidth: 1200px, boxShadow: 0 4px 20px rgba(0,0,0,0.1), borderRadius: 16px
- **Transition:** transition: all 0.3s ease
- **Alpine implementation:** <e.g. `x-data="{ scrolled: false }" x-init="window.addEventListener('scroll', () => scrolled = window.scrollY > 50)"` with `:class="scrolled ? '...' : '...'"`>

### Hover states
- **<Element>:** <property>: <before> → <after>, transition: <value> (Tailwind `hover:` + `transition duration-...`)

## Per-State Content (if applicable)

### State: "Featured"
- Title: "..."
- Subtitle: "..."
- Cards: [{ title, description, image, link }, ...]

### State: "Productivity"
- Title: "..."
- Cards: [...]

## Assets
- Background image: `public/images/<file>.webp` → `{{ asset('images/<file>.webp') }}`
- Overlay image: `public/images/<file>.png`
- Icons used: `<x-icons.arrow-right>`, `<x-icons.search>`

## Text Content (verbatim)
<All text content, copy-pasted from the live site>

## Responsive Behavior
- **Desktop (1440px):** <layout description; Tailwind `lg:` classes>
- **Tablet (768px):** <what changes — e.g., "maintains 2-column, gap reduces to 16px"; `md:` classes>
- **Mobile (390px):** <what changes — e.g., "stacks to single column, images full-width"; base classes>
- **Breakpoint:** layout switches at ~<N>px

Fill every section. If a section doesn't apply (e.g., no states for a static footer), write "N/A" — but think twice before marking States & Behaviors as N/A. Even a footer might have hover states on links.

Step 3: Dispatch Builders

Based on complexity, dispatch builder agent(s) in worktree(s):

Simple section (1-2 sub-components): One builder agent gets the entire section.

Complex section (3+ distinct sub-components): Break it up. One agent per sub-component, plus one agent for the section wrapper that includes them. Sub-component builders go first since the wrapper depends on them.

What every builder agent receives:

• The full contents of its component spec file (inline in the prompt — don't say "go read the spec file")
• Path to the section screenshot in docs/design-references/
• Which shared Blade components to use (<x-icons.*> from resources/views/components/icons/, any <x-ui.*> primitives, the layout)
• The target file path (e.g., resources/views/components/sections/hero.blade.php)
• The Hard Rules, restated: output the COMPLETE .blade.php file (no snippets, no ellipses); use class="" not className; all interactivity via Alpine.js; @props([...]) for inputs; {{ $slot }} for children; {{ asset('images/...') }} for images; 4-space indent; double-quoted attributes
• Instruction to verify with php artisan view:cache (Blade compiles clean) before finishing
• For responsive behavior: the specific breakpoint values and what changes (Tailwind sm:/md:/lg: prefixes)

Don't wait. As soon as you've dispatched the builder(s) for one section, move to extracting the next section. Builders work in parallel in their worktrees while you continue extraction.

Step 4: Merge

As builder agents complete their work:

• Merge their worktree branches into main
• You have full context on what each agent built, so resolve any conflicts intelligently
• After each merge, verify the build still passes: npm run build and php artisan view:cache
• If a merge introduces a Blade syntax error or a missing-component/asset reference, fix it immediately

The extract → spec → dispatch → merge cycle continues until all sections are built.

Phase 4: Page Assembly

After all sections are built and merged, compose the page and wire up routing:

• Create the page template at resources/views/pages/<name>.blade.php. It opens with <x-layouts.app title="..." :meta-description="...">, drops in the <x-sections.*> components in topology order, and closes with </x-layouts.app>.
• Implement the page-level layout from your topology doc (scroll containers, column structures, sticky positioning, z-index layering) in the layout/page markup.
• Pass real content to components via attributes / @props.
• Implement page-level behaviors with Alpine + CSS: scroll snap (CSS), scroll-driven animations (x-intersect or a shared IntersectionObserver in the layout), dark-to-light section transitions, smooth scroll (Lenis etc. imported in resources/js/app.js).
• Register the route in routes/web.php: Route::view('/', 'pages.<name>')->name('<name>'); (or a controller returning view('pages.<name>') if the page needs data).
• Verify: npm run build and php artisan view:cache pass clean, and the page renders under php artisan serve.

Phase 5: Visual QA Diff

After assembly, do NOT declare the clone complete. Run the clone locally (php artisan serve + npm run dev) and take side-by-side comparison screenshots:

1. Open the original site and your clone side-by-side (or take screenshots at the same viewport widths)
2. Compare section by section, top to bottom, at desktop (1440px)
3. Compare again at mobile (390px)
4. For each discrepancy found:
   • Check the component spec file — was the value extracted correctly?
   • If the spec was wrong: re-extract from browser MCP, update the spec, fix the component
   • If the spec was right but the builder got it wrong: fix the component to match the spec
5. Test all interactive behaviors: scroll through the page, click every button/tab, hover over interactive elements
6. Verify smooth scroll feels right, header transitions work, tab switching works, Alpine transitions play (and x-cloak prevents any flash of uninitialized content)

Only after this visual QA pass is the clone complete.

Pre-Dispatch Checklist

Before dispatching ANY builder agent, verify you can check every box. If you can't, go back and extract more.

• Spec file written to docs/research/components/<name>.spec.md with ALL sections filled
• Every CSS value in the spec is from getComputedStyle(), not estimated
• Interaction model is identified and documented, with its Alpine mechanism (static / click / scroll / time)
• For stateful components: every state's content and styles are captured
• For scroll-driven components: trigger threshold, before/after styles, and transition are recorded
• For hover states: before/after values and transition timing are recorded
• All images in the section are identified (including overlays and layered compositions)
• Responsive behavior is documented for at least desktop and mobile
• Text content is verbatim from the site, not paraphrased
• The builder prompt is under ~150 lines of spec; if over, the section needs to be split
• The builder is told to output a COMPLETE .blade.php file using class="" and Alpine-only interactivity

What NOT to Do

These are lessons from previous failed clones — each one cost hours of rework:

• Don't write React/JSX/className. This project is Blade. Attributes use class="...", files end in .blade.php, and there is no React, no Next.js, no hooks. This is the #1 way to produce output that doesn't belong in this project.
• Don't reach for a JS framework or jQuery for interactivity. Every toggle, dropdown, modal, tab, accordion, and scroll effect is Alpine.js (x-data, x-show, x-transition, x-collapse, x-intersect, @click, :class).
• Don't import shadcn/ui, Radix, MUI, or Lucide. Build UI as Blade components; extract icons as <x-icons.*> Blade components from the target's own SVGs.
• Don't emit snippets or partial files. Every builder outputs the ENTIRE .blade.php (or CSS/JS) file — paste-ready, no ellipses, no "rest unchanged" comments.
• Don't build click-based tabs when the original is scroll-driven (or vice versa). Determine the interaction model FIRST by scrolling before clicking. This requires a complete rewrite, not a CSS fix.
• Don't extract only the default state. If tabs show "Featured" on load, click Productivity, Creative, Lifestyle and extract each one's cards/content. If the header changes on scroll, capture styles at position 0 AND position 100+.
• Don't miss overlay/layered images. A background watercolor + foreground UI mockup = 2 images. Check every container's DOM tree for multiple <img> elements and positioned overlays.
• Don't build mockup components for content that's actually videos/animations. Check if a section uses <video>, Lottie, or canvas before building elaborate HTML mockups of what the video shows.
• Don't approximate CSS values. "It looks like text-lg" is wrong if the computed value is 18px with a 24px line-height. Extract exact values and translate them to precise Tailwind utilities or arbitrary values (text-[18px] leading-6).
• Don't build everything in one monolithic commit. The whole point of this pipeline is incremental progress with verified builds at each step.
• Don't reference docs from builder prompts. Each builder gets the CSS spec inline in its prompt — never "see DESIGN_TOKENS.md for colors." The builder should have zero need to read external docs.
• Don't skip asset extraction. Without real images, videos, and fonts, the clone will always look fake regardless of how perfect the CSS is.
• Don't give a builder agent too much scope. If a builder prompt is getting long because the section is complex, that's a signal to break it into smaller tasks.
• Don't bundle unrelated sections into one agent. A CTA section and a footer are different components — don't hand them both to one agent and hope for the best.
• Don't skip responsive extraction. If you only inspect at desktop width, the clone will break at tablet and mobile. Test at 1440, 768, and 390 during extraction.
• Don't forget smooth scroll libraries. Check for Lenis (.lenis class), Locomotive Scroll, or similar. Install and import them in resources/js/app.js; default browser scrolling feels noticeably different.
• Don't forget x-cloak. Any element toggled by x-show/x-if must carry x-cloak, and app.css must hide [x-cloak], or users see a flash of the open state on load.
• Don't dispatch builders without a spec file. The spec file forces exhaustive extraction and creates an auditable artifact.

Completion

When done, report:

• Total sections built
• Total components created (Blade components in resources/views/components/)
• Total spec files written (should match components)
• Total assets downloaded (images, videos, SVGs, fonts)
• Build status (npm run build + php artisan view:cache results)
• Route(s) registered in routes/web.php
• Visual QA results (any remaining discrepancies)
• Any known gaps or limitations