# How the AI Website Cloner Differentiates and Handles Scroll-Driven vs. Click-Driven Interactions

> Discover how the AI Website Cloner distinguishes scroll-driven from click-driven interactions. Learn its unique scroll-first inspection protocol for accurate component tagging.

- Repository: [JCodesMore/ai-website-cloner-template](https://github.com/JCodesMore/ai-website-cloner-template)
- Tags: internals
- Published: 2026-06-23

---

**The JCodesMore AI Website Cloner employs a strict scroll-first inspection protocol that records computed styles at scroll position 0 before any user simulation occurs, explicitly tagging each component as scroll-driven or click-driven in the generated specification.**

The `JCodesMore/ai-website-cloner-template` repository distinguishes between scroll-driven and click-driven interactions through a systematic three-stage pipeline defined in its workflow documentation. This methodology prevents common cloning errors where scroll-based animations are mistakenly implemented as click handlers. By mandating that agents observe visual changes during slow scrolling before attempting any clicks, the system accurately captures the true interaction model of the target website.

## The Three-Stage Inspection Pipeline

The cloner's decision logic lives in the specification-generation workflow rather than runtime code. According to the source code in [`.windsurf/workflows/clone-website.md`](https://github.com/JCodesMore/ai-website-cloner-template/blob/main/.windsurf/workflows/clone-website.md), the inspection process follows three distinct stages to determine interaction types.

### Stage 1: Scroll-First Observation

Agents begin by scrolling slowly through the target page and recording computed styles via `getComputedStyle()` at scroll position 0. If visual changes—such as layout shifts, color transitions, or element appearances—occur solely as scroll position changes, the section is immediately marked as **scroll-driven**. The workflow documentation explicitly instructs agents to "*don't click first*" during this initial observation phase.

### Stage 2: Trigger Mechanism Detection

For sections identified as scroll-driven, the cloner extracts the exact trigger mechanism. This includes `IntersectionObserver` thresholds, `scroll-snap-type` properties, `position: sticky` declarations, CSS `animation-timeline` values, or custom JavaScript scroll listeners. The workflow mandates recording precise trigger details, such as `IntersectionObserver` root margins like `"-30% 0px"`, ensuring the builder can reproduce the identical behavior.

### Stage 3: Interaction Model Documentation

The agent creates an explicit component specification entry that states either `INTERACTION MODEL: scroll-driven with IntersectionObserver` or `INTERACTION MODEL: click-driven with opacity transition`. This specification, documented according to [`.opencode/commands/clone-website.md`](https://github.com/JCodesMore/ai-website-cloner-template/blob/main/.opencode/commands/clone-website.md), is consumed by the builder agent to generate the appropriate implementation code.

## Implementing Scroll-Driven Interactions

When the cloner identifies a scroll-driven interaction, it captures two distinct states: the initial state at scroll position 0 and the post-trigger state. The system saves computed CSS values for both states and records the exact trigger parameters—whether pixel offsets, viewport ratios, or selector-based thresholds.

The builder then generates code that reproduces this behavior using the recorded trigger mechanism. For example, when `IntersectionObserver` drives the interaction, the generated React code appears as follows:

```tsx
import { useEffect, useRef, useState } from "react";

export default function ScrollTabs() {
  const [active, setActive] = useState<string>("section-1");
  const containerRef = useRef<HTMLDivElement>(null);

  useEffect(() => {
    if (!containerRef.current) return;
    const observer = new IntersectionObserver(
      ([entry]) => {
        if (entry.isIntersecting) setActive(entry.target.id);
      },
      {
        root: null,
        rootMargin: "-30% 0px", // ← recorded trigger threshold
        threshold: 0,
      }
    );
    containerRef.current.querySelectorAll("[data-tab]").forEach((el) => {
      observer.observe(el);
    });
    return () => observer.disconnect();
  }, []);

  return (
    <div ref={containerRef} className="scroll-tabs">
      {/* Sections rendered with data-tab attributes */}
    </div>
  );
}

```

## Implementing Click-Driven Interactions

For click-driven interactions, the cloner first verifies that no changes occur during the scroll observation phase. Only after confirming scroll invariance does the agent proceed to click elements and capture CSS states before and after the interaction. The system documents the precise click selector and transition properties, including duration and easing functions.

The generated implementation creates explicit event handlers rather than scroll listeners:

```tsx
import { useState } from "react";

export function ClickAccordion() {
  const [openId, setOpenId] = useState<string | null>(null);

  const toggle = (id: string) => setOpenId(openId === id ? null : id);

  return (
    <div className="accordion">
      {["item1", "item2", "item3"].map((id) => (
        <div key={id} className="accordion-item">
          <button onClick={() => toggle(id)} className="header">
            Header {id}
          </button>
          <div
            className={`content ${openId === id ? "expanded" : "collapsed"}`}
            /* CSS transition captured from the original site */
          >
            Content for {id}
          </div>
        </div>
      ))}
    </div>
  );
}

```

## Key Configuration Files

The differentiation logic is distributed across several configuration files that guide the AI agents:

| File | Role in Interaction Detection |
|------|-------------------------------|
| [`.windsurf/workflows/clone-website.md`](https://github.com/JCodesMore/ai-website-cloner-template/blob/main/.windsurf/workflows/clone-website.md) | Contains the primary "scroll first" directive and trigger capture instructions (lines 60-68, 100-108) |
| [`.opencode/commands/clone-website.md`](https://github.com/JCodesMore/ai-website-cloner-template/blob/main/.opencode/commands/clone-website.md) | Mandates explicit documentation of interaction models in component specs (lines 86-89) |
| [`.github/skills/clone-website/SKILL.md`](https://github.com/JCodesMore/ai-website-cloner-template/blob/main/.github/skills/clone-website/SKILL.md) | Supplies identical interaction-model instructions to GitHub-based agents (lines 63-89) |
| [`docs/research/INSPECTION_GUIDE.md`](https://github.com/JCodesMore/ai-website-cloner-template/blob/main/docs/research/INSPECTION_GUIDE.md) | Lists interaction-type checklist items including scroll behavior markers |
| [`src/app/page.tsx`](https://github.com/JCodesMore/ai-website-cloner-template/blob/main/src/app/page.tsx) | Consumes the generated component specs and renders the final implementation |

## Summary

- **Scroll-first inspection**: Agents must scroll through pages and record `getComputedStyle()` values before clicking, as defined in [`.windsurf/workflows/clone-website.md`](https://github.com/JCodesMore/ai-website-cloner-template/blob/main/.windsurf/workflows/clone-website.md).
- **Explicit modeling**: Each component receives an `INTERACTION MODEL` label identifying it as scroll-driven or click-driven in the specification.
- **Trigger precision**: Scroll-driven interactions capture exact thresholds like `IntersectionObserver` root margins, while click-driven interactions record selector targets and CSS transitions.
- **Implementation separation**: The builder generates `IntersectionObserver` hooks for scroll-driven behaviors and `onClick` handlers for click-driven behaviors based on the documented spec.

## Frequently Asked Questions

### How does the cloner avoid misclassifying a scroll animation as a click interaction?

The workflow explicitly prohibits clicking during the initial observation phase. Agents scroll slowly through the target page recording computed styles at scroll position 0, and any visual change occurring solely due to scroll position is flagged as scroll-driven before any click simulation begins.

### What specific trigger details does the cloner record for scroll-driven sections?

According to [`.windsurf/workflows/clone-website.md`](https://github.com/JCodesMore/ai-website-cloner-template/blob/main/.windsurf/workflows/clone-website.md), the cloner records exact trigger mechanisms including `IntersectionObserver` root margins (e.g., `"-30% 0px"`), `scroll-snap-type` values, `position: sticky` configurations, and CSS `animation-timeline` properties to ensure pixel-perfect reproduction.

### Where is the interaction type documented in the cloning pipeline?

The interaction model is explicitly written in the component specification as `INTERACTION MODEL: scroll-driven with [mechanism]` or `INTERACTION MODEL: click-driven with [transition]`, as mandated in [`.opencode/commands/clone-website.md`](https://github.com/JCodesMore/ai-website-cloner-template/blob/main/.opencode/commands/clone-website.md) lines 86-89, allowing the builder agent to select the correct implementation pattern.

### Can the cloner handle hybrid interactions that use both scroll and click triggers?

The current pipeline processes scroll and click detection sequentially—first establishing scroll behavior, then testing click responses. Each interaction mode is documented separately in the component spec, enabling the builder to implement combined behaviors using both `IntersectionObserver` hooks and click handlers where the source site uses hybrid approaches.