Browser Test
- 665 installs
- 67k repo stars
- Updated August 4, 2026
- ruvnet/ruflo
browser-test is a ruflo agent skill that composes browser-record capture and browser-replay verification so every UI test produces a replayable RVF artifact instead of an ephemeral browser run.
About
browser-test is a UI test recipe skill from ruvnet/ruflo that chains browser-record for capture with browser-replay for verification through Claude Flow browser MCP tools. Each test run produces a replayable RVF artifact rather than a one-off ephemeral session, supporting arguments like a target URL, optional screenshots, and comparison against a prior session ID. The skill exposes click, fill, type, select, hover, wait, screenshot, and snapshot actions via mcp__claude-flow__browser_* tools. Developers reach for browser-test when they need reproducible agent-driven UI tests with recorded sessions they can replay and diff across builds.
- browser-test
Browser Test by the numbers
- 665 all-time installs (skills.sh)
- +7 installs in the week ending Aug 5, 2026 (Skillselion tracking)
- Ranked #556 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-testAdd your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| Installs | 665 |
|---|---|
| repo stars | ★ 67k |
| Last updated | August 4, 2026 |
| Repository | ruvnet/ruflo ↗ |
How do you create replayable browser UI tests?
Use browser-test for development tasks
Who is it for?
Developers using ruflo and Claude Flow who need agent-driven UI tests with recorded, replayable RVF sessions instead of manual QA clicks.
Skip if: Unit tests without a browser, load testing at scale, or teams not running Claude Flow browser MCP tooling.
When should I use this skill?
A developer needs to capture, replay, or verify UI flows in a browser and persist tests as RVF artifacts rather than ephemeral runs.
What you get
RVF replay artifacts, browser session recordings, screenshot captures, and replay verification results against prior session IDs.
- RVF replay artifact
- Browser session recording
- Screenshot and replay diff report
Files
Browser Test
Automated UI testing. Now backed by a recorded RVF session container instead of an ephemeral run, so every test produces a replayable artifact.
When to use
- Verifying UI functionality, user flows, or that frontend changes work in a real browser.
- Producing a baseline session that future regressions can diff against.
- Re-running a stored test session when CI fails (no need to re-author the test).
Steps
1. Record the test run by composing browser-record:
- Allocates an RVF container with
--kind browser-session. - Begins a ruvector trajectory.
2. Drive interactions — browser_open, browser_click, browser_fill, browser_type, browser_select. Each action emits a trajectory-step. 3. Wait for elements / network idle via browser_wait before assertions. 4. Validate with browser_get-text / browser_get-value / browser_get-title / browser_get-url. Validation outcomes go into findings.md inside the RVF container. 5. Screenshot before / after key interactions for visual regression. Filenames follow <step-id>.png. 6. Snapshot the accessibility tree at navigation boundaries. 7. End the session: trajectory-end --verdict pass|fail, rvf compact, AgentDB index in browser-sessions. 8. (Optional) Diff against `--against <prior-session-id>`: invoke browser-screenshot-diff to compare the new run with a baseline.
Navigation
browser_back/browser_forwardfor history navigationbrowser_reloadto refresh the pagebrowser_scrollto scroll to elements or coordinates
What changed from v0.1.0
- The skill no longer ends with
browser_closealone — it ends with the session-end protocol. - Selectors discovered during the test land in
browser-selectors(host:intent), so the next test can find them by embedding similarity. - Validation outputs pass
aidefence_is_safebefore any LLM-facing summary; injection-flagged content is quarantined tofindings.md. - The same skill, used in CI, now produces an artifact that
/ruflo-browser replaycan re-drive.
Tips
- Use
browser_waitbefore assertions to handle async rendering. - For visual regression, save the parent session id and pass
--against <id>on the next run. - Use
browser_evalfor custom JavaScript assertions — but redact any returned strings via theaidefence_is_safegate before logging.
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
What makes browser-test different from a normal browser run?
browser-test composes browser-record and browser-replay so each UI test saves a replayable RVF artifact. Developers can re-run or diff against a prior session ID instead of losing ephemeral browser automation output.
Which tools does browser-test use?
browser-test drives Claude Flow browser MCP tools including browser_open, browser_click, browser_fill, browser_snapshot, browser_screenshot, and browser_wait, chained through the ruflo browser-record and browser-replay skills.