agent-browser

Name: agent-browser
Author: superagent-ai

AI Community

Repo stars 3,082
Author repo grok-cli

Interpretation is structured for decision-making; original keeps the upstream SKILL.md unchanged.

Decide Fit First

Core job: Use the host-side agent-browser CLI for local browser smoke tests, screenshots, snapshots, and simple UI validation against fo…
Best fit: Use it when the task has reusable inputs, steps, and validation criteria rather than a one-off answer.
Avoid forcing it: If the source lacks commands, platform support, or external-service evidence, keep those fields unknown instead of guessing.

Design Intent

Structure: The skill is organized around “Requirements”, “Core flow”, “Common commands”, “Guidance”, showing how the author expects the agent to judge fit, collect context, and produce verifiable output.
Trigger evidence: Prioritize the author’s wording around when to use it, what context to collect, and what output shape to produce.
Evidence boundary: Author text states facts, repository files prove commands and paths, and Fluxly only adds fit, limits, and usage judgment.

How To Use It

Inputs: Provide target material, scope, expected result, forbidden changes, and validation method.
Invocation: Name agent-browser directly; if the source includes slash commands, start with the command and then add task context.
Validation: Start small and check whether the result follows “Requirements / Core flow / Common commands” before expanding.

Boundaries And Review

Dependencies: It usually needs no extra API key, so start with a small validation task.
Permissions: Declared permissions include read; ask the agent to state file, command, and rollback boundaries before acting.
Quality bar: A useful result names the deliverable, evidence, and next action. Generic prose means the task needs tighter context.

agent-browser

Use this skill when verification needs a real browser after the app is booted from the sandbox.

This project uses agent-browser on the host, not inside Shuru. The usual flow is:

Start the app with sandboxed bash.
Expose it through a forwarded localhost port.
Use agent-browser against that localhost URL.

Requirements

The agent-browser CLI must be installed and available on PATH.
Prefer http://127.0.0.1:<port> or another explicit localhost URL.
Use a named browser session when there is any chance of concurrent runs.

Core flow

agent-browser --session verify open http://127.0.0.1:3000
agent-browser --session verify wait --load networkidle
agent-browser --session verify snapshot -i

After any click or navigation, re-snapshot before using old refs again.

Common commands

# Open and wait for readiness
agent-browser --session verify open <url>
agent-browser --session verify wait --load networkidle

# Inspect the page
agent-browser --session verify snapshot -i
agent-browser --session verify get title
agent-browser --session verify get url

# Interact with elements from snapshot refs
agent-browser --session verify click @e1
agent-browser --session verify fill @e2 "text"
agent-browser --session verify press Enter

# Record the smoke test as video
agent-browser record start .grok/verify-artifacts/verify-smoke.webm

# Capture screenshot proof (use --screenshot-dir, not a positional path)
mkdir -p .grok/verify-artifacts
agent-browser --screenshot-dir .grok/verify-artifacts screenshot
agent-browser --screenshot-dir .grok/verify-artifacts screenshot --full

# Stop recording and clean up
agent-browser record stop
agent-browser close

Guidance

Keep browser checks narrow in phase 1: page load, one or two critical controls, and optional screenshot evidence.
Save screenshots to stable workspace-relative paths under .grok/verify-artifacts/ so verify can report them back to the user.
Prefer wait --load networkidle after open.
If the page is dynamic, use snapshot -i again after each meaningful DOM change.
If the target URL is ambiguous because multiple forwarded ports exist, stop and report the ambiguity instead of guessing.
If agent-browser is unavailable, fall back to bash-only verification and say so clearly.

Fluxly profile Author and license come from source; runtime, permissions, and network are Fluxly detections or estimates

Fluxly category: AI
Author-declared agents: No explicit declaration found; this is not inferred or tested compatibility
Static check: 88 / 100 · heuristic scan, not runtime safety proof
Author / version / license: @superagent-ai · no license declared
Fluxly token estimate: Lean
Fluxly setup estimate: Plug-and-play
External API key: No requirement detected
Detected OS requirements: Unspecified
Runtime requirements: Unspecified
Detected file/system behavior: Read-only
Detected network behavior: Local-only
Install commands: None (reference only)

Profile is derived at build time from SKILL.md and install vectors. Subject to drift from author intent.

Heads up: 未限定 allowed-tools，默认拥有全部工具权限。

Output preview agent-browser-superagent-ai.preview

The current SKILL.md does not define a fixed output example.

SKILL.md SKILL.md

# agent-browser

Use this skill when verification needs a real browser after the app is booted from the sandbox.

This project uses `agent-browser` on the host, not inside Shuru. The usual flow is:

1. Start the app with sandboxed bash.
2. Expose it through a forwarded localhost port.
3. Use `agent-browser` against that localhost URL.

## Requirements

- The `agent-browser` CLI must be installed and available on `PATH`.
- Prefer `http://127.0.0.1:<port>` or another explicit localhost URL.
- Use a named browser session when there is any chance of concurrent runs.

## Core flow

```bash
agent-browser --session verify open http://127.0.0.1:3000
agent-browser --session verify wait --load networkidle
agent-browser --session verify snapshot -i
```

After any click or navigation, re-snapshot before using old refs again.

## Common commands

```bash
# Open and wait for readiness
agent-browser --session verify open <url>
agent-browser --session verify wait --load networkidle

# Inspect the page
agent-browser --session verify snapshot -i
agent-browser --session verify get title
agent-browser --session verify get url

# Interact with elements from snapshot refs
agent-browser --session verify click @e1
agent-browser --session verify fill @e2 "text"
agent-browser --session verify press Enter

# Record the smoke test as video
agent-browser record start .grok/verify-artifacts/verify-smoke.webm

# Capture screenshot proof (use --screenshot-dir, not a positional path)
mkdir -p .grok/verify-artifacts
agent-browser --screenshot-dir .grok/verify-artifacts screenshot
agent-browser --screenshot-dir .grok/verify-artifacts screenshot --full

# Stop recording and clean up
agent-browser record stop
agent-browser close
```

## Guidance

…

Evidence boundary and execution chain

Author text anchors workflow facts; Fluxly only indexes current sections, terms, files, and commands.

sections -> Requirements → Core flow → Common commands → Guidance
terms    -> Use this skill when verification needs a real browser after the app is booted from the sandbox. · This project uses agent-browser on the host, not inside Shuru. · 1. Start the app with sandboxed bash. · - The agent-browser CLI must be installed and available on PATH. · After any click or navigation, re-snapshot before using old refs again. · - Keep browser checks narrow in phase 1: page load, one or two critical controls, and optional screenshot evidence.
files/cmd -> agent-browser · PATH · http://127.0.0.1:<port> · .grok/verify-artifacts/ · wait --load networkidle · open · snapshot -i
body sha256 -> 0ef65b37de27

Decide Fit First

Design Intent

How To Use It

Boundaries And Review

agent-browser

Requirements

Core flow

Common commands

Guidance

Discussion