Website Interaction Model Detection Process: How AI Agents Analyze Scroll vs Click Behavior

The interaction model detection process is a systematic reconnaissance workflow that determines whether website sections respond to scroll events, click events, or remain static, documented in component specifications to guide builder agents.

The JCodesMore/ai-website-cloner-template repository encodes this critical analysis phase within the /clone-website skill, ensuring reverse-engineered sites faithfully replicate their original interaction patterns. Detecting whether a header fades on scroll or a tab panel requires a click prevents costly rebuilds later in the cloning pipeline.

The Five-Step Interaction Model Detection Workflow

The process follows a strict sequence defined in .windsurf/workflows/clone-website.md and mirrored in .opencode/commands/clone-website.md. Each step builds upon the previous to create a complete behavioral map.

Step 1: Scroll-First Reconnaissance (Don't Click First)

Begin by scrolling slowly from top to bottom without clicking any elements. Observe visual changes that trigger automatically during scroll movement.

When elements change during this sweep, label the section scroll-driven. Record the specific mechanism powering the animation, such as IntersectionObserver, CSS scroll-snap, position: sticky, CSS animation timelines, or custom JavaScript scroll listeners.

Step 2: Click-Driven Element Identification

If the scroll sweep reveals no changes, proceed to click interactive elements including buttons, tabs, pills, and cards. Sections that react only after user clicks are marked click-driven.

Document the transition type for each interaction, noting whether the change involves opacity fades, slide animations, or content swaps.

Step 3: Hover State Documentation

Perform an optional hover sweep over potential interactive elements to capture hover-only states. These subtle interactions are recorded separately in the component specification as distinct visual states, ensuring the cloned site preserves micro-interactions like button highlights or card lifts.

Step 4: Responsive Breakpoint Testing

Resize the viewport to three standard breakpoints—desktop (1440px), tablet (768px), and mobile (390px)—and repeat the scroll and click sweeps at each size.

Note any breakpoint-specific behavior changes, such as a sticky sidebar converting to a top navigation bar on mobile devices.

Step 5: Component Specification Documentation

Write all findings into the component specification file located at docs/research/components/.... Use clear tags like INTERACTION MODEL: scroll-driven with IntersectionObserver to create an unambiguous contract for builder agents.

Why Detection Order Matters (The "Most Expensive Mistake")

The documentation in .windsurf/workflows/clone-website.md (lines 81-90) explicitly warns that mixing up a scroll-driven tab panel for a click-driven one forces a full rewrite later.

This ordering prevents the "most expensive mistake" in the cloning workflow: building the wrong JavaScript architecture. Scroll-driven components require scroll-behaviour libraries like Lenis or Locomotive Scroll imported in src/app/layout.tsx or src/app/globals.css, while click-driven components need state management and event handlers.

Practical Detection Scripts

Use these browser console scripts during the reconnaissance phase to log interactions systematically.

Detecting Scroll-Driven Elements

// Run during the scroll sweep to identify viewport-triggered animations
let observed = new Set();
window.addEventListener('scroll', () => {
  document.querySelectorAll('[data-animate]').forEach(el => {
    const rect = el.getBoundingClientRect();
    if (rect.top < window.innerHeight && !observed.has(el)) {
      console.log('Scroll-driven element entered view:', el);
      observed.add(el);
    }
  });
});

This script records every element that becomes visible or changes as the user scrolls, helping identify whether the mechanism uses IntersectionObserver or CSS animation-timeline.

Identifying Click-Driven Interactions

// Run after the scroll sweep completes
document.querySelectorAll('.tab-button').forEach(btn => {
  btn.addEventListener('click', () => {
    const panel = document.querySelector(btn.dataset.target);
    console.log('Click-driven tab opened:', panel.id);
  });
});

When you click each tab, the console logs the associated panel, confirming a click-driven interaction model requiring React state management rather than scroll listeners.

Capturing Hover States

document.querySelectorAll('button, a, .card').forEach(el => {
  el.addEventListener('mouseenter', () => {
    console.log('Hover state entered:', el);
  });
});

These hover logs are added to the component spec as additional visual states for the builder agents to implement.

Recording Interaction Models in Component Specs

The final documentation format uses inline markdown specifications that builder agents consume directly:

## Header Component

**INTERACTION MODEL:** scroll-driven with IntersectionObserver  
- Trigger: when page scroll reaches 120px  
- Action: header background fades from transparent → solid, logo scales 0.9→1.0  
- Assets: `src/components/icons/LogoIcon.tsx`

Builder agents read this spec to generate the exact React/TypeScript code, importing the correct animation libraries and implementing the precise trigger logic.

Summary

• Scroll-first methodology prevents architectural mistakes by establishing passive animations before testing active interactions.
• Five-step workflow includes scroll reconnaissance, click identification, hover documentation, responsive testing, and spec documentation.
• Source files defining this process reside in .windsurf/workflows/clone-website.md and .opencode/commands/clone-website.md.
• Component specifications stored in docs/research/components/ serve as the contract between detection agents and builder agents.
• Detection scripts using IntersectionObserver and event listeners help identify the underlying mechanisms driving each interaction.

Frequently Asked Questions

What is the difference between scroll-driven and click-driven interaction models?

Scroll-driven models trigger visual changes automatically as the user moves through the viewport, typically using IntersectionObserver, position: sticky, or CSS scroll timelines. Click-driven models require explicit user interaction with buttons, tabs, or cards to initiate state changes. The detection process identifies which mechanism powers each section to ensure builder agents generate the correct JavaScript or CSS implementation.

Why must the scroll sweep come before the click sweep?

The sequential order prevents the "most expensive mistake" identified in the workflow documentation: misclassifying a scroll-driven component as click-driven (or vice versa) forces a complete rewrite of the component architecture. Scroll behaviors require different libraries and CSS configurations than click handlers, and correcting this error after component generation wastes significant development cycles.

How are interaction models recorded for builder agents?

Detected models are written into markdown specification files under docs/research/components/ using standardized tags like INTERACTION MODEL: scroll-driven with IntersectionObserver. These specs include trigger thresholds, animation descriptions, and asset references. Builder agents parse these files to determine whether to import scroll-behaviour libraries like Lenis in src/app/layout.tsx or implement React state management for click interactions.

What tools are needed to perform interaction model detection?

The process requires a browser console for running detection scripts and viewport resizing capabilities to test responsive breakpoints at 1440px, 768px, and 390px. The repository provides specific JavaScript snippets to log scroll-driven entries, click events, and hover states. No external software is required beyond the standard browser developer tools used during the reconnaissance phase.

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