launchframe 0.2.5 → 0.2.6
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/package.json +1 -1
- package/template/.amazonq/cli-agents/clone-website.json +1 -1
- package/template/.amazonq/rules/project.md +28 -18
- package/template/.augment/commands/clone-website.md +25 -25
- package/template/.claude/skills/clone-website/SKILL.md +25 -25
- package/template/.claude/skills/marketing-social-proof-motion/SKILL.md +47 -0
- package/template/.clinerules +33 -19
- package/template/.codex/skills/clone-website/SKILL.md +25 -25
- package/template/.continue/commands/clone-website.md +25 -25
- package/template/.continue/rules/project.md +28 -18
- package/template/.cursor/commands/clone-website.md +25 -25
- package/template/.cursor/commands/marketing-social-proof-motion.md +42 -0
- package/template/.cursor/rules/project.mdc +1 -4
- package/template/.gemini/commands/clone-website.toml +25 -25
- package/template/.github/copilot-instructions.md +28 -18
- package/template/.github/skills/clone-website/SKILL.md +25 -25
- package/template/.opencode/commands/clone-website.md +25 -25
- package/template/.windsurf/workflows/clone-website.md +25 -25
- package/template/AGENTS.md +24 -12
- package/template/docs/research/INSPECTION_GUIDE.md +11 -8
- package/template/package-lock.json +8795 -0
- package/template/scripts/recon-playwright.mjs +90 -17
- package/template/src/components/marketing/scribewise-landing.tsx +34 -0
- package/template/.claude/skills/marketing-landing-production/SKILL.md +0 -36
- package/template/.cursor/commands/marketing-landing-production.md +0 -31
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "launchframe",
|
|
3
|
-
"version": "0.2.
|
|
3
|
+
"version": "0.2.6",
|
|
4
4
|
"description": "Scaffold a SaaS-ready Next.js codebase from any URL. Point launchframe at a website you admire and describe the SaaS you want to build — it drops in the AI-cloner template wired with your URL and idea so your AI agent (Claude Code, Cursor, Codex, etc.) can run /clone-website and produce a pixel-perfect, re-skinned starting point.",
|
|
5
5
|
"license": "MIT",
|
|
6
6
|
"author": "Evan Gruhlkey",
|
|
@@ -1,7 +1,7 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "clone-website",
|
|
3
3
|
"description": "Reverse-engineer and clone any website as a pixel-perfect replica",
|
|
4
|
-
"prompt": "\n# Clone Website\n\nYou are about to reverse-engineer and rebuild a website as a pixel-perfect clone, then re-skin the copy/branding for the user's SaaS idea.\n\n**Launchframe shorthand:** If the user only says **Build it**, **Go**, **Ship it**, **Clone the site**, or **Run launchframe** with no URL in the message, treat that as an invocation of this skill with empty `the target URL provided by the user` — **`launchframe.config.json` alone** supplies `url` and `idea`. Proceed without asking them to repeat those values unless the file is missing or invalid.\n\n## Step 0: Read `launchframe.config.json`\n\n**Before doing anything else**, read `launchframe.config.json` at the project root. This file was written by the `launchframe` CLI when the project was scaffolded and is the authoritative source of:\n\n- `url` — the visual source-of-truth you are cloning\n- `idea` — the user's SaaS idea, which becomes the rebranding directive applied after the pixel-perfect clone\n\nIf `the target URL provided by the user` is non-empty, treat the arguments as additional URLs (or an override) and merge them with the config — explicit CLI args win on conflict. If `launchframe.config.json` is missing, fall back to `the target URL provided by the user` and ask the user for an idea if one wasn't provided.\n\nWhen 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>/`).\n\nThis 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.\n\n## Scope Defaults\n\nThe target is the `url` from `launchframe.config.json` (or any URL provided in `the target URL provided by the user`). Clone exactly what's visible at that URL, then apply the SaaS-idea rebrand. Unless the user specifies otherwise, use these defaults:\n\n- **Fidelity level (visuals):** Pixel-perfect — exact match in colors, spacing, typography, animations, responsive behavior\n- **Copy & branding:** Replaced to match the `idea` from `launchframe.config.json` (product name, headlines, feature copy, CTA labels, testimonials). Visuals stay 1:1; words and brand marks get re-skinned.\n- **In scope:** Visual layout and styling, component structure and interactions, responsive design, mock data shaped for the SaaS idea\n- **Out of scope:** Real backend / database, authentication, real-time features, SEO optimization, accessibility audit\n- **Customization beyond the rebrand:** None during the initial pass — match 1:1 visually, swap copy/brand only\n\nIf the user provides additional instructions (specific fidelity level, deeper customizations, extra context), honor those over the defaults.\n\n## Pre-Flight\n\n1. **Read `launchframe.config.json`** (see Step 0 above). After a fresh `npx launchframe` scaffold, proceed immediately — only echo `url`/`idea` for confirmation if the config looks wrong or the user asked to verify.\n2. **Browser automation.** Prefer an MCP (Chrome DevTools MCP, Playwright MCP, Browserbase MCP, etc.) when it is healthy. **If MCP is missing or in an error state, run `npm run recon` (Playwright)** — see `scripts/recon-playwright.mjs`. It writes `docs/research/computed-snapshot.json`, `docs/research/MEDIA_MANIFEST.md`, and full-page screenshots under `docs/design-references/`. Use `npm run recon:headed` if headless hits a WAF/challenge page. One-time install: `npx playwright install chromium`. Do not skip extraction — adapt the pipeline to the tools that work.\n3. Validate the resolved URL(s). Normalize and verify each is accessible via your browser MCP tool. If any are invalid, ask the user to correct `launchframe.config.json` (or pass an override) before proceeding.\n4. Verify the base project builds: `npm run build`. The Next.js + shadcn/ui + Tailwind v4 scaffold should already be in place. If not, tell the user to run `npm install` first.\n5. Create the output directories if they don't exist: `docs/research/`, `docs/research/components/`, `docs/design-references/`, `scripts/`. Plan `docs/research/MEDIA_MANIFEST.md` as soon as media is inventoried. For multiple clones, also prepare per-site folders like `docs/research/<hostname>/` and `docs/design-references/<hostname>/`.\n6. 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.\n\n## Guiding Principles\n\nThese are the truths that separate a successful clone from a \"close enough\" mess. Internalize them — they should inform every decision you make.\n\n### 0. Launchframe priorities: media & motion (do not defer)\n\n**Raster & video are first-class.** Before you treat the page as “mostly typography,” run a dedicated **media inventory** (see `@docs/research/INSPECTION_GUIDE.md` Priority section): every `<img>`, `<picture>` / `<source>`, `<video>` (+ poster), and non-trivial `background-image`. Download to `public/images/` and `public/videos/` and write `docs/research/MEDIA_MANIFEST.md` (URL → local path, or `BLOCKED` + reason). Component specs MUST list concrete `public/...` paths; if you use a placeholder, say why in `docs/research/EXTRACTION_LIMITATIONS.md`. Never silently drop a hero layer, reel, or og visual.\n\n**Motion defaults to Framer Motion.** This template lists `framer-motion` as a dependency. After foundation tokens, ensure `import { motion } from \"framer-motion\"` (and related APIs: `useScroll`, `useTransform`, `AnimatePresence`, `LayoutGroup`, **`useReducedMotion`**) for: scroll-triggered reveals, staggered children, layout transitions, and gestures — anything beyond a trivial one-property CSS `transition`. In each spec file, add a **Motion** subsection: trigger, duration, easing, delay/stagger, **tier A–E coverage** (see `AGENTS.md` production polish table), reduced-motion fallback, and **implementation: CSS | framer-motion**. Prefer CSS only when it matches the target exactly without JS.\n\n**Illustration & pixel art are production inputs.** Where the target (or post-rebrand layout) lacks convincing visuals, specs MUST still allocate **SVG illustration layers** — hero backdrop cluster, section separators, feature-card scenes tied to copy — using React SVG components (`currentColor` + theme vars). Pixel-art motifs require an explicit palette table in the spec. Do not ship ambiguous gray placeholders when `AGENTS.md` calls for production density on authored landings.\n\n### 1. Completeness Beats Speed\n\nEvery 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.\n\n### 2. Small Tasks, Perfect Results\n\nWhen 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.\n\nLook 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.\n\n**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.\"\n\n### 3. Real Content, Real Assets\n\nExtract 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>`, extract inline `<svg>` elements as React components. The only time you generate content is when something is clearly server-generated and unique per session.\n\n**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.\n\n### 4. Foundation First\n\nNothing can be built until the foundation exists: global CSS with the target site's design tokens (colors, fonts, spacing), TypeScript types for the content structures, and global assets (fonts, favicons). This is sequential and non-negotiable. Everything after this can be parallel.\n\n### 5. Extract How It Looks AND How It Behaves\n\nA 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.\n\nFor 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`).\n\nExamples 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:\n- A navbar that shrinks, changes background, or gains a shadow after scrolling past a threshold\n- Elements that animate into view when they enter the viewport (fade-up, slide-in, stagger delays)\n- Sections that snap into place on scroll (`scroll-snap-type`)\n- Parallax layers that move at different rates than the scroll\n- Hover states that animate (not just change — the transition duration and easing matter)\n- Dropdowns, modals, accordions with enter/exit animations\n- Scroll-driven progress indicators or opacity transitions\n- Auto-playing carousels or cycling content\n- Dark-to-light (or any theme) transitions between page sections\n- **Tabbed/pill content that cycles** — buttons that switch visible card sets with transitions\n- **Scroll-driven tab/accordion switching** — sidebars where the active item auto-changes as content scrolls past (IntersectionObserver, NOT click handlers)\n- **Smooth scroll libraries** (Lenis, Locomotive Scroll) — check for `.lenis` class or scroll container wrappers\n\n### 6. Identify the Interaction Model Before Building\n\nThis 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?**\n\nHow to determine this:\n1. **Don't click first.** Scroll through the section slowly and observe if things change on their own as you scroll.\n2. If they do, it's scroll-driven. Extract the mechanism: `IntersectionObserver`, `scroll-snap`, `position: sticky`, `animation-timeline`, or JS scroll listeners.\n3. If nothing changes on scroll, THEN click/hover to test for click/hover-driven interactivity.\n4. Document the interaction model explicitly in the component spec: \"INTERACTION MODEL: scroll-driven with IntersectionObserver\" or \"INTERACTION MODEL: click-to-switch with opacity transition.\"\n\nA 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.\n\n### 7. Extract Every State, Not Just the Default\n\nMany 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.\n\nFor tabbed/stateful content:\n- Click each tab/button via browser MCP\n- Extract the content, images, and card data for EACH state\n- Record which content belongs to which state\n- Note the transition animation between states (opacity, slide, fade, etc.)\n\nFor scroll-dependent elements:\n- Capture computed styles at scroll position 0 (initial state)\n- Scroll past the trigger threshold and capture computed styles again (scrolled state)\n- Diff the two to identify exactly which CSS properties change\n- Record the transition CSS (duration, easing, properties)\n- Record the exact trigger threshold (scroll position in px, or viewport intersection ratio)\n\n### 8. Spec Files Are the Source of Truth\n\nEvery 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.\n\nThe 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.\n\n### 9. Build Must Always Compile\n\nEvery builder agent must verify `npx tsc --noEmit` passes before finishing. After merging worktrees, you verify `npm run build` passes. A broken build is never acceptable, even temporarily.\n\n## Phase 1: Reconnaissance\n\nNavigate to the target URL with browser MCP.\n\n### Screenshots\n- Take **full-page screenshots** at desktop (1440px) and mobile (390px) viewports\n- Save to `docs/design-references/` with descriptive names\n- These are your master reference — builders will receive section-specific crops/screenshots later\n\n### Global Extraction\nExtract these from the page before doing anything else:\n\n**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. Configure them in `src/app/layout.tsx` using `next/font/google` or `next/font/local`.\n\n**Colors** — Extract the site's color palette from computed styles across the page. Update `src/app/globals.css` with the target's actual colors in the `:root` and `.dark` CSS variable blocks. Map them to shadcn's token names (background, foreground, primary, muted, etc.) where they fit. Add custom properties for colors that don't map to shadcn tokens.\n\n**Favicons & Meta** — Download favicons, apple-touch-icons, OG images, webmanifest to `public/seo/`. Update `layout.tsx` metadata.\n\n**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 `globals.css` and note any libraries that need to be installed.\n\n### Mandatory Interaction Sweep\n\nThis 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.\n\n**Scroll sweep:** Scroll the page slowly from top to bottom via browser MCP. At each section, pause and observe:\n- Does the header change appearance? Record the scroll position where it triggers.\n- Do elements animate into view? Record which ones and the animation type.\n- Does a sidebar or tab indicator auto-switch as you scroll? Record the mechanism.\n- Are there scroll-snap points? Record which containers.\n- Is there a smooth scroll library active? Check for non-native scroll behavior.\n\n**Click sweep:** Click every element that looks interactive:\n- Every button, tab, pill, link, card\n- Record what happens: does content change? Does a modal open? Does a dropdown appear?\n- For tabs/pills: click EACH ONE and record the content that appears for each state\n\n**Hover sweep:** Hover over every element that might have hover states:\n- Buttons, cards, links, images, nav items\n- Record what changes: color, scale, shadow, underline, opacity\n\n**Responsive sweep:** Test at 3 viewport widths via browser MCP:\n- Desktop: 1440px\n- Tablet: 768px\n- Mobile: 390px\n- At each width, note which sections change layout (column → stack, sidebar disappears, etc.) and at approximately which breakpoint the change occurs.\n\nSave all findings to `docs/research/BEHAVIORS.md`. This is your behavior bible — reference it when writing every component spec.\n\n### Page Topology\nMap out every distinct section of the page from top to bottom. Give each a working name. Document:\n- Their visual order\n- Which are fixed/sticky overlays vs. flow content\n- The overall page layout (scroll container, column structure, z-index layers)\n- Dependencies between sections (e.g., a floating nav that overlays everything)\n- **The interaction model** of each section (static, click-driven, scroll-driven, time-driven)\n\nSave this as `docs/research/PAGE_TOPOLOGY.md` — it becomes your assembly blueprint.\n\n## Phase 2: Foundation Build\n\nThis is sequential. Do it yourself (not delegated to an agent) since it touches many files:\n\n1. **Update fonts** in `layout.tsx` to match the target site's actual fonts\n2. **Confirm Framer Motion** — `framer-motion` should already be in `package.json`. If missing, add it (`npm install framer-motion`) so builders can import `motion` without ad-hoc library drift.\n3. **Update globals.css** with the target's color tokens, spacing values, keyframe animations, utility classes, and any **global scroll behaviors** (Lenis, smooth scroll CSS, scroll-snap on body)\n4. **Media inventory + download (early, high priority)** — run the asset discovery script (below) via browser MCP, write `docs/research/MEDIA_MANIFEST.md`, then implement **`scripts/download-assets.mjs`** and execute it so **images** land in `public/images/` and **videos** (+ posters) in `public/videos/` (or a clear subdirectory scheme under `public/`). Batch parallel downloads (4 concurrent) with errors logged — do not claim success if URLs failed. This step should complete **before** most section components are built so builders use real paths.\n5. **Create TypeScript interfaces** in `src/types/` for the content structures you've observed\n6. **Extract SVG icons** — find all inline `<svg>` elements on the page, deduplicate them, and save as named React components in `src/components/icons.tsx`. Name them by visual function (e.g., `SearchIcon`, `ArrowRightIcon`, `LogoIcon`).\n7. Verify: `npm run build` passes\n\n### Asset Discovery Script Pattern\n\nUse browser MCP to enumerate all assets on the page:\n\n```javascript\n// Run this via browser MCP to discover all assets\nJSON.stringify({\n images: [...document.querySelectorAll('img')].map(img => ({\n src: img.src || img.currentSrc,\n alt: img.alt,\n width: img.naturalWidth,\n height: img.naturalHeight,\n // Include parent info to detect layered compositions\n parentClasses: img.parentElement?.className,\n siblings: img.parentElement ? [...img.parentElement.querySelectorAll('img')].length : 0,\n position: getComputedStyle(img).position,\n zIndex: getComputedStyle(img).zIndex\n })),\n videos: [...document.querySelectorAll('video')].map(v => ({\n src: v.src || v.querySelector('source')?.src,\n poster: v.poster,\n autoplay: v.autoplay,\n loop: v.loop,\n muted: v.muted\n })),\n backgroundImages: [...document.querySelectorAll('*')].filter(el => {\n const bg = getComputedStyle(el).backgroundImage;\n return bg && bg !== 'none';\n }).map(el => ({\n url: getComputedStyle(el).backgroundImage,\n element: el.tagName + '.' + el.className?.split(' ')[0]\n })),\n svgCount: document.querySelectorAll('svg').length,\n fonts: [...new Set([...document.querySelectorAll('*')].slice(0, 200).map(el => getComputedStyle(el).fontFamily))],\n favicons: [...document.querySelectorAll('link[rel*=\"icon\"]')].map(l => ({ href: l.href, sizes: l.sizes?.toString() }))\n});\n```\n\nThen write a download script that fetches everything to `public/`. Use batched parallel downloads (4 at a time) with proper error handling.\n\n## Phase 3: Component Specification & Dispatch\n\nThis 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**.\n\n### Step 1: Extract\n\nFor each section, use browser MCP to extract everything:\n\n1. **Screenshot** the section in isolation (scroll to it, screenshot the viewport). Save to `docs/design-references/`.\n\n2. **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:\n\n```javascript\n// Per-component extraction — run via browser MCP\n// Replace SELECTOR with the actual CSS selector for the component\n(function(selector) {\n const el = document.querySelector(selector);\n if (!el) return JSON.stringify({ error: 'Element not found: ' + selector });\n const props = [\n 'fontSize','fontWeight','fontFamily','lineHeight','letterSpacing','color',\n 'textTransform','textDecoration','backgroundColor','background',\n 'padding','paddingTop','paddingRight','paddingBottom','paddingLeft',\n 'margin','marginTop','marginRight','marginBottom','marginLeft',\n 'width','height','maxWidth','minWidth','maxHeight','minHeight',\n 'display','flexDirection','justifyContent','alignItems','gap',\n 'gridTemplateColumns','gridTemplateRows',\n 'borderRadius','border','borderTop','borderBottom','borderLeft','borderRight',\n 'boxShadow','overflow','overflowX','overflowY',\n 'position','top','right','bottom','left','zIndex',\n 'opacity','transform','transition','cursor',\n 'objectFit','objectPosition','mixBlendMode','filter','backdropFilter',\n 'whiteSpace','textOverflow','WebkitLineClamp'\n ];\n function extractStyles(element) {\n const cs = getComputedStyle(element);\n const styles = {};\n 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; });\n return styles;\n }\n function walk(element, depth) {\n if (depth > 4) return null;\n const children = [...element.children];\n return {\n tag: element.tagName.toLowerCase(),\n classes: element.className?.toString().split(' ').slice(0, 5).join(' '),\n text: element.childNodes.length === 1 && element.childNodes[0].nodeType === 3 ? element.textContent.trim().slice(0, 200) : null,\n styles: extractStyles(element),\n images: element.tagName === 'IMG' ? { src: element.src, alt: element.alt, naturalWidth: element.naturalWidth, naturalHeight: element.naturalHeight } : null,\n childCount: children.length,\n children: children.slice(0, 20).map(c => walk(c, depth + 1)).filter(Boolean)\n };\n }\n return JSON.stringify(walk(el, 0), null, 2);\n})('SELECTOR');\n```\n\n3. **Extract multi-state styles** — for any element with multiple states (scroll-triggered, hover, active tab), capture BOTH states:\n\n```javascript\n// State A: capture styles at current state (e.g., scroll position 0)\n// Then trigger the state change (scroll, click, hover via browser MCP)\n// State B: re-run the extraction script on the same element\n// The diff between A and B IS the behavior specification\n```\n\nRecord the diff explicitly: \"Property X changes from VALUE_A to VALUE_B, triggered by TRIGGER, with transition: TRANSITION_CSS.\"\n\n4. **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**.\n\n5. **Identify assets** this section uses — which downloaded images/videos from `public/`, which icon components from `icons.tsx`. Check for **layered images** (multiple `<img>` or background-images stacked in the same container).\n\n6. **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).\n\n### Step 2: Write the Component Spec File\n\nFor 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.\n\n**File path:** `docs/research/components/<component-name>.spec.md`\n\n**Template:**\n\n```markdown\n# <ComponentName> Specification\n\n## Overview\n- **Target file:** `src/components/<ComponentName>.tsx`\n- **Screenshot:** `docs/design-references/<screenshot-name>.png`\n- **Interaction model:** <static | click-driven | scroll-driven | time-driven>\n\n## DOM Structure\n<Describe the element hierarchy — what contains what>\n\n## Computed Styles (exact values from getComputedStyle)\n\n### Container\n- display: ...\n- padding: ...\n- maxWidth: ...\n- (every relevant property with exact values)\n\n### <Child element 1>\n- fontSize: ...\n- color: ...\n- (every relevant property)\n\n### <Child element N>\n...\n\n## States & Behaviors\n\n### <Behavior name, e.g., \"Scroll-triggered floating mode\">\n- **Trigger:** <exact mechanism — scroll position 50px, IntersectionObserver rootMargin \"-30% 0px\", click on .tab-button, hover>\n- **State A (before):** maxWidth: 100vw, boxShadow: none, borderRadius: 0\n- **State B (after):** maxWidth: 1200px, boxShadow: 0 4px 20px rgba(0,0,0,0.1), borderRadius: 16px\n- **Transition:** transition: all 0.3s ease\n- **Implementation approach:** <CSS transition + scroll listener | IntersectionObserver | CSS animation-timeline | **framer-motion** (`motion`, `whileInView`, stagger container) | etc.>\n\n### Hover states\n- **<Element>:** <property>: <before> → <after>, transition: <value>\n\n## Motion (Framer Motion vs CSS)\n- **Tiers A–E:** <which tiers apply — load stagger, scroll reveal, ambient loop, interaction lifts, decorative parallax — list triggers>\n- **Reduced motion:** <what disables or simplifies when user prefers reduced motion>\n- **Entrance / scroll reveals:** <e.g. fade+translateY, staggerChildren — specify duration, easing, delay, viewport `once`/`margin`>\n- **Library:** <`framer-motion` | CSS-only — justify if CSS-only>\n- **Keyframes / springs:** <if any — match target curve>\n\n## Illustration & pixel art *(production uplift)*\n- **SVG components:** <named exports, paths using currentColor vs fixed fills>\n- **Pixel motif:** <palette hex table, grid, scaling — or N/A>\n- **Motif thread:** <how illustration echoes logo / OG / favicon>\n\n## Per-State Content (if applicable)\n\n### State: \"Featured\"\n- Title: \"...\"\n- Subtitle: \"...\"\n- Cards: [{ title, description, image, link }, ...]\n\n### State: \"Productivity\"\n- Title: \"...\"\n- Cards: [...]\n\n## Assets (images & video — required detail)\n- Raster: `public/images/<file>` — dimensions, `object-fit`, lazy if below fold\n- Video: `public/videos/<file>` — poster `public/images/...` or `public/videos/...`, autoplay/muted/loop, controls\n- Background layers: which div uses `background-image` and resolved URL → local path\n- Icons used: <ArrowIcon>, <SearchIcon> from icons.tsx\n\n## Text Content (verbatim)\n<All text content, copy-pasted from the live site>\n\n## Responsive Behavior\n- **Desktop (1440px):** <layout description>\n- **Tablet (768px):** <what changes — e.g., \"maintains 2-column, gap reduces to 16px\">\n- **Mobile (390px):** <what changes — e.g., \"stacks to single column, images full-width\">\n- **Breakpoint:** layout switches at ~<N>px\n```\n\nFill 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.\n\n### Step 3: Dispatch Builders\n\nBased on complexity, dispatch builder agent(s) in worktree(s):\n\n**Simple section** (1-2 sub-components): One builder agent gets the entire section.\n\n**Complex section** (3+ distinct sub-components): Break it up. One agent per sub-component, plus one agent for the section wrapper that imports them. Sub-component builders go first since the wrapper depends on them.\n\n**What every builder agent receives:**\n- The full contents of its component spec file (inline in the prompt — don't say \"go read the spec file\")\n- Path to the section screenshot in `docs/design-references/`\n- Which shared components to import (`icons.tsx`, `cn()`, shadcn primitives)\n- The target file path (e.g., `src/components/HeroSection.tsx`)\n- Instruction to verify with `npx tsc --noEmit` before finishing\n- For responsive behavior: the specific breakpoint values and what changes\n\n**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.\n\n### Step 4: Merge\n\nAs builder agents complete their work:\n- Merge their worktree branches into main\n- You have full context on what each agent built, so resolve any conflicts intelligently\n- After each merge, verify the build still passes: `npm run build`\n- If a merge introduces type errors, fix them immediately\n\nThe extract → spec → dispatch → merge cycle continues until all sections are built.\n\n## Phase 4: Page Assembly\n\nAfter all sections are built and merged, wire everything together in `src/app/page.tsx`:\n\n- Import all section components\n- Implement the page-level layout from your topology doc (scroll containers, column structures, sticky positioning, z-index layering)\n- Connect real content to component props\n- Implement page-level behaviors: scroll snap, scroll-driven animations, dark-to-light transitions, intersection observers, smooth scroll (Lenis etc.)\n- Verify: `npm run build` passes clean\n\n## Phase 4.5: SaaS Rebrand Pass\n\nThe pixel-perfect clone is done — now re-skin it for the SaaS idea from `launchframe.config.json`.\n\n**Guiding rule:** swap words and brand marks, leave structure untouched. The original site's visual hierarchy was already validated by a real product team. Your job is to put the user's product into that proven shell, not to redesign it.\n\nFor every section, replace:\n\n1. **Product name & logo** — wherever the original brand appears, use the SaaS idea's name (derive a short product name from the `idea` string if one isn't supplied — keep it 1–2 words, easy to lockup). Replace the wordmark text in place. For the logo glyph, either reuse the original SVG silhouette with a fresh fill, or use a Lucide icon that matches the SaaS category (e.g., `Brain` for AI, `Workflow` for automation, `Sparkles` for generative tooling). Do NOT keep the original brand's actual logo file.\n2. **Hero headline & sub-headline** — write fresh copy that pitches the SaaS idea, using the original line lengths and tone as constraints. If the original is 6 words, write 6 words. If it's 14, write 14. Match emphasis, line breaks, and any inline highlighted phrase.\n3. **Feature/section copy** — rewrite each feature card, callout, stat, and testimonial to fit the SaaS idea. Preserve the count and shape of items (3 feature cards stay 3 feature cards; a 4-column logo bar stays 4 columns). Generate plausible customer-logo names — never use real company names you haven't been authorized to use.\n4. **CTA labels** — adapt button text to the SaaS idea (\"Start free\", \"Get a demo\", \"Try it free\", etc.). Keep the CTA hierarchy (primary/secondary) identical to the original.\n5. **Mock data** — for product UI mockups embedded in marketing screenshots (e.g., a fake dashboard inside a hero), generate mock data shaped for the SaaS idea: realistic-looking but fictional rows, charts, conversation logs, etc.\n6. **Imagery** — placeholder-swap any photography or product screenshots that depict the original brand. Prefer using:\n - A neutral abstract gradient / shape composition you generate with CSS or SVG\n - A Lucide icon arrangement\n - Placeholder service URLs only if explicitly allowed by the user\n Keep dimensions, aspect ratios, drop shadows, and surrounding spacing identical to the original.\n7. **Metadata** — update `<title>`, meta description, OG tags, and favicon manifest in `src/app/layout.tsx` to reflect the new SaaS. Generate a simple favicon (initial letter on a brand-colored square) if no asset is provided.\n\nWhat you must NOT change in this pass:\n- Spacing, padding, typography scale, color tokens, **animation timing & motion choreography** (including Framer Motion `variants` / `transition` props), responsive breakpoints — those are still 1:1 to the original\n- Section order, section count, component structure\n- Interaction models (scroll-driven stays scroll-driven, etc.)\n- Any computed-style value extracted in Phase 3\n\nAfter the rebrand pass, the codebase should look like the original site visually but read like the user's SaaS at a glance. Save a short `docs/research/REBRAND.md` summarizing the product name you chose, the headline rewrites, and any assets you swapped — so the user can audit what's clone-derived vs. authored.\n\n## Phase 4.6: Production uplift *(sparse references / user asks for prod polish)*\n\nRun this pass when **any** of the following is true:\n\n- The cloned reference is mostly typography with weak imagery (internal demos, minimalist SaaS shells).\n- The user asks for **more motion**, **SVG / illustration**, **pixel art**, **brandability**, or **production-ready** marketing polish.\n- Visual QA feels “correct but dead” — layout matches but nothing moves and cards use unrelated placeholders.\n\n**Do not contradict pixel-perfect emulation when cloning a rich reference** — this phase *adds* density only where the brief allows uplift or the reference was inherently flat.\n\nChecklist (mirror `AGENTS.md`):\n\n1. **Imagery** — Add layered hero treatment + purposeful SVG scenes per feature (swap nonsense placeholders). Prefer named components under `src/components/marketing/art/`.\n2. **Motion tiers** — Implement at minimum **A + B + one of C/D**, optionally **E**: staggered hero load, `whileInView` sections + card stagger, looping ambient (marquee / caret / SVG dash loop), hover lifts / nav scroll shrink, optional light parallax. Gate loops with **`useReducedMotion()`**.\n3. **Brand** — Establish motif thread + accent tokens in `:root`; refresh favicon / OG sketch to match.\n\nDocument deltas in `docs/research/PRODUCTION_UPLIFT.md` (what SVGs/motion/accent decisions shipped).\n\nInvoke `.claude/skills/marketing-landing-production/SKILL.md` as a focused playbook for this pass.\n\n## Phase 5: Visual QA Diff\n\nAfter assembly, do NOT declare the clone complete. Take side-by-side comparison screenshots:\n\n1. Open the original site and your clone side-by-side (or take screenshots at the same viewport widths)\n2. Compare section by section, top to bottom, at desktop (1440px)\n3. Compare again at mobile (390px)\n4. For each discrepancy found:\n - Check the component spec file — was the value extracted correctly?\n - If the spec was wrong: re-extract from browser MCP, update the spec, fix the component\n - If the spec was right but the builder got it wrong: fix the component to match the spec\n5. Test all interactive behaviors: scroll through the page, click every button/tab, hover over interactive elements\n6. Verify smooth scroll feels right, header transitions work, tab switching works, animations play\n\nOnly after this visual QA pass is the clone complete.\n\n## Pre-Dispatch Checklist\n\nBefore dispatching ANY builder agent, verify you can check every box. If you can't, go back and extract more.\n\n- [ ] Spec file written to `docs/research/components/<name>.spec.md` with ALL sections filled\n- [ ] Every CSS value in the spec is from `getComputedStyle()`, not estimated\n- [ ] Interaction model is identified and documented (static / click / scroll / time)\n- [ ] For stateful components: every state's content and styles are captured\n- [ ] For scroll-driven components: trigger threshold, before/after styles, and transition are recorded\n- [ ] For hover states: before/after values and transition timing are recorded\n- [ ] All images in the section are identified (including overlays and layered compositions)\n- [ ] Any `<video>` (and poster), Lottie, or canvas-driven hero is identified — not approximated as a static div\n- [ ] **Motion** subsection filled: tiers **A–E** coverage (see `AGENTS.md`), CSS vs **framer-motion**, durations, easings, stagger, scroll triggers, **reduced-motion** fallback\n- [ ] **Illustration** subsection filled when uplift applies: SVG components / palette / motif thread — or explicit **N/A** with justification only on strict clone parity jobs\n- [ ] Responsive behavior is documented for at least desktop and mobile\n- [ ] Text content is verbatim from the site, not paraphrased\n- [ ] The builder prompt is under ~150 lines of spec; if over, the section needs to be split\n\n## What NOT to Do\n\nThese are lessons from previous failed clones — each one cost hours of rework:\n\n- **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 is the #1 most expensive mistake — it requires a complete rewrite, not a CSS fix.\n- **Don't extract only the default state.** If there are tabs showing \"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+.\n- **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.\n- **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.\n- **Don't approximate CSS classes.** \"It looks like `text-lg`\" is wrong if the computed value is `18px` and `text-lg` is `18px/28px` but the actual line-height is `24px`. Extract exact values.\n- **Don't build everything in one monolithic commit.** The whole point of this pipeline is incremental progress with verified builds at each step.\n- **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.\n- **Don't skip asset extraction.** Without real images, videos, and fonts, the clone will always look fake regardless of how perfect the CSS is.\n- **Don't defer image/video download to the end.** Run `MEDIA_MANIFEST.md` + `download-assets.mjs` during foundation so components reference real `public/` paths from the first build.\n- **Don't fake complex motion with a single CSS `transition` when the target uses staggered, scroll-scrubbed, or layout-driven animation** — use **`framer-motion`** (`motion`, `whileInView`, `variants`, `staggerChildren`) and match duration/easing from extraction.\n- **Don't give a builder agent too much scope.** If you're writing a builder prompt and it's getting long because the section is complex, that's a signal to break it into smaller tasks.\n- **Don't bundle unrelated sections into one agent.** A CTA section and a footer are different components with different designs — don't hand them both to one agent and hope for the best.\n- **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.\n- **Don't forget smooth scroll libraries.** Check for Lenis (`.lenis` class), Locomotive Scroll, or similar. Default browser scrolling feels noticeably different and the user will spot it immediately.\n- **Don't dispatch builders without a spec file.** The spec file forces exhaustive extraction and creates an auditable artifact. Skipping it means the builder gets whatever you can fit in a prompt from memory.\n\n## Completion\n\nWhen done, report:\n- Source URL cloned (from `launchframe.config.json` or `the target URL provided by the user`)\n- SaaS idea applied (from `launchframe.config.json`) and the product name you chose\n- Total sections built\n- Total components created\n- Total spec files written (should match components)\n- Total assets downloaded (images, videos, SVGs, fonts) — path to `docs/research/MEDIA_MANIFEST.md`\n- Rebrand summary (path to `docs/research/REBRAND.md`)\n- Build status (`npm run build` result)\n- Visual QA results (any remaining discrepancies)\n- Any known gaps or limitations\n",
|
|
4
|
+
"prompt": "\n# Clone Website\n\nYou are about to reverse-engineer and rebuild a website as a pixel-perfect clone, then re-skin the copy/branding for the user's SaaS idea.\n\n**Launchframe shorthand:** If the user only says **Build it**, **Go**, **Ship it**, **Clone the site**, or **Run launchframe** with no URL in the message, treat that as an invocation of this skill with empty `the target URL provided by the user` — **`launchframe.config.json` alone** supplies `url` and `idea`. Proceed without asking them to repeat those values unless the file is missing or invalid.\n\n## Step 0: Read `launchframe.config.json`\n\n**Before doing anything else**, read `launchframe.config.json` at the project root. This file was written by the `launchframe` CLI when the project was scaffolded and is the authoritative source of:\n\n- `url` — the visual source-of-truth you are cloning\n- `idea` — the user's SaaS idea, which becomes the rebranding directive applied after the pixel-perfect clone\n\nIf `the target URL provided by the user` is non-empty, treat the arguments as additional URLs (or an override) and merge them with the config — explicit CLI args win on conflict. If `launchframe.config.json` is missing, fall back to `the target URL provided by the user` and ask the user for an idea if one wasn't provided.\n\nWhen 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>/`).\n\nThis 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.\n\n## Scope Defaults\n\nThe target is the `url` from `launchframe.config.json` (or any URL provided in `the target URL provided by the user`). Clone exactly what's visible at that URL, then apply the SaaS-idea rebrand. Unless the user specifies otherwise, use these defaults:\n\n- **Fidelity level (visuals):** Pixel-perfect — exact match in colors, spacing, typography, animations, responsive behavior\n- **Copy & branding:** Replaced to match the `idea` from `launchframe.config.json` (product name, headlines, feature copy, CTA labels, testimonials). Visuals stay 1:1; words and brand marks get re-skinned.\n- **In scope:** Visual layout and styling, component structure and interactions, responsive design, mock data shaped for the SaaS idea\n- **Out of scope:** Real backend / database, authentication, real-time features, SEO optimization, accessibility audit\n- **Customization beyond the rebrand:** None during the initial pass — match 1:1 visually, swap copy/brand only\n\nIf the user provides additional instructions (specific fidelity level, deeper customizations, extra context), honor those over the defaults.\n\n## Pre-Flight\n\n1. **Read `launchframe.config.json`** (see Step 0 above). After a fresh `npx launchframe` scaffold, proceed immediately — only echo `url`/`idea` for confirmation if the config looks wrong or the user asked to verify.\n2. **Browser automation.** Prefer an MCP (Chrome DevTools MCP, Playwright MCP, Browserbase MCP, etc.) when it is healthy. **If MCP is missing or in an error state, run `npm run recon` (Playwright)** — see `scripts/recon-playwright.mjs`. It performs **stabilized full-document scrolling** at desktop and mobile, writes merged **`computed-snapshot.json`** + **`MEDIA_MANIFEST.md`**, and **full-page** screenshots under `docs/design-references/`. Use `npm run recon:headed` if headless hits a WAF/challenge page. One-time install: `npx playwright install chromium`. Do not skip extraction — adapt the pipeline to the tools that work.\n3. Validate the resolved URL(s). Normalize and verify each is accessible via your browser MCP tool. If any are invalid, ask the user to correct `launchframe.config.json` (or pass an override) before proceeding.\n4. Verify the base project builds: `npm run build`. The Next.js + shadcn/ui + Tailwind v4 scaffold should already be in place. If not, tell the user to run `npm install` first.\n5. Create the output directories if they don't exist: `docs/research/`, `docs/research/components/`, `docs/design-references/`, `scripts/`. Plan `docs/research/MEDIA_MANIFEST.md` as soon as media is inventoried. For multiple clones, also prepare per-site folders like `docs/research/<hostname>/` and `docs/design-references/<hostname>/`.\n6. 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.\n\n## Guiding Principles\n\nThese are the truths that separate a successful clone from a \"close enough\" mess. Internalize them — they should inform every decision you make.\n\n### 0. Launchframe priorities: media & motion (do not defer)\n\n**Raster & video are first-class.** Before you treat the page as “mostly typography,” run a dedicated **media inventory** (see `@docs/research/INSPECTION_GUIDE.md` Priority section): every `<img>`, `<picture>` / `<source>`, `<video>` (+ poster), and non-trivial `background-image`. Download to `public/images/` and `public/videos/` and write `docs/research/MEDIA_MANIFEST.md` (URL → local path, or `BLOCKED` + reason). Component specs MUST list concrete `public/...` paths; if you use a placeholder, say why in `docs/research/EXTRACTION_LIMITATIONS.md`. Never silently drop a hero layer, reel, or og visual.\n\n**Motion defaults to Framer Motion.** This template lists `framer-motion` as a dependency. After foundation tokens, ensure `import { motion } from \"framer-motion\"` (and related APIs: `useScroll`, `useTransform`, `AnimatePresence`, `LayoutGroup`, **`useReducedMotion`**) for: scroll-triggered reveals, staggered children, layout transitions, and gestures — anything beyond a trivial one-property CSS `transition`. In each spec file, add a **Motion** subsection: trigger, duration, easing, delay/stagger, **tier A–E coverage** (see `AGENTS.md` production polish table), reduced-motion fallback, and **implementation: CSS | framer-motion**. Prefer CSS only when it matches the target exactly without JS.\n\n**Illustration & pixel art are production inputs.** Where the target (or post-rebrand layout) lacks convincing visuals, specs MUST allocate **idea-tailored SVG scenes** — metaphors drawn from `launchframe.config.json#idea`, documented with **Idea tie-in** per asset — not generic gray placeholders or unrelated clipart. Pixel-art motifs require concept justification plus palette table in the spec.\n\n### 1. Completeness Beats Speed\n\nEvery 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.\n\n### 2. Small Tasks, Perfect Results\n\nWhen 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.\n\nLook 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.\n\n**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.\"\n\n### 3. Real Content, Real Assets\n\nExtract 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>`, extract inline `<svg>` elements as React components. The only time you generate content is when something is clearly server-generated and unique per session.\n\n**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.\n\n### 4. Foundation First\n\nNothing can be built until the foundation exists: global CSS with the target site's design tokens (colors, fonts, spacing), TypeScript types for the content structures, and global assets (fonts, favicons). This is sequential and non-negotiable. Everything after this can be parallel.\n\n### 5. Extract How It Looks AND How It Behaves\n\nA 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.\n\nFor 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`).\n\nExamples 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:\n- A navbar that shrinks, changes background, or gains a shadow after scrolling past a threshold\n- Elements that animate into view when they enter the viewport (fade-up, slide-in, stagger delays)\n- Sections that snap into place on scroll (`scroll-snap-type`)\n- Parallax layers that move at different rates than the scroll\n- Hover states that animate (not just change — the transition duration and easing matter)\n- Dropdowns, modals, accordions with enter/exit animations\n- Scroll-driven progress indicators or opacity transitions\n- Auto-playing carousels or cycling content\n- Dark-to-light (or any theme) transitions between page sections\n- **Tabbed/pill content that cycles** — buttons that switch visible card sets with transitions\n- **Scroll-driven tab/accordion switching** — sidebars where the active item auto-changes as content scrolls past (IntersectionObserver, NOT click handlers)\n- **Smooth scroll libraries** (Lenis, Locomotive Scroll) — check for `.lenis` class or scroll container wrappers\n\n### 6. Identify the Interaction Model Before Building\n\nThis 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?**\n\nHow to determine this:\n1. **Don't click first.** Scroll through the section slowly and observe if things change on their own as you scroll.\n2. If they do, it's scroll-driven. Extract the mechanism: `IntersectionObserver`, `scroll-snap`, `position: sticky`, `animation-timeline`, or JS scroll listeners.\n3. If nothing changes on scroll, THEN click/hover to test for click/hover-driven interactivity.\n4. Document the interaction model explicitly in the component spec: \"INTERACTION MODEL: scroll-driven with IntersectionObserver\" or \"INTERACTION MODEL: click-to-switch with opacity transition.\"\n\nA 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.\n\n### 7. Extract Every State, Not Just the Default\n\nMany 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.\n\nFor tabbed/stateful content:\n- Click each tab/button via browser MCP\n- Extract the content, images, and card data for EACH state\n- Record which content belongs to which state\n- Note the transition animation between states (opacity, slide, fade, etc.)\n\nFor scroll-dependent elements:\n- Capture computed styles at scroll position 0 (initial state)\n- Scroll past the trigger threshold and capture computed styles again (scrolled state)\n- Diff the two to identify exactly which CSS properties change\n- Record the transition CSS (duration, easing, properties)\n- Record the exact trigger threshold (scroll position in px, or viewport intersection ratio)\n\n### 8. Spec Files Are the Source of Truth\n\nEvery 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.\n\nThe 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.\n\n### 9. Build Must Always Compile\n\nEvery builder agent must verify `npx tsc --noEmit` passes before finishing. After merging worktrees, you verify `npm run build` passes. A broken build is never acceptable, even temporarily.\n\n## Phase 1: Reconnaissance\n\nNavigate to the target URL with browser MCP.\n\n### Screenshots *(entire landing — never “above the fold” only)*\n- Capture the **whole marketing surface**: hero through footer (single-page landings). Do **not** stop after the first viewport — lazy-loaded sections, footer nav, and bottom CTAs are required context.\n- Before **every** full-page capture (MCP or Playwright): **slow scroll top → bottom → top** once or twice until `scrollHeight` stops growing, so lazy images/`srcset`/`data-src` resolve where possible.\n- Take **`fullPage: true`** (or MCP equivalent) screenshots at desktop (**1440px**) and mobile (**390px**); save under `docs/design-references/` with descriptive names.\n- **`npm run recon`** already performs stabilized full-document scrolling + merged desktop/mobile asset inventory — prefer running it when automation must match full-page depth reliably.\n- These masters are references — builders still get section crops later, but those crops must exist because **you** scrolled and documented every band first.\n\n### Global Extraction\nExtract these from the page before doing anything else:\n\n**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. Configure them in `src/app/layout.tsx` using `next/font/google` or `next/font/local`.\n\n**Colors** — Extract the site's color palette from computed styles across the page. Update `src/app/globals.css` with the target's actual colors in the `:root` and `.dark` CSS variable blocks. Map them to shadcn's token names (background, foreground, primary, muted, etc.) where they fit. Add custom properties for colors that don't map to shadcn tokens.\n\n**Favicons & Meta** — Download favicons, apple-touch-icons, OG images, webmanifest to `public/seo/`. Update `layout.tsx` metadata.\n\n**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 `globals.css` and note any libraries that need to be installed.\n\n### Mandatory Interaction Sweep\n\nThis 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.\n\n**Scroll sweep:** Scroll the page slowly from top to bottom via browser MCP. At each section, pause and observe:\n- Does the header change appearance? Record the scroll position where it triggers.\n- Do elements animate into view? Record which ones and the animation type.\n- Does a sidebar or tab indicator auto-switch as you scroll? Record the mechanism.\n- Are there scroll-snap points? Record which containers.\n- Is there a smooth scroll library active? Check for non-native scroll behavior.\n\n**Click sweep:** Click every element that looks interactive:\n- Every button, tab, pill, link, card\n- Record what happens: does content change? Does a modal open? Does a dropdown appear?\n- For tabs/pills: click EACH ONE and record the content that appears for each state\n\n**Hover sweep:** Hover over every element that might have hover states:\n- Buttons, cards, links, images, nav items\n- Record what changes: color, scale, shadow, underline, opacity\n\n**Responsive sweep:** Test at 3 viewport widths via browser MCP:\n- Desktop: 1440px\n- Tablet: 768px\n- Mobile: 390px\n- At each width, note which sections change layout (column → stack, sidebar disappears, etc.) and at approximately which breakpoint the change occurs.\n\nSave all findings to `docs/research/BEHAVIORS.md`. This is your behavior bible — reference it when writing every component spec.\n\n### Page Topology\nMap out every distinct section of the page from top to bottom. Give each a working name. Document:\n- Their visual order\n- Which are fixed/sticky overlays vs. flow content\n- The overall page layout (scroll container, column structure, z-index layers)\n- Dependencies between sections (e.g., a floating nav that overlays everything)\n- **The interaction model** of each section (static, click-driven, scroll-driven, time-driven)\n\nSave this as `docs/research/PAGE_TOPOLOGY.md` — it becomes your assembly blueprint.\n\n## Phase 2: Foundation Build\n\nThis is sequential. Do it yourself (not delegated to an agent) since it touches many files:\n\n1. **Update fonts** in `layout.tsx` to match the target site's actual fonts\n2. **Confirm Framer Motion** — `framer-motion` should already be in `package.json`. If missing, add it (`npm install framer-motion`) so builders can import `motion` without ad-hoc library drift.\n3. **Update globals.css** with the target's color tokens, spacing values, keyframe animations, utility classes, and any **global scroll behaviors** (Lenis, smooth scroll CSS, scroll-snap on body)\n4. **Media inventory + download (early, high priority)** — run the asset discovery script (below) via browser MCP, write `docs/research/MEDIA_MANIFEST.md`, then implement **`scripts/download-assets.mjs`** and execute it so **images** land in `public/images/` and **videos** (+ posters) in `public/videos/` (or a clear subdirectory scheme under `public/`). Batch parallel downloads (4 concurrent) with errors logged — do not claim success if URLs failed. This step should complete **before** most section components are built so builders use real paths.\n5. **Create TypeScript interfaces** in `src/types/` for the content structures you've observed\n6. **Extract SVG icons** — find all inline `<svg>` elements on the page, deduplicate them, and save as named React components in `src/components/icons.tsx`. Name them by visual function (e.g., `SearchIcon`, `ArrowRightIcon`, `LogoIcon`).\n7. Verify: `npm run build` passes\n\n### Asset Discovery Script Pattern\n\nUse browser MCP to enumerate all assets on the page:\n\n```javascript\n// Run this via browser MCP to discover all assets\nJSON.stringify({\n images: [...document.querySelectorAll('img')].map(img => ({\n src: img.src || img.currentSrc,\n alt: img.alt,\n width: img.naturalWidth,\n height: img.naturalHeight,\n // Include parent info to detect layered compositions\n parentClasses: img.parentElement?.className,\n siblings: img.parentElement ? [...img.parentElement.querySelectorAll('img')].length : 0,\n position: getComputedStyle(img).position,\n zIndex: getComputedStyle(img).zIndex\n })),\n videos: [...document.querySelectorAll('video')].map(v => ({\n src: v.src || v.querySelector('source')?.src,\n poster: v.poster,\n autoplay: v.autoplay,\n loop: v.loop,\n muted: v.muted\n })),\n backgroundImages: [...document.querySelectorAll('*')].filter(el => {\n const bg = getComputedStyle(el).backgroundImage;\n return bg && bg !== 'none';\n }).map(el => ({\n url: getComputedStyle(el).backgroundImage,\n element: el.tagName + '.' + el.className?.split(' ')[0]\n })),\n svgCount: document.querySelectorAll('svg').length,\n fonts: [...new Set([...document.querySelectorAll('*')].slice(0, 200).map(el => getComputedStyle(el).fontFamily))],\n favicons: [...document.querySelectorAll('link[rel*=\"icon\"]')].map(l => ({ href: l.href, sizes: l.sizes?.toString() }))\n});\n```\n\nThen write a download script that fetches everything to `public/`. Use batched parallel downloads (4 at a time) with proper error handling.\n\n## Phase 3: Component Specification & Dispatch\n\nThis 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**.\n\n### Step 1: Extract\n\nFor each section, use browser MCP to extract everything:\n\n1. **Screenshot** the section in isolation (scroll to it, screenshot the viewport). Save to `docs/design-references/`.\n\n2. **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:\n\n```javascript\n// Per-component extraction — run via browser MCP\n// Replace SELECTOR with the actual CSS selector for the component\n(function(selector) {\n const el = document.querySelector(selector);\n if (!el) return JSON.stringify({ error: 'Element not found: ' + selector });\n const props = [\n 'fontSize','fontWeight','fontFamily','lineHeight','letterSpacing','color',\n 'textTransform','textDecoration','backgroundColor','background',\n 'padding','paddingTop','paddingRight','paddingBottom','paddingLeft',\n 'margin','marginTop','marginRight','marginBottom','marginLeft',\n 'width','height','maxWidth','minWidth','maxHeight','minHeight',\n 'display','flexDirection','justifyContent','alignItems','gap',\n 'gridTemplateColumns','gridTemplateRows',\n 'borderRadius','border','borderTop','borderBottom','borderLeft','borderRight',\n 'boxShadow','overflow','overflowX','overflowY',\n 'position','top','right','bottom','left','zIndex',\n 'opacity','transform','transition','cursor',\n 'objectFit','objectPosition','mixBlendMode','filter','backdropFilter',\n 'whiteSpace','textOverflow','WebkitLineClamp'\n ];\n function extractStyles(element) {\n const cs = getComputedStyle(element);\n const styles = {};\n 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; });\n return styles;\n }\n function walk(element, depth) {\n if (depth > 4) return null;\n const children = [...element.children];\n return {\n tag: element.tagName.toLowerCase(),\n classes: element.className?.toString().split(' ').slice(0, 5).join(' '),\n text: element.childNodes.length === 1 && element.childNodes[0].nodeType === 3 ? element.textContent.trim().slice(0, 200) : null,\n styles: extractStyles(element),\n images: element.tagName === 'IMG' ? { src: element.src, alt: element.alt, naturalWidth: element.naturalWidth, naturalHeight: element.naturalHeight } : null,\n childCount: children.length,\n children: children.slice(0, 20).map(c => walk(c, depth + 1)).filter(Boolean)\n };\n }\n return JSON.stringify(walk(el, 0), null, 2);\n})('SELECTOR');\n```\n\n3. **Extract multi-state styles** — for any element with multiple states (scroll-triggered, hover, active tab), capture BOTH states:\n\n```javascript\n// State A: capture styles at current state (e.g., scroll position 0)\n// Then trigger the state change (scroll, click, hover via browser MCP)\n// State B: re-run the extraction script on the same element\n// The diff between A and B IS the behavior specification\n```\n\nRecord the diff explicitly: \"Property X changes from VALUE_A to VALUE_B, triggered by TRIGGER, with transition: TRANSITION_CSS.\"\n\n4. **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**.\n\n5. **Identify assets** this section uses — which downloaded images/videos from `public/`, which icon components from `icons.tsx`. Check for **layered images** (multiple `<img>` or background-images stacked in the same container).\n\n6. **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).\n\n### Step 2: Write the Component Spec File\n\nFor 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.\n\n**File path:** `docs/research/components/<component-name>.spec.md`\n\n**Template:**\n\n```markdown\n# <ComponentName> Specification\n\n## Overview\n- **Target file:** `src/components/<ComponentName>.tsx`\n- **Screenshot:** `docs/design-references/<screenshot-name>.png`\n- **Interaction model:** <static | click-driven | scroll-driven | time-driven>\n\n## DOM Structure\n<Describe the element hierarchy — what contains what>\n\n## Computed Styles (exact values from getComputedStyle)\n\n### Container\n- display: ...\n- padding: ...\n- maxWidth: ...\n- (every relevant property with exact values)\n\n### <Child element 1>\n- fontSize: ...\n- color: ...\n- (every relevant property)\n\n### <Child element N>\n...\n\n## States & Behaviors\n\n### <Behavior name, e.g., \"Scroll-triggered floating mode\">\n- **Trigger:** <exact mechanism — scroll position 50px, IntersectionObserver rootMargin \"-30% 0px\", click on .tab-button, hover>\n- **State A (before):** maxWidth: 100vw, boxShadow: none, borderRadius: 0\n- **State B (after):** maxWidth: 1200px, boxShadow: 0 4px 20px rgba(0,0,0,0.1), borderRadius: 16px\n- **Transition:** transition: all 0.3s ease\n- **Implementation approach:** <CSS transition + scroll listener | IntersectionObserver | CSS animation-timeline | **framer-motion** (`motion`, `whileInView`, stagger container) | etc.>\n\n### Hover states\n- **<Element>:** <property>: <before> → <after>, transition: <value>\n\n## Motion (Framer Motion vs CSS)\n- **Tiers A–E:** <which tiers apply — load stagger, scroll reveal, ambient loop, interaction lifts, decorative parallax — list triggers>\n- **Reduced motion:** <what disables or simplifies when user prefers reduced motion>\n- **Entrance / scroll reveals:** <e.g. fade+translateY, staggerChildren — specify duration, easing, delay, viewport `once`/`margin`>\n- **Library:** <`framer-motion` | CSS-only — justify if CSS-only>\n- **Keyframes / springs:** <if any — match target curve>\n\n## Illustration & pixel art *(production uplift — idea-native)*\n- **Idea tie-in:** <one sentence — why this asset belongs only to this product>\n- **Metaphor link:** <which keyword from `idea` / metaphor list this illustrates>\n- **SVG components:** <named exports, paths using currentColor vs fixed fills>\n- **Pixel motif:** <palette hex table, grid, scaling — or N/A>\n- **Motif thread:** <how this echoes logo / OG / favicon for this SaaS>\n\n## Per-State Content (if applicable)\n\n### State: \"Featured\"\n- Title: \"...\"\n- Subtitle: \"...\"\n- Cards: [{ title, description, image, link }, ...]\n\n### State: \"Productivity\"\n- Title: \"...\"\n- Cards: [...]\n\n## Assets (images & video — required detail)\n- Raster: `public/images/<file>` — dimensions, `object-fit`, lazy if below fold\n- Video: `public/videos/<file>` — poster `public/images/...` or `public/videos/...`, autoplay/muted/loop, controls\n- Background layers: which div uses `background-image` and resolved URL → local path\n- Icons used: <ArrowIcon>, <SearchIcon> from icons.tsx\n\n## Text Content (verbatim)\n<All text content, copy-pasted from the live site>\n\n## Responsive Behavior\n- **Desktop (1440px):** <layout description>\n- **Tablet (768px):** <what changes — e.g., \"maintains 2-column, gap reduces to 16px\">\n- **Mobile (390px):** <what changes — e.g., \"stacks to single column, images full-width\">\n- **Breakpoint:** layout switches at ~<N>px\n```\n\nFill 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.\n\n### Step 3: Dispatch Builders\n\nBased on complexity, dispatch builder agent(s) in worktree(s):\n\n**Simple section** (1-2 sub-components): One builder agent gets the entire section.\n\n**Complex section** (3+ distinct sub-components): Break it up. One agent per sub-component, plus one agent for the section wrapper that imports them. Sub-component builders go first since the wrapper depends on them.\n\n**What every builder agent receives:**\n- The full contents of its component spec file (inline in the prompt — don't say \"go read the spec file\")\n- Path to the section screenshot in `docs/design-references/`\n- Which shared components to import (`icons.tsx`, `cn()`, shadcn primitives)\n- The target file path (e.g., `src/components/HeroSection.tsx`)\n- Instruction to verify with `npx tsc --noEmit` before finishing\n- For responsive behavior: the specific breakpoint values and what changes\n\n**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.\n\n### Step 4: Merge\n\nAs builder agents complete their work:\n- Merge their worktree branches into main\n- You have full context on what each agent built, so resolve any conflicts intelligently\n- After each merge, verify the build still passes: `npm run build`\n- If a merge introduces type errors, fix them immediately\n\nThe extract → spec → dispatch → merge cycle continues until all sections are built.\n\n## Phase 4: Page Assembly\n\nAfter all sections are built and merged, wire everything together in `src/app/page.tsx`:\n\n- Import all section components\n- Implement the page-level layout from your topology doc (scroll containers, column structures, sticky positioning, z-index layering)\n- Connect real content to component props\n- Implement page-level behaviors: scroll snap, scroll-driven animations, dark-to-light transitions, intersection observers, smooth scroll (Lenis etc.)\n- Verify: `npm run build` passes clean\n\n## Phase 4.5: SaaS Rebrand Pass\n\nThe pixel-perfect clone is done — now re-skin it for the SaaS idea from `launchframe.config.json`.\n\n**Guiding rule:** swap words and brand marks, leave structure untouched. The original site's visual hierarchy was already validated by a real product team. Your job is to put the user's product into that proven shell, not to redesign it.\n\nFor every section, replace:\n\n1. **Product name & logo** — wherever the original brand appears, use the SaaS idea's name (derive a short product name from the `idea` string if one isn't supplied — keep it 1–2 words, easy to lockup). Replace the wordmark text in place. For the logo glyph, either reuse the original SVG silhouette with a fresh fill, or use a Lucide icon that matches the SaaS category (e.g., `Brain` for AI, `Workflow` for automation, `Sparkles` for generative tooling). Do NOT keep the original brand's actual logo file.\n2. **Hero headline & sub-headline** — write fresh copy that pitches the SaaS idea, using the original line lengths and tone as constraints. If the original is 6 words, write 6 words. If it's 14, write 14. Match emphasis, line breaks, and any inline highlighted phrase.\n3. **Feature/section copy** — rewrite each feature card, callout, stat, and testimonial to fit the SaaS idea. Preserve the count and shape of items (3 feature cards stay 3 feature cards; a 4-column logo bar stays 4 columns). Generate plausible customer-logo names — never use real company names you haven't been authorized to use.\n4. **CTA labels** — adapt button text to the SaaS idea (\"Start free\", \"Get a demo\", \"Try it free\", etc.). Keep the CTA hierarchy (primary/secondary) identical to the original.\n5. **Mock data** — for product UI mockups embedded in marketing screenshots (e.g., a fake dashboard inside a hero), generate mock data shaped for the SaaS idea: realistic-looking but fictional rows, charts, conversation logs, etc.\n6. **Imagery** — Replace photography/screenshots that depict the original brand with visuals **authored for this SaaS idea**, not interchangeable decoration. Before designing: derive a **metaphor list** from `idea` (3–6 concrete hooks). Each hero/feature/OG asset gets an **Idea tie-in** sentence in `docs/research/REBRAND.md`. Prefer bespoke SVG scenes (`src/components/marketing/art/`) or raster under `public/images/marketing/` that preserve dimensions/aspect/shadows from the cloned layout. **Avoid:** unrelated filler (e.g. apparel, random lifestyle props when the product is notes/voice), generic gradient-only heroes, Lucide-icon piles unless the reference was already that minimal — those fail the uniqueness bar in `AGENTS.md`.\n7. **Metadata** — update `<title>`, meta description, OG tags, and favicon manifest in `src/app/layout.tsx` to reflect the new SaaS. Generate a simple favicon (initial letter on a brand-colored square) if no asset is provided.\n\nWhat you must NOT change in this pass:\n- Spacing, padding, typography scale, color tokens, **animation timing & motion choreography** (including Framer Motion `variants` / `transition` props), responsive breakpoints — those are still 1:1 to the original\n- Section order, section count, component structure\n- Interaction models (scroll-driven stays scroll-driven, etc.)\n- Any computed-style value extracted in Phase 3\n\nAfter the rebrand pass, the codebase should look like the original site visually but read like the user's SaaS at a glance. Save a short `docs/research/REBRAND.md` summarizing the product name you chose, the headline rewrites, and any assets you swapped — so the user can audit what's clone-derived vs. authored.\n\n## Phase 4.6: Production uplift *(sparse references / stronger idea-specific art)*\n\nRun this pass when **any** of the following is true:\n\n- The cloned reference is mostly typography with weak imagery (internal demos, minimalist SaaS shells).\n- The user asks for **more unique images**, **illustration tailored to the idea**, **stronger visuals**, motion, pixel art, or production polish.\n- Visual QA feels “correct but dead” — layout matches but art is generic, unrelated, or repeated stock metaphors.\n\n**Do not contradict pixel-perfect emulation when cloning a rich reference** — this phase *adds* or swaps **idea-native** imagery only where the brief allows uplift or the reference was inherently flat.\n\nChecklist (mirror `AGENTS.md` — **uniqueness first**):\n\n1. **Idea-tailored imagery** — Metaphor list from `idea`; replace any asset that could belong to another vertical. Per-asset **Idea tie-in** in `docs/research/PRODUCTION_UPLIFT.md` alongside SVG/raster paths.\n2. **Density** — Layered hero + distinct scene per feature card in **one shared visual language** (stroke/accent/grid), still idea-specific.\n3. **Motion tiers** — Implement at minimum **A + B + one of C/D**, optionally **E**: staggered hero load, `whileInView` sections + card stagger, looping ambient (marquee / caret / SVG dash loop), hover lifts / nav scroll shrink, optional light parallax. Gate loops with **`useReducedMotion()`**.\n4. **Brand** — Motif thread + accent tokens in `:root`; favicon / OG echo **this** product narrative.\n\nDocument deltas in `docs/research/PRODUCTION_UPLIFT.md`.\n\n## Phase 5: Visual QA Diff\n\nAfter assembly, do NOT declare the clone complete. Take side-by-side comparison screenshots:\n\n1. Open the original site and your clone side-by-side (or take screenshots at the same viewport widths)\n2. Compare section by section, top to bottom, at desktop (1440px)\n3. Compare again at mobile (390px)\n4. For each discrepancy found:\n - Check the component spec file — was the value extracted correctly?\n - If the spec was wrong: re-extract from browser MCP, update the spec, fix the component\n - If the spec was right but the builder got it wrong: fix the component to match the spec\n5. Test all interactive behaviors: scroll through the page, click every button/tab, hover over interactive elements\n6. Verify smooth scroll feels right, header transitions work, tab switching works, animations play\n\nOnly after this visual QA pass is the clone complete.\n\n## Pre-Dispatch Checklist\n\nBefore dispatching ANY builder agent, verify you can check every box. If you can't, go back and extract more.\n\n- [ ] Spec file written to `docs/research/components/<name>.spec.md` with ALL sections filled\n- [ ] Every CSS value in the spec is from `getComputedStyle()`, not estimated\n- [ ] Interaction model is identified and documented (static / click / scroll / time)\n- [ ] For stateful components: every state's content and styles are captured\n- [ ] For scroll-driven components: trigger threshold, before/after styles, and transition are recorded\n- [ ] For hover states: before/after values and transition timing are recorded\n- [ ] All images in the section are identified (including overlays and layered compositions)\n- [ ] Any `<video>` (and poster), Lottie, or canvas-driven hero is identified — not approximated as a static div\n- [ ] **Motion** subsection filled: tiers **A–E** coverage (see `AGENTS.md`), CSS vs **framer-motion**, durations, easings, stagger, scroll triggers, **reduced-motion** fallback\n- [ ] **Illustration** subsection filled when uplift applies: **Idea tie-in** + metaphor link per asset, SVG/pixel detail — or explicit **N/A** with justification only on strict clone parity jobs\n- [ ] Responsive behavior is documented for at least desktop and mobile\n- [ ] Text content is verbatim from the site, not paraphrased\n- [ ] The builder prompt is under ~150 lines of spec; if over, the section needs to be split\n\n## What NOT to Do\n\nThese are lessons from previous failed clones — each one cost hours of rework:\n\n- **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 is the #1 most expensive mistake — it requires a complete rewrite, not a CSS fix.\n- **Don't extract only the default state.** If there are tabs showing \"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+.\n- **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.\n- **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.\n- **Don't approximate CSS classes.** \"It looks like `text-lg`\" is wrong if the computed value is `18px` and `text-lg` is `18px/28px` but the actual line-height is `24px`. Extract exact values.\n- **Don't build everything in one monolithic commit.** The whole point of this pipeline is incremental progress with verified builds at each step.\n- **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.\n- **Don't skip asset extraction.** Without real images, videos, and fonts, the clone will always look fake regardless of how perfect the CSS is.\n- **Don't defer image/video download to the end.** Run `MEDIA_MANIFEST.md` + `download-assets.mjs` during foundation so components reference real `public/` paths from the first build.\n- **Don't fake complex motion with a single CSS `transition` when the target uses staggered, scroll-scrubbed, or layout-driven animation** — use **`framer-motion`** (`motion`, `whileInView`, `variants`, `staggerChildren`) and match duration/easing from extraction.\n- **Don't give a builder agent too much scope.** If you're writing a builder prompt and it's getting long because the section is complex, that's a signal to break it into smaller tasks.\n- **Don't bundle unrelated sections into one agent.** A CTA section and a footer are different components with different designs — don't hand them both to one agent and hope for the best.\n- **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.\n- **Don't forget smooth scroll libraries.** Check for Lenis (`.lenis` class), Locomotive Scroll, or similar. Default browser scrolling feels noticeably different and the user will spot it immediately.\n- **Don't ship interchangeable marketing art.** Random objects, unrelated lifestyle stock, or generic gradients that could match any SaaS violate the **idea-tailored** rule in `AGENTS.md` — every major visual needs a metaphor from `launchframe.config.json#idea`.\n- **Don't dispatch builders without a spec file.** The spec file forces exhaustive extraction and creates an auditable artifact. Skipping it means the builder gets whatever you can fit in a prompt from memory.\n\n## Completion\n\nWhen done, report:\n- Source URL cloned (from `launchframe.config.json` or `the target URL provided by the user`)\n- SaaS idea applied (from `launchframe.config.json`) and the product name you chose\n- Total sections built\n- Total components created\n- Total spec files written (should match components)\n- Total assets downloaded (images, videos, SVGs, fonts) — path to `docs/research/MEDIA_MANIFEST.md`\n- Rebrand summary (path to `docs/research/REBRAND.md`)\n- Build status (`npm run build` result)\n- Visual QA results (any remaining discrepancies)\n- Any known gaps or limitations\n",
|
|
5
5
|
"fileContext": [
|
|
6
6
|
"AGENTS.md",
|
|
7
7
|
"docs/research/**"
|
|
@@ -40,15 +40,25 @@ Treat these as **first-class deliverables**, not polish at the end.
|
|
|
40
40
|
2. **Motion** — Match the target’s feel: easing, duration, stagger, scroll triggers. Prefer **`motion` from `framer-motion`** for entrance sequences, viewport-driven animations, shared-layout-style transitions, and anything beyond a one-off CSS transition. Note in each component spec whether behavior is **CSS-only** vs **Framer Motion**.
|
|
41
41
|
3. **Illustration & brand marks** — Inline **SVG React components** (not only Lucide) for motifs that repeat across sections: logo glyph variants, dividers, grain/noise overlays, hero “scene” shapes, feature-card mini-compositions. Prefer **`currentColor`** + CSS variables so SVGs inherit theme tokens. For **pixel art**, keep a tight palette (4–8 fills), consistent pixel grid logic, and use `style={{ imageRendering: "pixelated" }}` on upscaled raster OR build pixel SVG paths intentionally — never blurry upscale.
|
|
42
42
|
|
|
43
|
-
## Production polish for marketing landings *(
|
|
43
|
+
## Production polish for marketing landings *(idea-tailored visuals + motion + brand)*
|
|
44
44
|
|
|
45
|
-
Use this whenever the page is **authored or minimalist** (internal templates, rebranded clones that still feel flat, or targets that are mostly typography). “Looks OK” is not ship-ready — **production landings** stack multiple visual layers, choreographed motion, and
|
|
45
|
+
Use this whenever the page is **authored or minimalist** (internal templates, rebranded clones that still feel flat, or targets that are mostly typography). “Looks OK” is not ship-ready — **production landings** stack multiple visual layers, choreographed motion, and cues that clearly belong to **this** product (`launchframe.config.json#idea`), not any SaaS.
|
|
46
|
+
|
|
47
|
+
### Idea-tailored imagery *(uniqueness bar)*
|
|
48
|
+
|
|
49
|
+
Generic decoration fails review. Apply this to **every** hero composition, feature-card illustration, OG image sketch, and major `public/` marketing raster.
|
|
50
|
+
|
|
51
|
+
1. **Derive metaphors from the idea** — Read `idea` (and product name). List 3–6 concrete nouns/verbs the product owns (e.g. voice → waveform, mic; notes → folded page, margin line; sync → paired arrows). Every bespoke visual must trace back to that list — **not** interchangeable clipart (random apparel, unrelated lifestyle objects, vague “business” silhouettes unless the idea demands them).
|
|
52
|
+
2. **Could this ship on another site unchanged?** If yes, redesign until **no** — different silhouette story, palette accent, or composition so the asset “only fits” this narrative.
|
|
53
|
+
3. **One tie-in sentence per asset** — In specs or `docs/research/REBRAND.md`, each image/SVG scene gets **Idea tie-in:** `<why this belongs to this product>`.
|
|
54
|
+
4. **Prefer authored scenes** — Custom SVG narratives (several shapes telling one moment), optional pixel mascot **on-brand** for the category, or composed raster under `public/images/marketing/` when illustration needs texture. Lucide-only piles and neutral blobs are **last resort**, not default.
|
|
55
|
+
5. **Distinct accents** — Pick accent hues/shapes suggested by the idea’s personality (precise studio vs warm companion vs rugged utility); avoid default gray-only SaaS anonymity unless the brief is explicitly brutalist.
|
|
46
56
|
|
|
47
57
|
### Imagery density (every fold earns a visual idea)
|
|
48
58
|
|
|
49
|
-
- **Hero** — Never headline-only on white: add at least two of — soft gradient mesh / radial spotlight,
|
|
50
|
-
- **Between sections** — Optional
|
|
51
|
-
- **Feature rows** —
|
|
59
|
+
- **Hero** — Never headline-only on white: add at least two of — soft gradient mesh / radial spotlight, **idea-specific** SVG cluster (metaphors from the list above), notebook/grid lines when the idea is docs, waveform device frame when the idea is capture, masked **purpose-built** raster in `public/images/marketing/`, geometric frame echoing **this** logo shape.
|
|
60
|
+
- **Between sections** — Optional dividers whose pattern/stroke **echoes the product motif** (not a stock wave).
|
|
61
|
+
- **Feature rows** — Each card illustration is a **different** moment in the same visual language (shared stroke weight, accent, or grid) — all still **idea-native** (e.g. capture → transcript lines; workspace → shared cursors; publish → export channels). No unrelated filler.
|
|
52
62
|
- **Social proof** — Logo strip may use grayscale marks; add **slow infinite marquee** or gentle opacity drift — motion sells “living product.”
|
|
53
63
|
|
|
54
64
|
### Motion choreography *(ship several layers; respect `prefers-reduced-motion`)*
|
|
@@ -80,9 +90,7 @@ Always gate looping motion: **`useReducedMotion()`** from Framer Motion — swap
|
|
|
80
90
|
|
|
81
91
|
### Spec requirement *(hand-off quality)*
|
|
82
92
|
|
|
83
|
-
When writing `docs/research/components/*.spec.md`, add sections **Illustration** (layers, SVG components, raster paths) and expand **Motion** with tier **A–E** coverage and reduced-motion fallback. Builders should not invent motion ad hoc — the spec states durations and triggers.
|
|
84
|
-
|
|
85
|
-
Invoke **`marketing-landing-production`** (`.claude/skills/marketing-landing-production/SKILL.md`) when the user asks for **prod-ready polish**, **more motion**, **SVG/pixel art**, or **stronger branding** on an existing landing.
|
|
93
|
+
When writing `docs/research/components/*.spec.md`, add sections **Illustration** (**Idea tie-in** per asset, layers, SVG components, raster paths) and expand **Motion** with tier **A–E** coverage and reduced-motion fallback. Builders should not invent motion ad hoc — the spec states durations and triggers.
|
|
86
94
|
|
|
87
95
|
## Commands
|
|
88
96
|
- `npm run dev` — Start dev server
|
|
@@ -112,7 +120,8 @@ Prefer **Playwright** for repeatable extraction in-repo — do **not** rely on C
|
|
|
112
120
|
## Design Principles
|
|
113
121
|
- **Images & video fidelity** — prefer real downloaded assets; preserve aspect ratio, `object-fit`, layering, and poster frames. Rebrand pass may **swap** URLs for IP-safe alternates but must keep layout identical.
|
|
114
122
|
- **Motion fidelity** — timing and easing matter as much as color; use Framer Motion when CSS alone cannot match staggered or scroll-driven behavior.
|
|
115
|
-
- **
|
|
123
|
+
- **Idea-specific imagery** — Marketing art (SVG, raster, OG) must be **tailored to `launchframe.config.json#idea`**: explicit metaphors, per-asset **Idea tie-in** notes, and **no interchangeable filler** that could belong to any generic SaaS.
|
|
124
|
+
- **Production landing density** — For authored/minimal pages, deliberately add **idea-specific** illustration (not generic SaaS filler), **pixel-art accents** when they reinforce the metaphor, and **tiered motion (A–E)** per “Production polish” above; static monochrome layouts are incomplete unless the user explicitly wants extreme minimalism.
|
|
116
125
|
- **Pixel-perfect emulation** — match the target's spacing, colors, typography exactly
|
|
117
126
|
- **No personal aesthetic changes during emulation phase** — match 1:1 first, rebrand later
|
|
118
127
|
- **Real content during extraction** — use actual text and assets from the target site so the clone scaffolds against real shapes
|
|
@@ -146,7 +155,6 @@ scripts/ # Asset download scripts
|
|
|
146
155
|
- When launching Claude Code agent teams, ALWAYS have each teammate work in their own worktree branch and merge everyone's work at the end, resolving any merge conflicts smartly since you are basically serving the orchestrator role and have full context to our goals, work given, work achieved, and desired outcomes.
|
|
147
156
|
- After editing `AGENTS.md`, run `bash scripts/sync-agent-rules.sh` to regenerate platform-specific instruction files.
|
|
148
157
|
- After editing `.claude/skills/clone-website/SKILL.md`, run `node scripts/sync-skills.mjs` to regenerate the skill for all platforms.
|
|
149
|
-
- After editing `.claude/skills/marketing-landing-production/SKILL.md`, update `.cursor/commands/marketing-landing-production.md` to match (Cursor command is maintained beside the Claude skill until sync-skills grows multi-skill support).
|
|
150
158
|
|
|
151
159
|
# Website Inspection Guide
|
|
152
160
|
|
|
@@ -173,17 +181,19 @@ If automation hits a bot wall, **do not pretend extraction succeeded** — captu
|
|
|
173
181
|
- [ ] **Gestures** — drag, pan, hover follow (often Framer Motion)
|
|
174
182
|
- [ ] **Implementation rule** — use **`framer-motion`** for anything beyond trivial single-property CSS `transition`. Record **duration, easing, delay, stagger**, and **trigger** (scroll, hover, tap) in specs.
|
|
175
183
|
|
|
176
|
-
### 3.
|
|
184
|
+
### 3. Idea-tailored illustration & motifs *(production landings)*
|
|
177
185
|
|
|
178
|
-
When the reference page is **sparse** (mostly type + gray boxes) or after a **rebrand** the UI still reads generic,
|
|
186
|
+
When the reference page is **sparse** (mostly type + gray boxes) or after a **rebrand** the UI still reads generic, illustration is required — and it must be **unique to the SaaS idea** (`launchframe.config.json#idea`), not reusable wallpaper.
|
|
179
187
|
|
|
180
|
-
- [ ] **
|
|
181
|
-
- [ ] **
|
|
182
|
-
- [ ] **
|
|
183
|
-
- [ ] **
|
|
184
|
-
- [ ] **
|
|
188
|
+
- [ ] **Metaphor list** — 3–6 nouns/verbs derived from `idea`; every bespoke asset maps to ≥ one entry
|
|
189
|
+
- [ ] **Uniqueness check** — If the scene works unchanged for another product category, revise
|
|
190
|
+
- [ ] **Inline SVG** — hero shapes, dividers, card mini-scenes; note `viewBox`, **`currentColor`** vs fixed fills, **Idea tie-in** sentence per asset
|
|
191
|
+
- [ ] **Pixel art / sprites** — only when character reinforces the metaphor; palette hex table; `imageRendering` / grid discipline
|
|
192
|
+
- [ ] **Motif thread** — recurring element echoing hero + OG + favicon **for this product**, not a random geometric pattern
|
|
193
|
+
- [ ] **Accent tokens** — primary/secondary roles aligned with idea personality (extract from reference or define in `:root`)
|
|
194
|
+
- [ ] **Motion tiers A–E** — document with **reduced-motion** fallback (`prefers-reduced-motion`)
|
|
185
195
|
|
|
186
|
-
See **`AGENTS.md` → Production polish for marketing landings** for tier definitions and
|
|
196
|
+
See **`AGENTS.md` → Production polish for marketing landings** for tier definitions and folders (`src/components/marketing/art/`, `public/images/marketing/`).
|
|
187
197
|
|
|
188
198
|
---
|
|
189
199
|
|
|
@@ -40,7 +40,7 @@ If the user provides additional instructions (specific fidelity level, deeper cu
|
|
|
40
40
|
## Pre-Flight
|
|
41
41
|
|
|
42
42
|
1. **Read `launchframe.config.json`** (see Step 0 above). After a fresh `npx launchframe` scaffold, proceed immediately — only echo `url`/`idea` for confirmation if the config looks wrong or the user asked to verify.
|
|
43
|
-
2. **Browser automation.** Prefer an MCP (Chrome DevTools MCP, Playwright MCP, Browserbase MCP, etc.) when it is healthy. **If MCP is missing or in an error state, run `npm run recon` (Playwright)** — see `scripts/recon-playwright.mjs`. It writes
|
|
43
|
+
2. **Browser automation.** Prefer an MCP (Chrome DevTools MCP, Playwright MCP, Browserbase MCP, etc.) when it is healthy. **If MCP is missing or in an error state, run `npm run recon` (Playwright)** — see `scripts/recon-playwright.mjs`. It performs **stabilized full-document scrolling** at desktop and mobile, writes merged **`computed-snapshot.json`** + **`MEDIA_MANIFEST.md`**, and **full-page** screenshots under `docs/design-references/`. Use `npm run recon:headed` if headless hits a WAF/challenge page. One-time install: `npx playwright install chromium`. Do not skip extraction — adapt the pipeline to the tools that work.
|
|
44
44
|
3. Validate the resolved URL(s). Normalize and verify each is accessible via your browser MCP tool. If any are invalid, ask the user to correct `launchframe.config.json` (or pass an override) before proceeding.
|
|
45
45
|
4. Verify the base project builds: `npm run build`. The Next.js + shadcn/ui + Tailwind v4 scaffold should already be in place. If not, tell the user to run `npm install` first.
|
|
46
46
|
5. Create the output directories if they don't exist: `docs/research/`, `docs/research/components/`, `docs/design-references/`, `scripts/`. Plan `docs/research/MEDIA_MANIFEST.md` as soon as media is inventoried. For multiple clones, also prepare per-site folders like `docs/research/<hostname>/` and `docs/design-references/<hostname>/`.
|
|
@@ -56,7 +56,7 @@ These are the truths that separate a successful clone from a "close enough" mess
|
|
|
56
56
|
|
|
57
57
|
**Motion defaults to Framer Motion.** This template lists `framer-motion` as a dependency. After foundation tokens, ensure `import { motion } from "framer-motion"` (and related APIs: `useScroll`, `useTransform`, `AnimatePresence`, `LayoutGroup`, **`useReducedMotion`**) for: scroll-triggered reveals, staggered children, layout transitions, and gestures — anything beyond a trivial one-property CSS `transition`. In each spec file, add a **Motion** subsection: trigger, duration, easing, delay/stagger, **tier A–E coverage** (see `AGENTS.md` production polish table), reduced-motion fallback, and **implementation: CSS | framer-motion**. Prefer CSS only when it matches the target exactly without JS.
|
|
58
58
|
|
|
59
|
-
**Illustration & pixel art are production inputs.** Where the target (or post-rebrand layout) lacks convincing visuals, specs MUST
|
|
59
|
+
**Illustration & pixel art are production inputs.** Where the target (or post-rebrand layout) lacks convincing visuals, specs MUST allocate **idea-tailored SVG scenes** — metaphors drawn from `launchframe.config.json#idea`, documented with **Idea tie-in** per asset — not generic gray placeholders or unrelated clipart. Pixel-art motifs require concept justification plus palette table in the spec.
|
|
60
60
|
|
|
61
61
|
### 1. Completeness Beats Speed
|
|
62
62
|
|
|
@@ -143,10 +143,12 @@ Every builder agent must verify `npx tsc --noEmit` passes before finishing. Afte
|
|
|
143
143
|
|
|
144
144
|
Navigate to the target URL with browser MCP.
|
|
145
145
|
|
|
146
|
-
### Screenshots
|
|
147
|
-
-
|
|
148
|
-
-
|
|
149
|
-
-
|
|
146
|
+
### Screenshots *(entire landing — never “above the fold” only)*
|
|
147
|
+
- Capture the **whole marketing surface**: hero through footer (single-page landings). Do **not** stop after the first viewport — lazy-loaded sections, footer nav, and bottom CTAs are required context.
|
|
148
|
+
- Before **every** full-page capture (MCP or Playwright): **slow scroll top → bottom → top** once or twice until `scrollHeight` stops growing, so lazy images/`srcset`/`data-src` resolve where possible.
|
|
149
|
+
- Take **`fullPage: true`** (or MCP equivalent) screenshots at desktop (**1440px**) and mobile (**390px**); save under `docs/design-references/` with descriptive names.
|
|
150
|
+
- **`npm run recon`** already performs stabilized full-document scrolling + merged desktop/mobile asset inventory — prefer running it when automation must match full-page depth reliably.
|
|
151
|
+
- These masters are references — builders still get section crops later, but those crops must exist because **you** scrolled and documented every band first.
|
|
150
152
|
|
|
151
153
|
### Global Extraction
|
|
152
154
|
Extract these from the page before doing anything else:
|
|
@@ -376,10 +378,12 @@ For each section (or sub-component, if you're breaking it up), create a spec fil
|
|
|
376
378
|
- **Library:** <`framer-motion` | CSS-only — justify if CSS-only>
|
|
377
379
|
- **Keyframes / springs:** <if any — match target curve>
|
|
378
380
|
|
|
379
|
-
## Illustration & pixel art *(production uplift)*
|
|
381
|
+
## Illustration & pixel art *(production uplift — idea-native)*
|
|
382
|
+
- **Idea tie-in:** <one sentence — why this asset belongs only to this product>
|
|
383
|
+
- **Metaphor link:** <which keyword from `idea` / metaphor list this illustrates>
|
|
380
384
|
- **SVG components:** <named exports, paths using currentColor vs fixed fills>
|
|
381
385
|
- **Pixel motif:** <palette hex table, grid, scaling — or N/A>
|
|
382
|
-
- **Motif thread:** <how
|
|
386
|
+
- **Motif thread:** <how this echoes logo / OG / favicon for this SaaS>
|
|
383
387
|
|
|
384
388
|
## Per-State Content (if applicable)
|
|
385
389
|
|
|
@@ -461,11 +465,7 @@ For every section, replace:
|
|
|
461
465
|
3. **Feature/section copy** — rewrite each feature card, callout, stat, and testimonial to fit the SaaS idea. Preserve the count and shape of items (3 feature cards stay 3 feature cards; a 4-column logo bar stays 4 columns). Generate plausible customer-logo names — never use real company names you haven't been authorized to use.
|
|
462
466
|
4. **CTA labels** — adapt button text to the SaaS idea ("Start free", "Get a demo", "Try it free", etc.). Keep the CTA hierarchy (primary/secondary) identical to the original.
|
|
463
467
|
5. **Mock data** — for product UI mockups embedded in marketing screenshots (e.g., a fake dashboard inside a hero), generate mock data shaped for the SaaS idea: realistic-looking but fictional rows, charts, conversation logs, etc.
|
|
464
|
-
6. **Imagery** —
|
|
465
|
-
- A neutral abstract gradient / shape composition you generate with CSS or SVG
|
|
466
|
-
- A Lucide icon arrangement
|
|
467
|
-
- Placeholder service URLs only if explicitly allowed by the user
|
|
468
|
-
Keep dimensions, aspect ratios, drop shadows, and surrounding spacing identical to the original.
|
|
468
|
+
6. **Imagery** — Replace photography/screenshots that depict the original brand with visuals **authored for this SaaS idea**, not interchangeable decoration. Before designing: derive a **metaphor list** from `idea` (3–6 concrete hooks). Each hero/feature/OG asset gets an **Idea tie-in** sentence in `docs/research/REBRAND.md`. Prefer bespoke SVG scenes (`src/components/marketing/art/`) or raster under `public/images/marketing/` that preserve dimensions/aspect/shadows from the cloned layout. **Avoid:** unrelated filler (e.g. apparel, random lifestyle props when the product is notes/voice), generic gradient-only heroes, Lucide-icon piles unless the reference was already that minimal — those fail the uniqueness bar in `AGENTS.md`.
|
|
469
469
|
7. **Metadata** — update `<title>`, meta description, OG tags, and favicon manifest in `src/app/layout.tsx` to reflect the new SaaS. Generate a simple favicon (initial letter on a brand-colored square) if no asset is provided.
|
|
470
470
|
|
|
471
471
|
What you must NOT change in this pass:
|
|
@@ -476,25 +476,24 @@ What you must NOT change in this pass:
|
|
|
476
476
|
|
|
477
477
|
After the rebrand pass, the codebase should look like the original site visually but read like the user's SaaS at a glance. Save a short `docs/research/REBRAND.md` summarizing the product name you chose, the headline rewrites, and any assets you swapped — so the user can audit what's clone-derived vs. authored.
|
|
478
478
|
|
|
479
|
-
## Phase 4.6: Production uplift *(sparse references /
|
|
479
|
+
## Phase 4.6: Production uplift *(sparse references / stronger idea-specific art)*
|
|
480
480
|
|
|
481
481
|
Run this pass when **any** of the following is true:
|
|
482
482
|
|
|
483
483
|
- The cloned reference is mostly typography with weak imagery (internal demos, minimalist SaaS shells).
|
|
484
|
-
- The user asks for **more
|
|
485
|
-
- Visual QA feels “correct but dead” — layout matches but
|
|
484
|
+
- The user asks for **more unique images**, **illustration tailored to the idea**, **stronger visuals**, motion, pixel art, or production polish.
|
|
485
|
+
- Visual QA feels “correct but dead” — layout matches but art is generic, unrelated, or repeated stock metaphors.
|
|
486
486
|
|
|
487
|
-
**Do not contradict pixel-perfect emulation when cloning a rich reference** — this phase *adds*
|
|
487
|
+
**Do not contradict pixel-perfect emulation when cloning a rich reference** — this phase *adds* or swaps **idea-native** imagery only where the brief allows uplift or the reference was inherently flat.
|
|
488
488
|
|
|
489
|
-
Checklist (mirror `AGENTS.md`):
|
|
489
|
+
Checklist (mirror `AGENTS.md` — **uniqueness first**):
|
|
490
490
|
|
|
491
|
-
1. **
|
|
492
|
-
2. **
|
|
493
|
-
3. **
|
|
491
|
+
1. **Idea-tailored imagery** — Metaphor list from `idea`; replace any asset that could belong to another vertical. Per-asset **Idea tie-in** in `docs/research/PRODUCTION_UPLIFT.md` alongside SVG/raster paths.
|
|
492
|
+
2. **Density** — Layered hero + distinct scene per feature card in **one shared visual language** (stroke/accent/grid), still idea-specific.
|
|
493
|
+
3. **Motion tiers** — Implement at minimum **A + B + one of C/D**, optionally **E**: staggered hero load, `whileInView` sections + card stagger, looping ambient (marquee / caret / SVG dash loop), hover lifts / nav scroll shrink, optional light parallax. Gate loops with **`useReducedMotion()`**.
|
|
494
|
+
4. **Brand** — Motif thread + accent tokens in `:root`; favicon / OG echo **this** product narrative.
|
|
494
495
|
|
|
495
|
-
Document deltas in `docs/research/PRODUCTION_UPLIFT.md
|
|
496
|
-
|
|
497
|
-
Invoke `.claude/skills/marketing-landing-production/SKILL.md` as a focused playbook for this pass.
|
|
496
|
+
Document deltas in `docs/research/PRODUCTION_UPLIFT.md`.
|
|
498
497
|
|
|
499
498
|
## Phase 5: Visual QA Diff
|
|
500
499
|
|
|
@@ -525,7 +524,7 @@ Before dispatching ANY builder agent, verify you can check every box. If you can
|
|
|
525
524
|
- [ ] All images in the section are identified (including overlays and layered compositions)
|
|
526
525
|
- [ ] Any `<video>` (and poster), Lottie, or canvas-driven hero is identified — not approximated as a static div
|
|
527
526
|
- [ ] **Motion** subsection filled: tiers **A–E** coverage (see `AGENTS.md`), CSS vs **framer-motion**, durations, easings, stagger, scroll triggers, **reduced-motion** fallback
|
|
528
|
-
- [ ] **Illustration** subsection filled when uplift applies:
|
|
527
|
+
- [ ] **Illustration** subsection filled when uplift applies: **Idea tie-in** + metaphor link per asset, SVG/pixel detail — or explicit **N/A** with justification only on strict clone parity jobs
|
|
529
528
|
- [ ] Responsive behavior is documented for at least desktop and mobile
|
|
530
529
|
- [ ] Text content is verbatim from the site, not paraphrased
|
|
531
530
|
- [ ] The builder prompt is under ~150 lines of spec; if over, the section needs to be split
|
|
@@ -548,6 +547,7 @@ These are lessons from previous failed clones — each one cost hours of rework:
|
|
|
548
547
|
- **Don't bundle unrelated sections into one agent.** A CTA section and a footer are different components with different designs — don't hand them both to one agent and hope for the best.
|
|
549
548
|
- **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.
|
|
550
549
|
- **Don't forget smooth scroll libraries.** Check for Lenis (`.lenis` class), Locomotive Scroll, or similar. Default browser scrolling feels noticeably different and the user will spot it immediately.
|
|
550
|
+
- **Don't ship interchangeable marketing art.** Random objects, unrelated lifestyle stock, or generic gradients that could match any SaaS violate the **idea-tailored** rule in `AGENTS.md` — every major visual needs a metaphor from `launchframe.config.json#idea`.
|
|
551
551
|
- **Don't dispatch builders without a spec file.** The spec file forces exhaustive extraction and creates an auditable artifact. Skipping it means the builder gets whatever you can fit in a prompt from memory.
|
|
552
552
|
|
|
553
553
|
## Completion
|
|
@@ -39,7 +39,7 @@ If the user provides additional instructions (specific fidelity level, deeper cu
|
|
|
39
39
|
## Pre-Flight
|
|
40
40
|
|
|
41
41
|
1. **Read `launchframe.config.json`** (see Step 0 above). After a fresh `npx launchframe` scaffold, proceed immediately — only echo `url`/`idea` for confirmation if the config looks wrong or the user asked to verify.
|
|
42
|
-
2. **Browser automation.** Prefer an MCP (Chrome DevTools MCP, Playwright MCP, Browserbase MCP, etc.) when it is healthy. **If MCP is missing or in an error state, run `npm run recon` (Playwright)** — see `scripts/recon-playwright.mjs`. It writes
|
|
42
|
+
2. **Browser automation.** Prefer an MCP (Chrome DevTools MCP, Playwright MCP, Browserbase MCP, etc.) when it is healthy. **If MCP is missing or in an error state, run `npm run recon` (Playwright)** — see `scripts/recon-playwright.mjs`. It performs **stabilized full-document scrolling** at desktop and mobile, writes merged **`computed-snapshot.json`** + **`MEDIA_MANIFEST.md`**, and **full-page** screenshots under `docs/design-references/`. Use `npm run recon:headed` if headless hits a WAF/challenge page. One-time install: `npx playwright install chromium`. Do not skip extraction — adapt the pipeline to the tools that work.
|
|
43
43
|
3. Validate the resolved URL(s). Normalize and verify each is accessible via your browser MCP tool. If any are invalid, ask the user to correct `launchframe.config.json` (or pass an override) before proceeding.
|
|
44
44
|
4. Verify the base project builds: `npm run build`. The Next.js + shadcn/ui + Tailwind v4 scaffold should already be in place. If not, tell the user to run `npm install` first.
|
|
45
45
|
5. Create the output directories if they don't exist: `docs/research/`, `docs/research/components/`, `docs/design-references/`, `scripts/`. Plan `docs/research/MEDIA_MANIFEST.md` as soon as media is inventoried. For multiple clones, also prepare per-site folders like `docs/research/<hostname>/` and `docs/design-references/<hostname>/`.
|
|
@@ -55,7 +55,7 @@ These are the truths that separate a successful clone from a "close enough" mess
|
|
|
55
55
|
|
|
56
56
|
**Motion defaults to Framer Motion.** This template lists `framer-motion` as a dependency. After foundation tokens, ensure `import { motion } from "framer-motion"` (and related APIs: `useScroll`, `useTransform`, `AnimatePresence`, `LayoutGroup`, **`useReducedMotion`**) for: scroll-triggered reveals, staggered children, layout transitions, and gestures — anything beyond a trivial one-property CSS `transition`. In each spec file, add a **Motion** subsection: trigger, duration, easing, delay/stagger, **tier A–E coverage** (see `AGENTS.md` production polish table), reduced-motion fallback, and **implementation: CSS | framer-motion**. Prefer CSS only when it matches the target exactly without JS.
|
|
57
57
|
|
|
58
|
-
**Illustration & pixel art are production inputs.** Where the target (or post-rebrand layout) lacks convincing visuals, specs MUST
|
|
58
|
+
**Illustration & pixel art are production inputs.** Where the target (or post-rebrand layout) lacks convincing visuals, specs MUST allocate **idea-tailored SVG scenes** — metaphors drawn from `launchframe.config.json#idea`, documented with **Idea tie-in** per asset — not generic gray placeholders or unrelated clipart. Pixel-art motifs require concept justification plus palette table in the spec.
|
|
59
59
|
|
|
60
60
|
### 1. Completeness Beats Speed
|
|
61
61
|
|
|
@@ -142,10 +142,12 @@ Every builder agent must verify `npx tsc --noEmit` passes before finishing. Afte
|
|
|
142
142
|
|
|
143
143
|
Navigate to the target URL with browser MCP.
|
|
144
144
|
|
|
145
|
-
### Screenshots
|
|
146
|
-
-
|
|
147
|
-
-
|
|
148
|
-
-
|
|
145
|
+
### Screenshots *(entire landing — never “above the fold” only)*
|
|
146
|
+
- Capture the **whole marketing surface**: hero through footer (single-page landings). Do **not** stop after the first viewport — lazy-loaded sections, footer nav, and bottom CTAs are required context.
|
|
147
|
+
- Before **every** full-page capture (MCP or Playwright): **slow scroll top → bottom → top** once or twice until `scrollHeight` stops growing, so lazy images/`srcset`/`data-src` resolve where possible.
|
|
148
|
+
- Take **`fullPage: true`** (or MCP equivalent) screenshots at desktop (**1440px**) and mobile (**390px**); save under `docs/design-references/` with descriptive names.
|
|
149
|
+
- **`npm run recon`** already performs stabilized full-document scrolling + merged desktop/mobile asset inventory — prefer running it when automation must match full-page depth reliably.
|
|
150
|
+
- These masters are references — builders still get section crops later, but those crops must exist because **you** scrolled and documented every band first.
|
|
149
151
|
|
|
150
152
|
### Global Extraction
|
|
151
153
|
Extract these from the page before doing anything else:
|
|
@@ -375,10 +377,12 @@ For each section (or sub-component, if you're breaking it up), create a spec fil
|
|
|
375
377
|
- **Library:** <`framer-motion` | CSS-only — justify if CSS-only>
|
|
376
378
|
- **Keyframes / springs:** <if any — match target curve>
|
|
377
379
|
|
|
378
|
-
## Illustration & pixel art *(production uplift)*
|
|
380
|
+
## Illustration & pixel art *(production uplift — idea-native)*
|
|
381
|
+
- **Idea tie-in:** <one sentence — why this asset belongs only to this product>
|
|
382
|
+
- **Metaphor link:** <which keyword from `idea` / metaphor list this illustrates>
|
|
379
383
|
- **SVG components:** <named exports, paths using currentColor vs fixed fills>
|
|
380
384
|
- **Pixel motif:** <palette hex table, grid, scaling — or N/A>
|
|
381
|
-
- **Motif thread:** <how
|
|
385
|
+
- **Motif thread:** <how this echoes logo / OG / favicon for this SaaS>
|
|
382
386
|
|
|
383
387
|
## Per-State Content (if applicable)
|
|
384
388
|
|
|
@@ -460,11 +464,7 @@ For every section, replace:
|
|
|
460
464
|
3. **Feature/section copy** — rewrite each feature card, callout, stat, and testimonial to fit the SaaS idea. Preserve the count and shape of items (3 feature cards stay 3 feature cards; a 4-column logo bar stays 4 columns). Generate plausible customer-logo names — never use real company names you haven't been authorized to use.
|
|
461
465
|
4. **CTA labels** — adapt button text to the SaaS idea ("Start free", "Get a demo", "Try it free", etc.). Keep the CTA hierarchy (primary/secondary) identical to the original.
|
|
462
466
|
5. **Mock data** — for product UI mockups embedded in marketing screenshots (e.g., a fake dashboard inside a hero), generate mock data shaped for the SaaS idea: realistic-looking but fictional rows, charts, conversation logs, etc.
|
|
463
|
-
6. **Imagery** —
|
|
464
|
-
- A neutral abstract gradient / shape composition you generate with CSS or SVG
|
|
465
|
-
- A Lucide icon arrangement
|
|
466
|
-
- Placeholder service URLs only if explicitly allowed by the user
|
|
467
|
-
Keep dimensions, aspect ratios, drop shadows, and surrounding spacing identical to the original.
|
|
467
|
+
6. **Imagery** — Replace photography/screenshots that depict the original brand with visuals **authored for this SaaS idea**, not interchangeable decoration. Before designing: derive a **metaphor list** from `idea` (3–6 concrete hooks). Each hero/feature/OG asset gets an **Idea tie-in** sentence in `docs/research/REBRAND.md`. Prefer bespoke SVG scenes (`src/components/marketing/art/`) or raster under `public/images/marketing/` that preserve dimensions/aspect/shadows from the cloned layout. **Avoid:** unrelated filler (e.g. apparel, random lifestyle props when the product is notes/voice), generic gradient-only heroes, Lucide-icon piles unless the reference was already that minimal — those fail the uniqueness bar in `AGENTS.md`.
|
|
468
468
|
7. **Metadata** — update `<title>`, meta description, OG tags, and favicon manifest in `src/app/layout.tsx` to reflect the new SaaS. Generate a simple favicon (initial letter on a brand-colored square) if no asset is provided.
|
|
469
469
|
|
|
470
470
|
What you must NOT change in this pass:
|
|
@@ -475,25 +475,24 @@ What you must NOT change in this pass:
|
|
|
475
475
|
|
|
476
476
|
After the rebrand pass, the codebase should look like the original site visually but read like the user's SaaS at a glance. Save a short `docs/research/REBRAND.md` summarizing the product name you chose, the headline rewrites, and any assets you swapped — so the user can audit what's clone-derived vs. authored.
|
|
477
477
|
|
|
478
|
-
## Phase 4.6: Production uplift *(sparse references /
|
|
478
|
+
## Phase 4.6: Production uplift *(sparse references / stronger idea-specific art)*
|
|
479
479
|
|
|
480
480
|
Run this pass when **any** of the following is true:
|
|
481
481
|
|
|
482
482
|
- The cloned reference is mostly typography with weak imagery (internal demos, minimalist SaaS shells).
|
|
483
|
-
- The user asks for **more
|
|
484
|
-
- Visual QA feels “correct but dead” — layout matches but
|
|
483
|
+
- The user asks for **more unique images**, **illustration tailored to the idea**, **stronger visuals**, motion, pixel art, or production polish.
|
|
484
|
+
- Visual QA feels “correct but dead” — layout matches but art is generic, unrelated, or repeated stock metaphors.
|
|
485
485
|
|
|
486
|
-
**Do not contradict pixel-perfect emulation when cloning a rich reference** — this phase *adds*
|
|
486
|
+
**Do not contradict pixel-perfect emulation when cloning a rich reference** — this phase *adds* or swaps **idea-native** imagery only where the brief allows uplift or the reference was inherently flat.
|
|
487
487
|
|
|
488
|
-
Checklist (mirror `AGENTS.md`):
|
|
488
|
+
Checklist (mirror `AGENTS.md` — **uniqueness first**):
|
|
489
489
|
|
|
490
|
-
1. **
|
|
491
|
-
2. **
|
|
492
|
-
3. **
|
|
490
|
+
1. **Idea-tailored imagery** — Metaphor list from `idea`; replace any asset that could belong to another vertical. Per-asset **Idea tie-in** in `docs/research/PRODUCTION_UPLIFT.md` alongside SVG/raster paths.
|
|
491
|
+
2. **Density** — Layered hero + distinct scene per feature card in **one shared visual language** (stroke/accent/grid), still idea-specific.
|
|
492
|
+
3. **Motion tiers** — Implement at minimum **A + B + one of C/D**, optionally **E**: staggered hero load, `whileInView` sections + card stagger, looping ambient (marquee / caret / SVG dash loop), hover lifts / nav scroll shrink, optional light parallax. Gate loops with **`useReducedMotion()`**.
|
|
493
|
+
4. **Brand** — Motif thread + accent tokens in `:root`; favicon / OG echo **this** product narrative.
|
|
493
494
|
|
|
494
|
-
Document deltas in `docs/research/PRODUCTION_UPLIFT.md
|
|
495
|
-
|
|
496
|
-
Invoke `.claude/skills/marketing-landing-production/SKILL.md` as a focused playbook for this pass.
|
|
495
|
+
Document deltas in `docs/research/PRODUCTION_UPLIFT.md`.
|
|
497
496
|
|
|
498
497
|
## Phase 5: Visual QA Diff
|
|
499
498
|
|
|
@@ -524,7 +523,7 @@ Before dispatching ANY builder agent, verify you can check every box. If you can
|
|
|
524
523
|
- [ ] All images in the section are identified (including overlays and layered compositions)
|
|
525
524
|
- [ ] Any `<video>` (and poster), Lottie, or canvas-driven hero is identified — not approximated as a static div
|
|
526
525
|
- [ ] **Motion** subsection filled: tiers **A–E** coverage (see `AGENTS.md`), CSS vs **framer-motion**, durations, easings, stagger, scroll triggers, **reduced-motion** fallback
|
|
527
|
-
- [ ] **Illustration** subsection filled when uplift applies:
|
|
526
|
+
- [ ] **Illustration** subsection filled when uplift applies: **Idea tie-in** + metaphor link per asset, SVG/pixel detail — or explicit **N/A** with justification only on strict clone parity jobs
|
|
528
527
|
- [ ] Responsive behavior is documented for at least desktop and mobile
|
|
529
528
|
- [ ] Text content is verbatim from the site, not paraphrased
|
|
530
529
|
- [ ] The builder prompt is under ~150 lines of spec; if over, the section needs to be split
|
|
@@ -547,6 +546,7 @@ These are lessons from previous failed clones — each one cost hours of rework:
|
|
|
547
546
|
- **Don't bundle unrelated sections into one agent.** A CTA section and a footer are different components with different designs — don't hand them both to one agent and hope for the best.
|
|
548
547
|
- **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.
|
|
549
548
|
- **Don't forget smooth scroll libraries.** Check for Lenis (`.lenis` class), Locomotive Scroll, or similar. Default browser scrolling feels noticeably different and the user will spot it immediately.
|
|
549
|
+
- **Don't ship interchangeable marketing art.** Random objects, unrelated lifestyle stock, or generic gradients that could match any SaaS violate the **idea-tailored** rule in `AGENTS.md` — every major visual needs a metaphor from `launchframe.config.json#idea`.
|
|
550
550
|
- **Don't dispatch builders without a spec file.** The spec file forces exhaustive extraction and creates an auditable artifact. Skipping it means the builder gets whatever you can fit in a prompt from memory.
|
|
551
551
|
|
|
552
552
|
## Completion
|