domains / families / software-engineering / browser-automation

browser-automation

combined

Use when the user asks to do something on a real website, such as open a page, click through a flow, fill or submit a form, log in, extract data, take screenshots, or run a Skyvern workflow. Calls the Skyvern MCP server. Build reliable browser checks using observed UI state, semantic locators, bounded waits, isolated test data and explicit outcome verification.

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.

When not to use

• 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.

Skill page

Conflict

The two skills describe different procedures for different tools. The first is a specific operational runbook for the Skyvern MCP server, defining a session-based workflow, a strict approval protocol for credit-consuming actions, and security rules for handling web content and secrets. The second is a general guide for writing reliable browser automation tests using Playwright/Puppeteer/Selenium, focusing on semantic locators, test isolation, and avoiding fragile selectors. They do not reproduce or shorten each other; they are distinct approaches to browser automation (cloud-hosted agent vs. local test framework).