Scroll-Driven Page Builder

---
name: scroll-driven-page-builder
description: Use when a page should behave like an experience rather than a document, and scroll is the input driving it. Triggers on "scrollytelling", "scroll animation site", "a site where scrolling plays a video", "Apple-style landing page", "make this feel like an experience", "this looks like a template", "pinned sections", "make our brand a scroll story". Not for a standard marketing page, not for route transitions, and not for an accessibility pass.
---

# Scroll-Driven Page Builder

Scroll is the only input every visitor already knows how to use. Treated as a timeline, the wheel becomes a scrubber, the page becomes a film with real text on top, and each section behaves differently enough that the visitor keeps going to find out what the next one does.

The failure this exists to prevent is the opposite of ugly. It is the page where one device gets applied to the whole document: the same flythrough, the same centred copy, the same section counter, the same nudge to scroll. Five sections that behave identically are one section shown five times.

## Interview before generating anything

A page built from assumptions comes back looking like the last page built from assumptions. Ask, get answers, write them down. Eight questions in one pass:

1. The vibe in three to five words, plus up to three references **from any medium**. A film, an album cover, a shop, a magazine. Do not ask which websites they like, because naming sites is how the page ends up looking like an existing site.
2. The scroll journey section by section, in their sequence, not from a menu you offered.
3. The energy curve. Where it should feel calm, where it should feel intense. Loud the whole way is as flat as quiet the whole way.
4. How the visitor should feel stage by stage, and the one moment they should remember. Energy is loudness and this is emotion; on a loud page the quiet act is often the most intense.
5. One thing this site should do that no site they have seen does. This is the seed of the signature move, and "be memorable" is not an answer.
6. How far from premium-minimal they want to go: brutalist, maximalist, playful, retro, dense, editorial. Their answer governs the aesthetic family, not your taste.
7. One unbroken world, or distinct scenes? This is the largest structural fork and it is their call, not a device chosen later. Offer both plainly; neither is the default.
8. What assets already exist. Footage, product shots, brand kit. Real assets anchor the world and remove generation cost, and "nothing" is a fine answer.

Write the answers verbatim into a brief file, in their words rather than paraphrased into marketing prose. Everything downstream reads from that file. If the run is genuinely autonomous with no human reachable, author the brief yourself, mark it as self-authored at the top, and say so in the final report.

## The journey comes before the assets

Four to seven beats, each one a shift in what the visitor knows or feels. Recognition, then tension, then the turn, then substance, then range, then commitment is one shape among several, not a template to reuse.

Beats are the spine. A section that serves no beat gets cut however good the shot is. Settle the journey with the user before generating a single asset, because assets are the expensive part and the journey decides every one of them.

## Grammar, uniqueness gate, then score

Three things in order, all before act planning.

**Pick a page grammar and commit to it.** Grammars are mutually exclusive because each forbids what the others require: a continuous filmic one-shot, a chaptered sequence, a printed editorial spread, a live responsive surface, and so on. Whichever one the last build used is the one to justify hardest. Navigation, hero, and close all follow from the grammar rather than being decided separately.

**Invent one signature move.** A single bespoke interaction that lives on this page alone, written as page-level code. A recoloured spotlight or a retuned tilt on an existing device is a parameter change, not a signature move.

**Run a fingerprint check against your previous builds.** Keep a short registry with one row per shipped page recording six dimensions: grammar, navigation treatment, hero device, act-sequence shape, close pattern, and signature move. A new plan must differ from **every** existing row on at least four of the six. When it fails, change the plan rather than the registry. Total page length and act count belong in the check too, because a studio that always lands on six acts at the same viewport height has a fingerprint whether it meant to or not.

**Write the feeling curve before the score table.** One line per act: the emotion, then what on screen causes it. Curve first, devices second, because a device chosen before the feeling is a device looking for a reason. Two adjacent acts carrying the same feeling means one of them is filler, and cutting it now is far cheaper than cutting it after the assets exist. Name the peak in the same pass and give it the largest scroll span on the page.

