Browser Replay
- 627 installs
- 67k repo stars
- Updated August 4, 2026
- ruvnet/ruflo
browser-replay is a ruflo Claude Code skill that replays recorded browser session trajectories against the same or mutated URLs, using browser-selectors embedding similarity to recover from DOM drift during UI testing.
About
browser-replay is a Testing & QA skill in ruvnet/ruflo that replays recorded session trajectories against a target URL or a mutated variant. The skill uses browser-selectors embedding similarity to recover when DOM structure drifts between recording and replay, reducing brittle selector failures during regression runs. Developers reach for browser-replay when validating recorded user flows after UI refactors, testing against staging variants, or automating click, fill, type, and navigation sequences captured in a prior session. It integrates with claude-flow browser MCP tools including click, fill, screenshot, and wait operations, accepting session-id, url, mutate JSON, and tolerance parameters.
- browser-replay
Browser Replay by the numbers
- 627 all-time installs (skills.sh)
- +6 installs in the week ending Aug 5, 2026 (Skillselion tracking)
- Ranked #610 of 4,347 Backend & APIs skills by installs in the Skillselion catalog
- Data as of Aug 5, 2026 (Skillselion catalog sync)
npx skills add https://github.com/ruvnet/ruflo --skill browser-replayAdd your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| Installs | 627 |
|---|---|
| repo stars | ★ 67k |
| Last updated | August 4, 2026 |
| Repository | ruvnet/ruflo ↗ |
How do you replay recorded browser sessions after DOM changes?
Use browser-replay for development tasks
Who is it for?
Developers regression-testing recorded UI flows who need DOM-drift tolerance instead of brittle fixed selectors.
Skip if: Teams without recorded session trajectories or projects that only need one-off manual browser checks.
When should I use this skill?
User wants to replay a recorded browser session, test UI flows after DOM changes, or validate trajectories against a mutated URL.
What you get
Replayed browser session results, DOM-drift recovery logs, and screenshots from trajectory validation
- Replay execution report
- DOM recovery logs
- Browser screenshots
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 fromProposed→Accepted. If you find replay unreliable, capture the failure modes infindings.mdand 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>.rvf2. Load the trajectory:
Read .../trajectory.ndjsonEach line is {ts, action, args, selector, result}. 3. Open a fresh browser via mcp__claude-flow__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 56. 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
--mutateto inject expected variation or pin to a fixture. - For visual diff, chain into
browser-screenshot-diffagainst 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.
Related skills
Lark Openapi ExplorerInstantly explore, test, and generate calls against the full Lark (Feishu) OpenAPI surface without leaving their agent workflow.493k
Lark EventConsume real-time events from Lark/Feishu as structured NDJSON streams inside AI agent workflows.387k16kLark Openapi ExplorerWhen an existing Lark/Feishu skill or CLI command cannot fulfill a specific requirement and they need to discover and invoke the exact native OpenAPI endpoint.386k16k
Just ScrapeQuickly search, crawl, extract structured JSON, or monitor web pages without writing custom scraping code.245k41Lark AppsQuery the current visibility and permission scope of a Lark (Feishu) app without writing HTTP client code.235k16k
Design An InterfaceGenerate multiple radically different interface or API designs in parallel before committing to one.188k198kFAQ
How does browser-replay handle DOM changes?
browser-replay uses browser-selectors embedding similarity to match elements when DOM structure drifts between recording and replay. The --tolerance flag accepts values from 0 to 1 to control matching strictness.
What arguments does browser-replay accept?
browser-replay accepts a session-id plus optional --url for a new target, --mutate JSON for variant testing, and --tolerance between 0 and 1. It drives claude-flow browser MCP tools for clicks, fills, and screenshots.