How Multi-State Component Behaviors Are Captured During Website Cloning

The JCodesMore/ai-website-cloner-template extracts interactive component behaviors by triggering state changes, diffing computed styles before and after each interaction, and recording the results in structured specification files for builder agents.

The ai-website-cloner-template treats user interface elements as state machines rather than static markup. To preserve the full interactive experience of the original site, the cloning pipeline explicitly mandates capturing multi-state component behaviors—documenting every visual transformation triggered by scroll, hover, click, or timeout. This requirement is hard-coded in the skill definition at .github/skills/clone-website/SKILL.md, which instructs agents to "Extract multi-state styles" and to "capture BOTH states" for every interactive element.

The Multi-State Extraction Protocol

Static screenshots lose the interactive layer that defines modern web experiences. The cloning workflow compensates by treating each interactive element as a set of discrete states that must be documented, compared, and reconstructed.

Identifying Stateful Elements

Before extraction begins, the reconnaissance phase scans the target page for elements that change under user interaction or time-based conditions. According to the checklist defined in .github/skills/clone-website/SKILL.md (lines 35-45), agents flag components such as sticky headers, hover cards, accordion tabs, and scroll-driven animations for multi-state capture.

Capturing the Baseline State (State A)

With the page in its initial condition (typically scroll position zero), the agent executes a JavaScript extraction snippet that calls getComputedStyle() on the target element. This captures the complete set of computed CSS properties—including backgroundColor, transform, opacity, and transition—that define the visual appearance before any interaction occurs.

The extraction script filters out default values (none, 0px, auto) to produce a clean baseline:

// Replace SELECTOR with the component’s CSS selector
(function(selector) {
  const el = document.querySelector(selector);
  if (!el) return JSON.stringify({ error: 'Element not found: ' + selector });
  const props = [
    'fontSize','fontWeight','color','backgroundColor','padding','margin',
    'borderRadius','boxShadow','opacity','transform','transition','zIndex'
  ];
  const extract = e => {
    const cs = getComputedStyle(e);
    return props.reduce((out, p) => {
      const v = cs[p];
      if (v && v !== 'none' && v !== '0px' && v !== 'auto')
        out[p] = v;
      return out;
    }, {});
  };
  return JSON.stringify({ selector, styles: extract(el) });
})('SELECTOR');

Triggering the State Change

The agent uses the browser Model Context Protocol (MCP) to perform the exact interaction that causes the state transition. This may include scrolling to a specific threshold, hovering over an element, clicking a tab control, or waiting for a timeout to elapse. The specific trigger mechanism (e.g., scroll-position > 80px) is recorded alongside the visual data.

Capturing the Transformed State (State B)

Immediately after triggering the interaction, the same extraction script runs again to capture the new computed styles. For example, when documenting a scroll-driven header transformation:

// State A – top of page
const before = await page.evaluate(() => {
  const h = document.querySelector('header');
  return getComputedStyle(h).backgroundColor;
});

// Trigger – scroll 100px
await page.evaluate(() => window.scrollTo(0, 100));

// State B – after scroll
const after = await page.evaluate(() => {
  const h = document.querySelector('header');
  return getComputedStyle(h).backgroundColor;
});

console.log({
  property: 'background-color',
  before,
  after,
  trigger: 'scroll-position > 80px',
  transition: 'all 0.3s ease',
});

Generating the Behavior Diff

The agent produces a concise diff comparing State A and State B. This behavior specification includes the changed CSS properties, the exact values before and after, the trigger condition, and the transition timing function. The skill file explicitly warns against capturing only the default view, mandating that agents "Extract every state, not just the default" (lines 93-98).

The Component Specification Format

All gathered data—DOM hierarchy, computed styles for each state, triggers, transitions, assets, and text content—is written to a markdown specification file under docs/research/components/. The template for these specs is defined in .github/skills/clone-website/SKILL.md (lines 106-136).

A generated spec for a scroll-sensitive header component looks like this:

## States & Behaviors

### Scroll‑triggered header shrink

- **Trigger:** scroll‑position > 80px
- **State A (before):** background-color: rgba(255,255,255,1); height: 80px; box-shadow: none
- **State B (after):**  background-color: rgba(30,30,30,1); height: 56px; box-shadow: 0 2px 6px rgba(0,0,0,0.1)
- **Transition:** all 0.3s ease
- **Implementation:** IntersectionObserver toggles `data-scrolled` attribute; CSS reads `[data-scrolled] { … }`

Reconstructing Interactions in React

Builder agents receive the complete multi-state spec inline in their prompt context. They generate React components that switch between the recorded states using the exact CSS values extracted from the original site. Interactions are implemented using appropriate listeners—IntersectionObserver for scroll triggers, onClick for tabs, and onMouseEnter/onMouseLeave for hover effects.

The generated components utilize the cn utility from src/lib/utils.ts to apply the precise class strings and style objects derived from the specification diffs, ensuring the rebuilt component matches the original's timing and visual feel.

Validation and Build Verification

After component generation, the pipeline validates that the reconstructed behaviors match the recorded specifications. The system runs npx tsc --noEmit to verify type safety, followed by npm run build to ensure the code compiles and that the interactive behaviors function as specified in the research documents.

Summary

• Multi-state capture is mandatory, not optional: The skill definition at .github/skills/clone-website/SKILL.md requires documenting both before and after states for every interactive element.
• Computed style diffing: The system triggers interactions (scroll, hover, click) and diffs getComputedStyle() results to generate exact behavior specifications.
• Structured storage: State data is stored in markdown specs under docs/research/components/, including triggers, transitions, and implementation notes.
• Accurate reconstruction: Builder agents use the specs to generate React components with matching interaction handlers and CSS values.
• Automated validation: The pipeline verifies generated code with TypeScript checks and production builds to ensure fidelity.

Frequently Asked Questions

What qualifies as a "state" in the cloning context?

A state is any distinct visual condition of a component that results from user interaction or environmental changes. This includes hover states, active tab panels, scroll-transformed headers, modal open/close states, and timeout-based animations. If an element's getComputedStyle() results differ between two conditions, those are treated as separate states that must both be documented.

How does the system handle complex animations or transitions?

The extraction process captures the start and end values of the relevant CSS properties along with the transition timing function defined in the computed styles. While the intermediate interpolation is handled by the browser's rendering engine, the spec records the initial state, final state, and transition parameters (duration, easing, delay) so the reconstructed component can replicate the exact animation curve using standard CSS transitions or CSS-in-JS equivalents.

Where are the multi-state specifications stored?

Individual component specifications are saved as markdown files in the docs/research/components/ directory. Each file follows the template defined in the skill documentation and includes the DOM structure, asset references, verbatim text content, and the multi-state behavior diffs. These spec files serve as the single source of truth for subsequent builder agents.

What happens if a state change cannot be triggered automatically?

If a state requires user authentication, specific viewport conditions, or third-party data that the automated browser cannot replicate, the agent notes the limitation in the spec file and captures a static screenshot of the secondary state. The builder agent then receives instructions to implement the state transition logic based on the visual reference and the trigger description (e.g., "authenticated user view"), though the exact computed style values may require manual approximation in these edge cases.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}