Only then assign a device to each beat and write it down as a table with a third column saying why that device and not another. Video scrubbing under the wheel, pinning with copy assembling line by line, a wipe reveal that reads as a change of state, lateral panning that reads as options where vertical reads as argument, pointer-driven response once the page stops moving.

Check the score before building:

- Four or more distinct device families, or the page has one idea.
- No device family twice in a row.
- At most two scrub acts. Video is the heaviest thing on the page and the third one stops being a surprise.
- One peak with the largest span by a visible margin, and a quieter act immediately before it.
- Every act earns its scroll span. Eight to fourteen viewport heights in total. Longer is slower rather than more immersive.

## Build real markup

Real headings, real paragraphs, real links, real reading order, with the scroll behaviour driven off data attributes on that markup. A runtime that generates the DOM from a configuration object is precisely why every site built on one looks the same.

Theme through tokens rather than per-component overrides: two surface colours, two ink colours, an accent and its contrast pair, one display face and one text face. That constraint is what keeps six separately produced assets reading as one shoot.

When assets are generated rather than shot, write one style preamble and reuse it verbatim in every prompt, never paraphrased. Look at every generated frame before using it. Encode video for **seeking rather than playback**: a normal web encode plays perfectly and scrubs like mud, because seeking walks forward from the previous keyframe, so the clip needs a dense keyframe interval.

## Verify by scrolling it, not by looking at it

A scroll page has no single state. Every position is a different frame and the failures live between the two positions you happened to check.

Drive a headless browser through each act at several scroll positions, waiting for the scrubbed video to settle before each capture, at desktop width, at phone width, and once with reduced motion requested. Hunt for three machine-detectable failures: **dead scroll**, where a range of the page changes nothing; **cues that never reach full opacity**, where copy fades in and stops half-arrived; and **contrast measured on the composited page at the brightest frame under each line**, which is the only measurement that means anything over moving video.

Then do the part the harness cannot. Read the contact sheet: it proves the clip advanced, and it cannot tell you the composition is good or the page means anything. Tab through for focus order. Scroll it cold and write one word per act for what you felt, then open the brief and diff that against the intended curve. Where the two disagree, the page is wrong rather than the brief.

Say what a green run does not cover. Headless Chrome cannot reproduce a phone video decoder, an autoplay policy, low power mode, or touch scrolling, so a page can pass every automated round with the hero clip frozen on the actual device. Treat mobile as a target throughout rather than a pass at the end: portrait clips authored separately, touch-tuned easing, tap targets grown. When a device-only defect is reported, put a diagnostic page next to the site on the first round and let the device answer instead of theorising from a machine that cannot reproduce it.

## Ship blockers

| Never | Instead |
|---|---|
| A scroll cue, arrow, or animated mouse icon | Nothing. They are looking at the hero and they know |
| Section counters reading 01 / 06 | Delete them. Sequence is not information here |
| An eyebrow label above every section heading | At most one per three sections |
| Centred copy in every act | Vary the anchor: lead, trail, centre, split |
| The same device twice in a row | Score the journey properly first |
| Soft low-poly clay diorama as the default world | Photographic, unless the brand is genuinely illustrated |
| Text baked into a generated image | Real markup. It is selectable, translatable, and sharp |
| Invented statistics in a counter | Only real numbers. No number, no counter |
| A full-frame dark overlay to fix contrast | A scrim only where the text sits |
| Gradient text, neon glow, zero-offset coloured halo shadows | Weight and size for emphasis; shadows with real offset and blur |
| Animating width, height, top, or left, or using a catch-all transition | Transform and opacity, with clip-path for wipes |
| Audio on a scrubbed clip | Strip the track at encode |
| An ending that fades out or simply becomes a footer | The close resolves and holds. The last feeling is the one they carry |
| Shipping without the scroll verification pass | Run it |

## Deliverable

The page, plus a short report: the grammar and why the alternatives lost, the signature move, the fingerprint result against each previous build, the journey, the feeling curve and its peak, the diff between the intended curve and what you felt scrolling it cold, the device-per-beat table, what was generated, what the screenshots verified, and what could not be verified without a real device. Then append this build to the fingerprint registry, because the next page has to differ from it.