New to Claude Skills? Learn how to install them →

ruvnet on GitHub

Browser Replay

Free

Replay recorded browser sessions for testing and verification.

by ruvnet67.6k stars on ruvnet/ruflo
Updated Aug 10, 2026
Get this skill

Free · Opens the source repo

What Browser Replay does

Browser Replay is a specialized tool designed for developers and testers who need to validate UI flows after deployments or reproduce bugs captured in previous sessions. By re-driving a recorded session trajectory, this skill ensures that the actions taken during a prior session can be accurately replicated, making it invaluable for regression testing and quality assurance. It leverages browser selectors that embed similarity to recover from DOM drift, which is a common issue when web applications undergo changes.

The skill operates by allowing users to load a recorded session trajectory and execute the actions in a fresh browser instance. It provides a structured approach to replaying user interactions, including clicking, filling forms, and evaluating scripts. If a selector fails to match during replay, the tool intelligently queries a namespace for an embedding-similar selector, allowing for a retry without failing the entire process immediately. This feature is crucial for maintaining the reliability of tests, especially on sites that frequently change.

Browser Replay is particularly useful in scenarios where consistency and accuracy are paramount, such as in automated testing environments. It supports regression testing, enabling teams to ensure that new code changes do not introduce bugs into existing functionality. Additionally, it can be used to compare different runs of the same session for visual differences, enhancing the testing process further.

However, users should be aware of certain limitations. The skill does not support playback on heavily drifted sites, as it relies on selector embedding recovery, which may introduce noise. Furthermore, network nondeterminism can lead to false failures, so users are encouraged to utilize the --mutate option for expected variations. Understanding these caveats will help users effectively integrate Browser Replay into their testing workflows.

When to use it

Use this skill for regression testing after deployments or when reproducing bugs captured in earlier sessions.

When not to use it

It may not be suitable for heavily drifted websites or scenarios requiring high network determinism, as it might produce false-fail verdicts.

What you can build with it

Regression Testing After Deployment

Use Browser Replay to ensure that new changes do not break existing functionality by replaying recorded sessions.

Bug Reproduction

Quickly reproduce a bug by replaying the session where it was originally captured, ensuring accurate debugging.

Visual Comparison of Session Runs

Compare two runs of the same flow visually by using Browser Replay in conjunction with screenshot diffing tools.

How to install Browser Replay

View source

1. Install with the skills CLI

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

2. Or install it manually

Download the skill folder and drop it into ~/.claude/skills/ for all projects, or .claude/skills/ to scope it to one repo. Restart Claude Code so it picks up the new skill.

Anthropic's agentic coding CLI, and the reference implementation of Agent Skills. Drop a skill folder into ~/.claude/skills and Claude Code loads it automatically whenever a task matches the skill's description. Claude Code docs

Inside SKILL.md

Written by ruvnet

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 ProposedAccepted. 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.

Steps

  1. Locate the source session:
    npx -y ruvector@0.2.25 rvf status <session-id>.rvf
    
  2. Load the trajectory:
    Read .../trajectory.ndjson
    
    Each line is {ts, action, args, selector, result}.
  3. Open a fresh browser via mcp__plugin_ruflo-core_ruflo__browser_open (target URL = original or --url override).
  4. For each trajectory step, dispatch the matching MCP tool (browser_click, browser_fill, browser_eval, etc.) with the recorded args.
  5. On selector miss, do not fail immediately — query the browser-selectors namespace for an embedding-similar selector for the same <host>:<intent> and retry once:
    npx -y @claude-flow/cli@latest memory search --namespace browser-selectors \
      --query "<host> <intent>" --limit 5
    
  6. Record a new trajectory for the replay run (allocate a fresh RVF container, lineage-tracked via rvf derive).
  7. Verdict: tally matched-step / total-step ratio. Default tolerance threshold is 0.85 (configurable via --tolerance). Verdict goes into findings.md.

Caveats

  • Browserbase explicitly does not offer replay (rrweb session replay was deprecated). We're betting on selector-embedding recovery; expect noise on heavily drifted sites.
  • Network nondeterminism (timing, content variation) can produce false-fail verdicts. Use --mutate to inject expected variation or pin to a fixture.
  • For visual diff, chain into browser-screenshot-diff against the parent session id.
  • If selector recovery requires more than one retry per step, log it. That's the signal that the site needs a re-record, not a replay.

Frequently asked questions about Browser Replay

Similar skills