browser-automation

Stars11

Forks3

UpdatedJuly 4, 2026 at 08:43

Use when a task needs a real browser — navigating sites, filling and submitting forms, clicking through flows, extracting page data, or taking screenshots — driving whatever browser tool or MCP server is available.

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Source

imzodev

imzodev/openaidy

View GitHub Repository View Creator Repositories

Download

Related occupationsSOC

Based on SOC occupation classification

Software DevelopersComputer and Mathematical Occupations·SOC 15-1252

File Explorer

2 files

SKILL.md

readonly

name	Browser Automation
description	Use when a task needs a real browser — navigating sites, filling and submitting forms, clicking through flows, extracting page data, or taking screenshots — driving whatever browser tool or MCP server is available.
version	1.0.0

Browser Automation

Some things only exist behind a page: a login-walled dashboard, a form with no API, a site that renders with JavaScript. Drive a browser to do them — deliberately, one observable step at a time.

Before you start

Confirm a browser tool or configured MCP server (Playwright, Puppeteer, a browser MCP, etc.) is available. If not, tell the user what to set up instead of pretending to click.
Restate the goal as a concrete end state — "reach the order-confirmation page", "extract the table rows". You need to know when you're done.
Flag any step that spends money, sends a message, or changes someone else's data, and get explicit approval before running it.

Method

Navigate, then observe before acting. Read the actual page — visible text, form fields, current URL — rather than assuming the layout.
Prefer stable selectors: visible labels, roles, and text over brittle CSS/xpath tied to generated class names.
Do one action, then re-check the result. Don't fire a long sequence blind and hope it worked.
Wait for the page to settle — network idle, element present — instead of fixed-duration sleeps.
Capture a screenshot at decision points and on failure. It's your evidence of what actually happened.

Guardrails

Never submit a purchase, booking, message, or account change without confirming first.
Don't enter credentials the user didn't give you; use the browser's existing session or profile where possible.
Stop and report if you hit a login wall, a CAPTCHA, or a page you didn't expect — don't thrash.

See references/automation-recipe.md.

Anti-patterns

Assuming a selector still exists instead of checking the current page.
Chaining many clicks with no verification between them.
Treating a fixed "wait 5 seconds" as a substitute for a real condition.
Auto-accepting consent or purchase dialogs that have real consequences.

More from this repository

same repository

addon-ui-components-cookbook

imzodev/openaidy

Use when writing or reviewing OpenAidy addon UI code (app/index.html, app/index.js) that calls sdk.ui.* — covers component mounting semantics and composed usage patterns beyond the one-line reference in addon_create's tool description.

2026-07-2011

data-and-apis

imzodev/openaidy

Use when calling external REST APIs or querying databases on the user's behalf through available tools or MCP servers — read-only by default, parametrized queries, and confirmation before any write.

2026-07-0411

working-with-documents

imzodev/openaidy

Use when reading, extracting from, or generating real-world document files — PDFs, spreadsheets (CSV/Excel/Sheets), and slide decks — with available tools; preserve the source and verify the output.

2026-07-0411

scheduling

imzodev/openaidy

Use when working with calendars — checking availability, finding meeting times, and creating or updating events through an available calendar integration — with careful timezone handling and confirmation before inviting others.

2026-07-0411

sending-messages

imzodev/openaidy

Use when posting to chat or email on the user's behalf — Slack, Discord, Telegram, or mail — through an available integration. Get the recipient and content right, and confirm before anything goes out.

2026-07-0411

web-research

imzodev/openaidy

Use when you need current or external facts — searching the web, reading multiple sources, cross-checking claims, and synthesizing an answer with citations instead of guessing from memory.

2026-07-0411

name	Browser Automation
description	Use when a task needs a real browser — navigating sites, filling and submitting forms, clicking through flows, extracting page data, or taking screenshots — driving whatever browser tool or MCP server is available.
version	1.0.0

Browser Automation

Some things only exist behind a page: a login-walled dashboard, a form with no API, a site that renders with JavaScript. Drive a browser to do them — deliberately, one observable step at a time.

Before you start

Confirm a browser tool or configured MCP server (Playwright, Puppeteer, a browser MCP, etc.) is available. If not, tell the user what to set up instead of pretending to click.
Restate the goal as a concrete end state — "reach the order-confirmation page", "extract the table rows". You need to know when you're done.
Flag any step that spends money, sends a message, or changes someone else's data, and get explicit approval before running it.

Method

Navigate, then observe before acting. Read the actual page — visible text, form fields, current URL — rather than assuming the layout.
Prefer stable selectors: visible labels, roles, and text over brittle CSS/xpath tied to generated class names.
Do one action, then re-check the result. Don't fire a long sequence blind and hope it worked.
Wait for the page to settle — network idle, element present — instead of fixed-duration sleeps.
Capture a screenshot at decision points and on failure. It's your evidence of what actually happened.

Guardrails

Never submit a purchase, booking, message, or account change without confirming first.
Don't enter credentials the user didn't give you; use the browser's existing session or profile where possible.
Stop and report if you hit a login wall, a CAPTCHA, or a page you didn't expect — don't thrash.

See references/automation-recipe.md.

Anti-patterns

Assuming a selector still exists instead of checking the current page.
Chaining many clicks with no verification between them.
Treating a fixed "wait 5 seconds" as a substitute for a real condition.
Auto-accepting consent or purchase dialogs that have real consequences.