steel-browser

Original：🇺🇸 English

Translated

Use this skill whenever a user needs terminal-first browser automation with `steel browser`, asks to navigate/click/fill/snapshot/extract from websites, needs explicit browser session lifecycle control (`start`, `stop`, `sessions`, `live`), or wants to migrate `agent-browser` scripts. Trigger even when the user does not mention this skill by name and instead asks for multi-step web workflows, CDP attach behavior, local runtime setup, or browser automation troubleshooting.

2installs

Sourcesteel-dev/cli

Added on2026-02-28

NPX Install

npx skill4agent add steel-dev/cli steel-browser

SKILL.md Content

View Translation Comparison →

Steel Browser Skill

Use this skill to produce reliable, executable

steel browser

workflows for agent-driven automation.

Why this skill exists

steel browser

keeps broad command compatibility with

agent-browser

while adding Steel-native session lifecycle and endpoint handling. Agents get better results when they use named sessions, deterministic mode selection, and task-specific command patterns instead of one-off ad-hoc commands.

Use this workflow

Identify the operating mode first.
Start or attach a named session before interactive work.
Run task commands in small verifiable steps.
Validate results (
```
wait
```
,
```
snapshot
```
,
```
get ...
```
) before moving on.
Stop sessions when the task is done unless the user asks to keep them alive.

Mode selection rules

Use cloud mode by default.
Use self-hosted mode if the user specifies
```
--local
```
,
```
--api-url
```
, or self-hosted infrastructure.
Keep mode consistent for all commands in a sequence.

Read references/steel-browser-lifecycle.md for full lifecycle and endpoint precedence details.

Session discipline

Prefer
```
--session <name>
```
across all commands in one workflow.
Parse and preserve session
```
id
```
from
```
steel browser start
```
when needed for downstream tooling.
Treat
```
connect_url
```
as display-safe metadata; do not treat it as a raw secret-bearing URL.

Task execution pattern

Use this skeleton and adapt commands to the task:

bash

SESSION="task-$(date +%s)"
steel browser start --session "$SESSION"
steel browser open <url> --session "$SESSION"
steel browser snapshot -i --session "$SESSION"
# perform interactions/extraction commands
steel browser stop --session "$SESSION"

For command families and examples, read references/steel-browser-commands.md.

Migration behavior

When users provide

agent-browser

commands or scripts:

Convert command prefix from
```
agent-browser
```
to
```
steel browser
```
.
Preserve original behavior intent.
Add Steel lifecycle commands (
```
start
```
,
```
stop
```
,
```
sessions
```
,
```
live
```
) when explicit session control is needed.

Read references/migration-agent-browser.md.

Troubleshooting behavior

On auth, local runtime, stale sessions, or attach errors:

Diagnose with
```
sessions
```
,
```
live
```
, and mode/endpoint checks.
Provide a minimal corrective command sequence.
Retry the original action sequence.

Read references/troubleshooting.md.

Response format

When giving users commands, prefer this structure:

```
Mode
```
: cloud/self-hosted and why.
```
Session
```
: chosen session name and lifecycle steps.
```
Commands
```
: exact executable sequence.
```
Checks
```
: what output confirms success.

If the user asks for terse output, keep the same order but shorten prose.

Guardrails

Do not print or request raw API keys in command output.
Do not mix cloud and local mode in one flow unless explicitly transitioning.
Do not assume an existing active session without checking.
For inherited command uncertainty, use
```
steel browser <command> --help
```
.

Reference routing table

Lifecycle, endpoint precedence, attach rules: references/steel-browser-lifecycle.md
Complete command families and examples: references/steel-browser-commands.md
Migration from upstream command usage: references/migration-agent-browser.md
Error handling and recovery playbooks: references/troubleshooting.md