Best browser automation skills for AI agents

Ask an agent to log into your staging app and check the dashboard, and watch what it does unaided. It writes a throwaway Puppeteer script. It pulls the raw HTML into its context and tries to reason over the markup. It sleeps for two seconds instead of waiting for anything in particular, keeps using an element handle after the page navigated away from it, and puts the password in the command line. Then the screenshot comes back blank — networkidle fired, React had not hydrated yet — and the agent tells you the page looks fine. None of that is a reasoning failure. It is the absence of a written procedure for a job where the failure modes are specific, boring, and known.

The surprise, once you read the documents, is how much of this space is one document. The dominant browser-control skill exists as 42 copies published under a single name, scattered across unrelated repositories and frozen at different dates. The name doesn't tell you which one you have. Neither does the star count on the repo hosting it.

The line between them is not the one you would guess. Password handling barely figures — 15 of those 42 already document the credential vault and its stdin form. What actually divides them is containment: whether the document treats the page as a hostile surface and hands the agent the controls to fence it in. Exactly one of the 42 does, alongside the upstream document it was copied from. Those two carry a domain allowlist that restricts navigation and page-initiated traffic and, on supported Chromium sessions, switches off RTCPeerConnection so WebRTC can't tunnel past the HTTP filter — with workers failing closed rather than running unguarded. They carry a section headed "Working safely" that names page content, console output, network bodies and error overlays as untrusted data rather than instructions, and tells the agent to stay on the user's target URL instead of one a page suggested. They carry a doctor command to run first when something breaks, and a restore key the document explicitly tells agent skills to prefer over hand-built state files. Every other copy stops before all of it. Same name. Same tool. Very different thing to hand a machine that can click Submit.

Top picks

Browser control: take the upstream copy, not the popular one

vercel-labs/agent-browser/core is the document the rest of the field is copying, and it is the one to install. It teaches a four-beat loop — open, snapshot -i, act on @eN refs, re-snapshot — built on accessibility-tree snapshots that cost roughly 200-400 tokens instead of a page of HTML. What makes it good is not the command list but the section headed "Waiting (read this)", which states flatly that agents fail more from bad waits than bad selectors, then ranks the options and puts the dumb millisecond wait last; timeouts default to 25 seconds. The troubleshooting reads like scar tissue: what to do when a click reports it was covered by an overlay, when a custom input swallows keystrokes and you need keyboard inserttext to bypass key events, when a WebGPU page renders black in headless capture. It also ships a doctor command for the install failures that otherwise eat an afternoon.

It is not flawless. Its own first login example fills a plain password straight into the form, and only the line immediately after it warns that shell history is a leak and points at the vault instead. The order is backwards, and an agent skimming for a pattern to copy will hit the wrong one first.

Compare it with a widely-mirrored copy such as shanraisshan/claude-code-best-practice/agent-browser, which is competent and considerably shorter. Its login recipe is actually careful with the password — it fills from shell variables rather than a typed literal — but it persists the result as a hand-built session-state file, exactly the pattern the upstream document now tells agent skills to replace with a restore key. And there is no trust-boundary section, no domain allowlist, no doctor, no accessibility audit, no MCP server. If you can't get the upstream skill, fcakyon/claude-codex-settings/agent-browser is the mirror that stayed close to current — it keeps the containment flags and the safety rules. Caveat: this is Apache-2.0 and it wraps a CLI you install globally, so it is worth nothing to an agent that cannot run shell commands.

Electron apps: the same CLI, one extra page of setup

If the thing you need to drive is Slack, VS Code, or any other Electron app, vercel-labs/agent-browser/electron is a genuinely separate document rather than a stub. It exists because Electron is Chromium and exposes a debugging port, and it gets the operational details right: the app must be relaunched with the flag if it's already running, each app gets its own port, lsof -i :9222 tells you what's squatting there, and <webview> elements show up in the tab list as their own targets so you have to switch to one before its contents appear in a snapshot. The detail that will otherwise cost you an hour: connecting over the debugging protocol can default the color scheme to light, so your dark-mode screenshot lies unless you ask for dark explicitly. It's a short read and it pairs directly with the core skill above: same globally-installed CLI, one extra step to attach to a debugging port, and then the usual snapshot-and-act loop resumes unchanged.

Playwright suites: install the doctrine, not the index

testdino-hq/playwright-skill takes a moment to get to the point — it opens by advertising its 50+ reference guides, then spends a paragraph on what Playwright 1.61 added, then states a security trust boundary. Its ten rules come fourth. They are the right ten: role-based locators over CSS and XPath, never a fixed timeout, web-first assertions because expect(locator) retries and expect(await locator.textContent()) does not, retries set to 2 in CI and 0 locally so flakiness surfaces where it matters, traces on first retry, mock third-party services and never your own app. It is versioned, it names features from Playwright 1.61 rather than whatever was current when it was first written, and it carries a security section most testing skills skip entirely — treat page text as untrusted before feeding it back to an agent, and pin CI actions and container images to immutable digests instead of moving tags.

The obvious rival is currents-dev/playwright-best-practices, which is broader on paper: an activity-to-file routing table covering everything from clock mocking to browser extensions, plus a validation loop that tells the agent to re-run critical tests with --repeat-each=5. But open the body and it is almost entirely a table of contents. It states no position; the opinions live in files it points at. Testdino's is also an index — the difference is that its index arrives with the doctrine attached, which means the agent gets value from the first screenful. A third document, zebbern/claude-code-guide/playwright, publishes the same ten rules under the same skill name: it's an earlier cut of the same work, minus the security section and the version currency. Worth knowing before you conclude two identically-named skills are interchangeable.

