Browser Replay

Replays a recorded browser session trajectory against the original URL or a modified variant, using embedding similarity on selectors to recover when the DOM has drifted. You'd reach for this when regression testing a UI flow after a deploy, reproducing a captured bug, or preparing a visual diff between two runs. The architecture bets heavily on selector recovery since Browserbase doesn't offer native replay. It defaults to an 85% step match threshold before declaring failure, which is aggressive but honest about the nondeterminism you'll hit with timing and content variation. If you need more than one retry per step, the site probably needs a fresh recording rather than another replay attempt.

skills.sh installs: 721
GitHub stars: 81.4K
last updated: Aug 21, 2026

View on GitHub

Install

$ npx -y skills add ruvnet/ruflo --skill browser-replay --agent claude-code

Installs into .claude/skills of the current project.

Files

Browser Replay

Re-drive a recorded session trajectory. Used for regression testing, deterministic re-runs, and as the verification path that browser-record plus browser-selectors actually produces something replayable.

This skill is the load-bearing assumption of the v0.2.0 architecture. ADR-0001 Verification §4 requires ≥80% replay success across 10 distinct sites of varying drift profiles before the proposal moves from Proposed → Accepted. If you find replay unreliable, capture the failure modes in findings.md and report them up the ADR.

When to use

Regression-testing a UI flow after a deploy.
Reproducing a bug captured in a prior session.
Comparing two runs of the same flow for browser-screenshot-diff.
Forking a session (/ruflo-browser fork) and replaying the parent before mutating.