PluginBench
Skill
Review
Audit score 70

browser-automation

sickn33/agentic-awesome-skills

Build reliable browser automation tests using semantic locators, isolated contexts, and explicit outcome verification.

What is browser-automation?

Browser automation skill for testing real browser workflows with Playwright, Puppeteer, or Selenium. Use semantic locators (by role, label, text) instead of fragile CSS/XPath selectors, isolate test data per test, and verify explicit outcomes rather than relying on auto-waiting.

  • Use semantic locators (getByRole, getByLabel, getByText) for resilient element selection
  • Run tests in isolated browser contexts with no shared cookies or storage between tests
  • Verify explicit outcomes with bounded waits rather than relying on auto-waiting
  • Inspect current page state and available tool APIs before selecting locators
  • Capture authorized scope only; avoid screenshots/traces containing private information
  • Distinguish between retrying reads (safe) and retrying mutations like checkout or deletion (unsafe)

How to install browser-automation

npx skills add https://github.com/sickn33/agentic-awesome-skills --skill browser-automation
Prerequisites
  • Browser tool already selected or installed (Playwright, Puppeteer, or Selenium)
  • Running instance of the application under test
  • Synthetic test data for isolated test execution
  • Understanding of semantic locators vs. fragile CSS/XPath selectors
Claude Code
Cursor
Windsurf
Cline

How to use browser-automation

  1. 1.Read the detailed guide in references/detailed-guide.md before executing
  2. 2.Set up isolated browser contexts so each test runs with fresh state (no shared cookies/storage)
  3. 3.Use semantic locators: getByRole, getByLabel, getByText, getByPlaceholder, getByTestId (last resort)
  4. 4.Avoid fragile selectors: CSS class chains, nth-child, auto-generated data attributes, XPath tied to structure
  5. 5.Register event listeners (e.g., download) before triggering actions
  6. 6.Inspect the page and verify explicit outcomes with expect() assertions
  7. 7.Verify state before repeating mutations (checkout, deletion, messaging) to avoid duplicates

Use cases

Good for
  • Verify user workflows like adding items to cart and checking out in a local web app
  • Diagnose UI timing failures by observing actual browser state and interactions
  • Test form submission and validation with isolated test data per test case
  • Collect explicitly authorized page data from a running application
  • Validate keyboard/focus behavior and usability on desktop and mobile viewports
Who it's for
  • QA engineers testing web applications they control
  • Developers diagnosing UI timing and interaction issues
  • Teams building end-to-end test suites with Playwright, Puppeteer, or Selenium
  • Product teams verifying real browser workflows before deployment

browser-automation FAQ

Should I use CSS selectors or XPath for locating elements?

No. Use semantic locators instead: getByRole (best), getByLabel, getByText, getByPlaceholder. CSS and XPath tied to DOM structure are fragile and break when UI changes. Reserve getByTestId only when no user-facing option works.

How do I prevent test data from leaking between tests?

Run each test in an isolated browser context with fresh state. Playwright's test fixture provides this by default—each test gets a new page with no cookies or storage from other tests.

Can I retry a failed checkout or deletion?

No. Retrying reads (like checking a value) is safe, but retrying mutations (checkout, deletion, sending messages) may duplicate the side effect. Always verify state before repeating a mutation.

What should I do if auto-waiting isn't enough?

Auto-waiting checks actionability, not business correctness. Use bounded waits and explicit outcome verification: register event listeners before actions, inspect the page after interactions, and assert expected results with expect().

Can I capture screenshots and traces for debugging?

Yes, but only for authorized scope. Screenshots, HTML, and traces may contain private information. Capture only what you are authorized to inspect and avoid exposing hidden project data or network submissions.

Full instructions (SKILL.md)

Source of truth, from sickn33/agentic-awesome-skills.


name: browser-automation description: Build reliable browser checks using observed UI state, semantic locators, bounded waits, isolated test data and explicit outcome verification. risk: critical source: vibeship-spawner-skills (Apache 2.0) date_added: 2026-02-27

Browser Automation

Use the browser tool already selected by the user or installed in the project. Playwright, Puppeteer and Selenium have different integrations; choose from actual requirements rather than unsupported success-rate claims. Modified by AAS maintainers on 2026-09-05: removed unverified comparisons and bypass defaults, clarified waiting and evidence limits.

Separate tests of applications you control from interaction with an existing authenticated browser. Do not replace the latter with a fresh unauthenticated session or extract credentials to make an automation test work.

Detailed Guide

Read the detailed guide before executing this skill. It retains the complete procedure and reference material. Treat its safety, prerequisites, and validation requirements as mandatory. For focused work, load the relevant sections; for end-to-end work, read the guide completely.

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(); }); """

Good Examples (User-Facing)

""" // By role - THE BEST CHOICE await page.getByRole('button', { name: 'Submit' }).click(); await page.getByRole('link', { name: 'Sign up' }).click(); await expect(page.getByRole('heading', { name: 'Dashboard' })).toBeVisible(); await page.getByRole('textbox', { name: 'Search' }).fill('query');

// By text content await expect(page.getByText('Welcome back')).toBeVisible(); await page.getByText(/Order #\d+/).click(); // Regex supported

// By label (forms) await page.getByLabel('Email address').fill('user@example.com'); await page.getByLabel('Password').fill('secret');

// By placeholder await page.getByPlaceholder('Search...').fill('query');

// By test ID (when no user-facing option works) await page.getByTestId('submit-button').click(); """

Bad Examples (Fragile)

""" // DON'T - CSS selectors tied to structure await page.locator('.btn-primary.submit-form').click(); await page.locator('#header > div > button:nth-child(2)').click();

// DON'T - XPath tied to structure await page.locator('//div[@class="form"]/button[1]').click();

// DON'T - Auto-generated selectors await page.locator('[data-v-12345]').click(); """

When to Use

Use to verify a real browser workflow, diagnose a UI timing failure or collect explicitly authorized page data. Inspect the current page and available tool APIs before selecting locators or actions.

Worked example and prerequisites

Input: exporting a reviewed JSON file from a local web app. Have the app running, the intended browser available and a synthetic form value. Observe the export control, register the download event before clicking, inspect the downloaded JSON and confirm that editing the input invalidates the old preview. Expected: one file containing the reviewed value, with no hidden project data or network submission.

Use explicit desktop/mobile viewports and inspect keyboard/focus behavior when the task includes usability. A locked desktop leaves interactive verification pending; unit tests and headless probes are separate evidence.

Limitations

  • Auto-waiting checks actionability, not business correctness or successful backend writes.
  • Screenshots, HTML, traces and auth-state files may contain private information; capture only the authorized scope.
  • Retrying a read can be safe; retrying checkout, deletion or sending a message may duplicate a side effect. Verify state before repeating it.
  • Resource blocking and mocked responses change the environment and cannot establish unmodified production behavior.
  • Examples require the project’s imports, runner and fixture routes; no browser, service or account is installed by this skill.