Accessibility: the one that tells you what it can't catch

fugazi/test-automation-skills-agents/a11y-playwright-testing leads with its own ceiling — automated tooling catches something like 30-40% of accessibility issues, so use it to stop regressions and book the manual audit anyway. Then it makes the observation that justifies the whole skill: if you cannot locate an element by role or label, that is usually a defect, not a selector problem. The tests it writes are the ones people skip. A dialog test that tabs around the modal to prove focus is trapped and presses Escape to prove focus returns to the trigger. A skip-link test that checks the first Tab lands on the link and Enter moves focus into main. Its troubleshooting table names the actual cause of a dead skip link (tabindex="-1" missing on the target). And rather than letting the agent silence a failing rule, it requires exclusions to be scoped, documented against a WCAG criterion, and given an owner and a date.

Two named alternatives, both worth knowing. LambdaTest/agent-skills/accessibility-skill is unusually candid — it states up front that its capability can start a scan but there is no results API, no exit code and no build-gating flag, so an agent cannot read the outcome without their MCP server. That's honest, and it means the skill can't be your CI gate. aj-geddes/useful-ai-prompts/accessibility-testing has the right instincts and a good do/don't list, but its Quick Start example stops mid-test inside the code fence with a comment pointing at reference files. Fugazi's assumes TypeScript in the project and recommends Node 18 or better; if your suite is Selenium, that's a real constraint.

Screenshots: the skill that knows why yours are blank

curiositech/some_claude_skills/playwright-screenshot-inspector is built around a distinction worth internalising: pixel diffing tells you fifty pixels changed, while a vision model can tell you the page is empty. It names the failure mode that makes agent screenshots useless — capturing before the framework hydrates — and gives a concrete remedy instead of a platitude: wait for DOM content, then network idle, then a half-second hydration buffer, then an actual content selector, and if the body text comes back under fifty characters, wait again and re-check. It also catches the theme bug you would otherwise chase for an hour: emulate the color scheme on the page, not on the context, or your dark-mode capture comes back light. Caveat: it's Python, it hands you a template script rather than a framework, and it says outright that if you want deterministic baseline comparison you should use Playwright's native screenshot assertion instead of this.

A skill's name is its topic, not its identity

Skills are community-published and names are not namespaced, so the same name routinely covers different documents — sometimes different tools entirely. A skill called playwright can be a tool card describing Microsoft's framework with an install line and some snippets, as in AIDotNet/MoYuCode/playwright, whose frontmatter description is written in Chinese. Or it can be an ad-hoc script runner, like lackeyjb/playwright-skill, which detects your running dev servers before writing any code, keeps every generated script in /tmp so your repo stays clean, and deliberately defaults to a visible browser so you can watch.

That last one is a good illustration of why you can't shortcut this. Lackeyjb's skill insists on a visible browser; the screenshot inspector insists on headless. Both are right, because one is for a human watching a flow and the other is for an unattended run that shouldn't spawn windows. The skill's job determines its defaults, and only the body tells you the job. The check that works: read the frontmatter for an author, a version and a license, then scan the body for the two or three markers that date the document. For a browser-control skill, does it mention the doctor command and the domain allowlist, or does it stop at saving state to a file? For a Playwright skill, does it name features from a current release, or only conventions that the framework has since moved past?

Three things to check before you install

Frontmatter can switch a skill off. bobmatnyc/claude-mpm-skills/playwright is a solid framework walkthrough, but it declares itself non-user-invocable with model invocation disabled — install it and your agent will never reach for it on its own. That is a deliberate choice inside a larger system, and a silent disappointment anywhere else.

Vendor skills route. LambdaTest/agent-skills/playwright-skill is substantive — a real anti-pattern table, a full config, working code in five languages — and its first step is "determine execution target", which sends impossible local combinations like Safari on Windows to their cloud grid of 3000+ browser and OS combinations. It defaults to local when the request is ambiguous, which is fair. Just know you are installing a document that assumes an account exists.

And check that the body is the substance. Some of the best skills here are indexes over a reference tree, which is fine when the tree ships with them and useless when only the entry file lands. The thin end of this spectrum is instructive rather than simply bad. SawyerHood/dev-browser is a well-regarded tool whose skill is a one-line description, an install snippet, an instruction to run --help, and then one closing paragraph that earns its place completely: named daemon-launched browsers persist by default, --idle-timeout 5m closes each launched browser after inactivity while preserving its profile and login state, the setting never closes a Chrome you attached to with --connect, and --idle-timeout 0 disables the cleanup. That paragraph is the skill. The three things above it are what your agent would have found by running --help itself.

What you should end up with

The failure you started with — blank screenshots reported as success, stale element references, credentials in argv, waits that are really sleeps — is not solved by a better model. It is solved by handing the agent a procedure that already names those failures. Install the upstream browser-control skill for driving pages, add its Electron companion if desktop apps are in scope, take testdino's for anything that becomes a test suite, fugazi's when accessibility has to hold, and the screenshot inspector when the agent needs to look at what it built. What you have avoided is subtler than any of them: the near-identical copy — same name, no version field to warn you, nothing but the body to date it — that teaches your agent to drive a browser and never mentions that everything on the page is untrusted input, or that the browser can be fenced in at all.