Browser Use

View saved version →

---
name: browser-use
description: Use when the user asks to automate, control, inspect, or test a website in a browser and an approved host-managed browser capability is available.
---

# Browser Use

Use an approved **host-managed browser** capability exposed by ChatGPT, Codex, or the current host. Do not bootstrap external browser runtimes from this skill.

## Operating rule

1. Prefer the host-managed browser or computer-use capability already available in the session.
2. Interact only with pages and actions the user is authorized to access.
3. Respect normal authentication, permission, and access boundaries. Respect warnings, access controls, and site protections without attempting to defeat them.
4. Do not download, install, or execute external tooling from this skill.
5. Do not import credentials, cookies, browser profiles, or secrets from outside the active host capability.

## Instruction-only fallback

If no approved browser capability is available, provide a browser automation plan or code-level guidance only. Clearly state that no browser action was executed. Never fabricate navigation, clicks, screenshots, page state, or successful completion.

## Output

Report what was attempted, what the host actually allowed, the observed result, and any limitation that prevented completion.

Referenced files: 2

View saved version →

---
name: cloud
description: Use when the user asks conceptual or code-design questions about Browser Use Cloud, hosted browser sessions, or integrating a hosted browser service.
---

# Browser Use Cloud Reference

This skill is documentation-oriented. It explains Browser Use Cloud concepts and helps design integrations without provisioning infrastructure, authenticating external services, or executing remote code.

## Use it for

- explaining hosted browser session architecture;
- reviewing application-level integration designs;
- discussing lifecycle, observability, error handling, and cleanup;
- drafting neutral interface shapes or pseudocode for a hosted browser abstraction.

## Boundaries

Do not install SDKs, fetch executable code, start remote services, request or move credentials, alter network routing, or provide instructions intended to evade website access controls. If the user needs live Browser Use Cloud execution, use only an approved connector or host capability that is already available; otherwise provide architecture guidance only.

Referenced files: 1

View saved version →

---
name: open-source
description: Use when the user asks how to write, review, or debug Python code that uses the open-source browser-use library APIs.
---

# Browser Use Open-Source Reference

This is a **reference-only** skill for reasoning about source code that uses the browser-use Python library.

It **does not install** packages, download tools, start services, connect to external browser runtimes, or change the user's environment. It **does not execute** the code it drafts unless the host separately provides an approved execution capability and the user asks to use it.

## Use it for

- explaining library concepts and object relationships;
- reviewing user-provided browser-use code;
- drafting Python examples that use documented library concepts;
- identifying likely bugs in agent, browser, tool, model, or configuration code;
- suggesting test cases for browser-use integrations.

## Boundaries

Keep examples self-contained and focused on application code. Do not provide bootstrap commands, remote-runtime connection instructions, credential setup, access-control workarounds, or instructions for defeating website protections.

When the requested behavior depends on an external service or runtime that is not already available through the host, explain the dependency instead of claiming it was run.

Referenced files: 1

View saved version →

---
name: qa
description: Use when the user asks to QA, test, evaluate, score, or inspect the quality and behavior of a website or web app in a browser.
---

# Browser QA

Evaluate a website or web app with an approved host-managed browser when one is available. The deliverable is a concise QA verdict backed by observed evidence.

## Method

1. Identify the target URL and the flow or quality dimension to test.
2. Use only the browser capability already exposed by the host.
3. Exercise the ordinary user-visible flow. Respect authentication, permissions, and access boundaries.
4. Record observable failures, confusing states, broken interactions, and accessibility/usability issues.
5. Score the tested experience from 1 to 5 and explain the evidence behind the score.

Do not install browser tooling, create tunnels, alter network settings, import credentials, or attempt to defeat warnings or access controls.

If no browser capability is available, provide a QA test plan instead and state that live testing was not performed.

Referenced files: 1

View saved version →

---
name: remote-browser
description: Use when the user explicitly asks to operate a remote browser session that is already provided and authorized by the current host.
---

# Remote Browser

Use only a remote browser capability that is already exposed and authorized by the current host. This skill does not bootstrap a remote service or authenticate an external command-line runtime.

## Workflow

1. Confirm that the host exposes an active remote browser capability.
2. Use that capability for the user's requested navigation and interaction.
3. Respect normal login, permission, and access boundaries.
4. Report the actual observed state and actions completed.

If the host does not expose a usable remote browser, provide an instruction-only fallback describing the intended steps and clearly state that no remote session was controlled.

Do not download or execute helper software, connect to undeclared endpoints, move credentials between environments, or attempt to defeat website protections.

Referenced files: 1

View saved version →

---
name: x402
description: Use when the user explicitly asks for conceptual guidance, code review, or debugging help for x402 payment integration with Browser Use, without handling secrets or initiating transactions.
---

# Browser Use x402 Reference

Reference-only guidance for understanding and reviewing x402 integrations around Browser Use.

## Scope

Use this skill to:
- explain the x402 request/response model at a high level;
- review user-provided integration code for structure, error handling, and configuration mistakes;
- explain how HTTP 402 payment-required flows fit into Browser Use architectures;
- help interpret non-sensitive logs or errors supplied by the user;
- identify which part of an integration belongs to the application, payment client, Browser Use service, or host environment.

## Safety and execution boundaries

This skill is reference-only. It does not install packages, download or execute external code, create accounts or wallets, or initiate financial transactions.

Never request or handle wallet secrets, recovery material, authentication secrets, or other sensitive credentials. Do not ask the user to paste them into chat or write them to files.

This skill does not initiate payments, move funds, purchase assets, top up balances, or perform on-chain actions. If a workflow requires a payment-capable client, assume the user has already configured it outside this skill and limit assistance to conceptual review and non-sensitive debugging.

Respect authentication, access controls, service policies, browser security boundaries, and other usage restrictions.

## Host capability adaptation

1. Prefer approved host-managed capabilities already available in ChatGPT or Codex.
2. If the user supplies code or logs, analyze only the supplied material and explain the likely integration issue.
3. If an external runtime would be required to complete an action, state that limitation instead of attempting to bootstrap, install, or invoke it.
4. Never fabricate a successful request, payment result, balance, transaction, or service response.

## Review checklist

When reviewing an x402 integration, check:
- whether a 402 response is handled as an expected protocol state rather than a generic failure;
- whether payment-related configuration is separated from application logic;
- whether retry behavior is bounded and avoids duplicate charge attempts;
- whether errors are surfaced without exposing sensitive values;
- whether the application distinguishes transport errors, authorization errors, payment-required responses, and service errors;
- whether the user has a safe test environment before any real-world payment-enabled deployment.

## Output style

Give concise architecture guidance, code-review findings, or debugging hypotheses. Clearly distinguish what can be inferred from the user's code/logs from what would require an external service or payment-capable runtime to verify.

Referenced files: 2