
Browser Automation
Reliable Playwright- or Puppeteer-based browser flows for E2E tests, scraping, and agent-driven web interactions without flaky waits or brittle selectors.
Overview
Browser automation is an agent skill most often used in Ship (also Build integrations) that teaches Playwright- and Puppeteer patterns for reliable E2E testing, scraping, and agentic browser control.
Install
npx skills add https://github.com/sickn33/antigravity-awesome-skills --skill browser-automationWhat is this skill?
- Recommends Playwright over Puppeteer unless you need stealth Chrome-only ecosystems
- User-facing locators (getByRole, getByText) and auto-wait instead of manual sleeps
- Splits testing automation (apps you control) from scraping and anti-detection agent flows
- Isolated contexts per task, headed vs headless guidance, and trace-first debugging
- Covers Playwright (recommended) and Puppeteer with distinct testing vs scraping/agent guidance
- Six core principles including no manual waits and fresh context per test or task
Adoption & trust: 5.1k installs on skills.sh; 40.1k GitHub stars; 1/3 security scanners passed (skills.sh audits).
What problem does it solve?
Your browser scripts flake on timing and selectors, or you cannot tell whether you are building tests for your app or fighting hostile sites.
Who is it for?
Solo builders adding Playwright E2E to a SaaS repo, agent skills that need a real browser, or scrapers that need explicit anti-detection awareness.
Skip if: Teams that only need a hosted no-code scraper with no agent workflow, or projects with zero browser surface area.
When should I use this skill?
User needs Playwright/Puppeteer patterns for testing, scraping, or agent browser control and wants stable selectors and wait strategy.
What do I get? / Deliverables
You adopt locator, wait, isolation, and debugging patterns that produce stable automation—and separate test vs scrape/agent strategies before writing code.
- Automation design aligned to testing vs scraping/agent modes
- Locator and isolation conventions for CI and local debug
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Canonical shelf is Ship because the skill centers on test isolation, traces, and CI headless patterns—where flaky automation usually surfaces before release. Testing subphase matches E2E automation, user-facing locators, and debugging with screenshots and traces rather than one-off scraper scripts.
Where it fits
Wire Playwright into an agent skill that logs into a staging app and captures traces on failure.
Refactor E2E suites to use getByRole locators and isolated contexts before a release branch.
Replay headed runs with traces when a nightly browser job regresses after a UI change.
How it compares
Procedural skill for framework patterns—not a hosted browser farm or MCP browser server by itself.
Common Questions / FAQ
Who is browser-automation for?
Indie developers and agent users shipping web apps, CLI tools with browser steps, or agents that must click and read pages reliably.
When should I use browser-automation?
In Ship when hardening E2E tests; in Build when integrating Playwright into an agent or backend job; in Operate when debugging production browser checks; before choosing Playwright vs Puppeteer for a new flow.
Is browser-automation safe to install?
Review the Security Audits panel on this skill’s Prism page and treat any browser automation as capable of network access and page interaction when your agent runs it.
SKILL.md
READMESKILL.md - Browser Automation
# Browser Automation Browser automation powers web testing, scraping, and AI agent interactions. The difference between a flaky script and a reliable system comes down to understanding selectors, waiting strategies, and anti-detection patterns. This skill covers Playwright (recommended) and Puppeteer, with patterns for testing, scraping, and agentic browser control. Key insight: Playwright won the framework war. Unless you need Puppeteer's stealth ecosystem or are Chrome-only, Playwright is the better choice in 2025. Critical distinction: Testing automation (predictable apps you control) vs scraping/agent automation (unpredictable sites that fight back). Different problems, different solutions. ## Principles - Use user-facing locators (getByRole, getByText) over CSS/XPath - Never add manual waits - Playwright's auto-wait handles it - Each test/task should be fully isolated with fresh context - Screenshots and traces are your debugging lifeline - Headless for CI, headed for debugging - Anti-detection is cat-and-mouse - stay current or get blocked ## Capabilities - browser-automation - playwright - puppeteer - headless-browsers - web-scraping - browser-testing - e2e-testing - ui-automation - selenium-alternatives ## Scope - api-testing → backend - load-testing → performance-thinker - accessibility-testing → accessibility-specialist - visual-regression-testing → ui-design ## Tooling ### Frameworks - Playwright - When: Default choice - cross-browser, auto-waiting, best DX Note: 96% success rate, 4.5s avg execution, Microsoft-backed - Puppeteer - When: Chrome-only, need stealth plugins, existing codebase Note: 75% success rate at scale, but best stealth ecosystem - Selenium - When: Legacy systems, specific language bindings Note: Slower, more verbose, but widest browser support ### Stealth_tools - puppeteer-extra-plugin-stealth - When: Need to bypass bot detection with Puppeteer Note: Gold standard for anti-detection - playwright-extra - When: Stealth plugins for Playwright Note: Port of puppeteer-extra ecosystem - undetected-chromedriver - When: Selenium anti-detection Note: Dynamic bypass of detection ### Cloud_browsers - Browserbase - When: Managed headless infrastructure Note: Built-in stealth mode, session management - BrowserStack - When: Cross-browser testing at scale Note: Real devices, CI integration ## Patterns ### Test Isolation Pattern Each test runs in complete isolation with fresh state **When to use**: Testing, any automation that needs reproducibility # TEST ISOLATION: """ Each test gets its own: - Browser context (cookies, storage) - Fresh page - Clean state """ ## Playwright Test Example """ import { test, expect } from '@playwright/test'; // Each test runs in isolated browser context test('user can add item to cart', async ({ page }) => { // Fresh context - no cookies, no storage from other tests await page.goto('/products'); await page.getByRole('button', { name: 'Add to Cart' }).click(); await expect(page.getByTestId('cart-count')).toHaveText('1'); }); test('user can remove item from cart', async ({ page }) => { // Completely isolated - cart is empty await page.goto('/cart'); await expect(page.getByText('Your cart is empty')).toBeVisible(); }); """ ## Shared Authentication Pattern """ // Save auth state once, reuse across tests // setup.ts import { test as setup } from '@playwright/test'; setup('authenticate', async ({ page }) => { await page.goto('/login'); await page.getByLabel('Email').fill('user@example.com'); await page.getByLabel('Password').fill('password'); await page.getByRole('button', { name: 'Sign i