The first version of Motion Replication Kit treated the problem a little like spot the difference.
Capture the initial page. Scroll. Capture it again. Put the two images next to each other. The heading moved up, the cards appeared, and the background changed position. That looked like enough evidence to start guessing opacity, translateY, and a plausible duration.
It was enough evidence for two poses.
It said almost nothing about the part in between. Did the element settle in 300 milliseconds, or was it coupled to scroll progress? Did opacity change before movement? Were five cards simultaneous or staggered? Was that final position the end of an animation, or was the whole section pinned there?
A recreation can match both endpoints and still feel completely wrong in motion. It feels a little like trying to remake a film from two stills.
The judgment behind the kit became much simpler after that: motion replication is an evidence problem before it is a GSAP, CSS, or Motion problem.
Put time back into the third frame
The early capture flow kept initial.png and scrolled.png. Those files were useful. They answered spatial questions: what was visible before scrolling, where an element ended up, and whether the page shifted in an obvious way.
The project's own early PRD also recorded the boundary. Two fixed states could not explain scrubbed, pinned, or multi-stage scroll behavior. A screenshot could not expose duration or easing at all.
The next version did not search for a smarter screenshot. It separated the evidence.
The current default samples five points across the scroll distance and saves a filmstrip. A Playwright trace preserves what happened in the browser. Video can retain continuous feel when the filmstrip leaves a gap. The original before-and-after images remain for compatibility and fast spatial comparison.
These artifacts are not redundant copies of the same truth.
Screenshots preserve space. A filmstrip preserves order. Video preserves continuity. A trace lets me return to browser events and timelines when the visual result is ambiguous. They overlap, but no single one explains the motion on its own.
This is why I am skeptical of the claim that an agent can recreate web motion from one reference image. It may produce a reasonable entrance animation. Reasonable is not the same as observed, and neither is the same as verified.
Every inference needs a way back
More frames still do not justify generating code immediately.
At each sample, the kit records candidate positions, dimensions, opacity, and transforms. It also inspects transitions, animations, native scroll timelines, and timing data exposed through the Web Animations API: duration, delay, easing, play state, and timeline type. A pure Node inference layer then turns the samples into candidate explanations such as fade-up, slide-in, scale-in, or a possible stagger group.
The important design choice is not how many patterns the tool can name. It is the suffix attached to every inferred field in the draft brief: (inferred — verify).
I want that phrase to remain slightly annoying.
Timing returned by the browser is an observation. Movement calculated from five rectangles is an inference. A class name containing motion is only a clue. Flatten those categories into one confident result and the next agent starts precise implementation on top of a guess.
I would rather preserve an empty field than manufacture a convincing number. Guessing a duration badly may only damage the feel. Mistaking scroll-linked behavior for a one-shot reveal changes the entire interaction.
Map the behavior onto owned components
A stronger evidence trail creates another temptation. If the reference page is already open, why not take its CSS, structure, and assets too?
The kit draws the boundary in the opposite place. A captured page is untrusted evidence. Its motion behavior can be studied. Its copy, imagery, brand assets, routes, and page structure cannot be copied. The rebuild uses neutral names and local data attributes, then maps the observed behavior onto components owned by the target project.
This constraint forces a better question: what behavior does the new project actually need to preserve?
A simple viewport reveal may need only CSS transitions and IntersectionObserver. Scroll progress without JavaScript can use native scroll-driven animation as progressive enhancement. GSAP and ScrollTrigger become justified when the evidence shows a real timeline, pin, scrub, or complex sequence.
A more capable technique is not automatically a more faithful one. Turning a 200-millisecond fade into a scrubbed master timeline only makes a small behavior more expensive to maintain.
The kit therefore does not translate "GSAP detected" into "install GSAP." A detected library is evidence about the source, not an implementation order. The final choice depends on behavior complexity, existing target dependencies, browser support, and the reduced-motion path.
Run the page again with reduced motion
Many recreation attempts stop when the default animation looks close. The kit keeps the work going a little longer.
Every animation needs a prefers-reduced-motion branch. Setting duration to zero is not sufficient if opacity or transforms leave the content hidden. Reduced mode must preserve the final visible state.
Capture can run a second reduced-motion pass. The comparison tool classifies the reference as honoring, ignoring, mixing, or providing insufficient evidence for the preference. That comparison intentionally reasons over JSON activity signals rather than decoding PNG pixels inside the zero-dependency runtime. Pixel regression belongs in the target project's Playwright screenshot gate, where the browser tooling already exists.
Performance has the same boundary. The templates can observe long tasks and CLS during a stepped scroll and apply project-specific budgets. Those starting thresholds are not proof that a recreation performs well. They are a gate against buying visual similarity with main-thread blocking or layout movement.
"Looks close" can then be challenged with narrower questions. Is the sequence correct in default mode? Is every required element visible with reduced motion? Does the filmstrip retain the key phases? Did the scroll produce long tasks or layout shift?
I stop at the third frame
I reran the current repository tests while writing this article. Five passed, with no failures and no skips. They cover the capture baseline, several inference patterns, stagger detection, the verification suffix, and the MCP surface.
That result proves the workflow ran on this machine. It does not prove the kit understands all web motion. There is no dataset supporting that claim, and five green checks cannot invent one.
Motion Replication Kit now feels less like an animation generator and more like a small forensic workflow shared by a person and an agent. It saves states and records time. Candidate explanations go back to the filmstrip or video for review. The implementation then passes through reduced-motion, visual, and performance gates.
My final check is now very specific: open the filmstrip and stop at frame three. Can it show whether the element is still transitioning, already pinned, or coupled to scroll progress?
If the answer is still unknown, the implementation brief stays empty. Add video when continuity is missing. Return to the trace when the browser timeline is unclear. If frame three does not hold up, the code waits.