Browser Steel

Browser automation with Steel CLI as the default runtime, plus a Python Playwright fallback for custom flows. Use when the user asks to open a JS-heavy site,...

Security Scan

The skill's code, instructions, and requested credential (STEEL_API_KEY) are consistent with a browser-automation wrapper for the Steel CLI and a Python/Playwright fallback; nothing in the bundle indicates deliberate misdirection or unrelated credential access, but there are a few practical privacy/runtime risks to be aware of.

Purpose & Capability

Name/description (browser automation with Steel CLI + Python Playwright fallback) align with required binaries (steel, python3), the presence of a wrapper script, and the single required env var STEEL_API_KEY. The included CLI commands, session workflows, and Python plan runner are coherent with the stated purpose.

Instruction Scope

SKILL.md and scripts/main.py load environment variables and .env files (cwd and skill dir) and reference additional environment variables (e.g., STEEL_BROWSER_ENV_FILE, STEEL_BROWSER_COOKIES_FILE, STEEL_BROWSER_PYTHON_BIN, STEEL_BROWSER_CLI_BIN, STEEL_BROWSER_API_URL / STEEL_LOCAL_API_URL) that are not listed as required in the registry metadata. While these are plausible runtime options for configuring the wrapper, loading .env from the current working directory or skill directory can cause the skill to read local secrets unexpectedly. The instructions do warn against baking secrets into the skill, but the automatic .env loading behavior is a privacy-sensitive action worth noting.

Install Mechanism

No install spec (instruction-only plus an included wrapper script). The wrapper may invoke the CLI via an installed `steel` binary or fall back to `npx --yes @steel-dev/cli`, which will fetch code from the npm registry at runtime. Using npx implies runtime network retrieval/execution of package code (moderate risk compared to a declared, reviewed package install). This is expected for a CLI-first skill but worth awareness.

Credentials

The declared primary credential is a single STEEL_API_KEY, which is appropriate. However, the code and docs use several optional env vars and files (cookies file paths, alternate python binary, forced CLI bin, env-file variables, and API URL overrides). These extras are relevant to advanced runtime scenarios but increase the number of sensitive inputs the skill can read. None of them appears unrelated to the stated functionality, but they should be considered when setting environment context.

Persistence & Privilege

The skill is not always-enabled and does not request system-wide persistence. It does read .env files and may create named sessions via the Steel CLI (normal for browser automation), but it does not modify other skills or global agent settings. Autonomous invocation is allowed by default (normal for skills) and is not by itself a reason to downgrade the verdict.

Assessment

This skill appears to be what it claims: a CLI-first browser automation wrapper that uses a STEEL_API_KEY to talk to the Steel runtime and can fall back to Python/Playwright. Before installing or using it: (1) Treat your STEEL_API_KEY like any API secret — ensure the key's scope and permissions are appropriate and rotate it if unsure. (2) Be aware the wrapper automatically looks for .env files in your working directory and the skill directory and will merge those values into its environment — do not keep unrelated secrets in those locations if you don't want them read by the skill. (3) The wrapper may call `npx @steel-dev/cli` when a local `steel` binary is absent; npx downloads and runs code from npm at runtime, so only use that fallback in environments where you trust the upstream package. (4) Optional env vars (STEEL_BROWSER_COOKIES_FILE, STEEL_BROWSER_ENV_FILE, STEEL_BROWSER_PYTHON_BIN, STEEL_BROWSER_CLI_BIN, STEEL_BROWSER_API_URL, etc.) are supported — review and set them explicitly rather than relying on auto-discovery. (5) If you need higher assurance, inspect or run the included scripts/main.py in a sandboxed environment to confirm behavior, or require a local installation of the trusted `steel` CLI to avoid npx network pulls.

Use Steel CLI first. Use the Python runtime only when the workflow needs selector-heavy custom logic that is awkward to express through raw CLI steps.

What CLI means here

CLI means Command Line Interface.

In this skill, it specifically means the Steel terminal commands themselves, for example:

steel scrape https://example.com
steel browser start --session demo
steel browser open https://example.com --session demo
steel browser snapshot -i --session demo

The wrapper script does not replace Steel CLI. It packages it into a more publishable, agent-friendly entrypoint:

python3 {baseDir}/scripts/main.py scrape --url https://example.com
python3 {baseDir}/scripts/main.py start-session --session demo
python3 {baseDir}/scripts/main.py browser --session demo -- snapshot -i -c

So the relationship is:

• Steel CLI = the underlying browser command system
• scripts/main.py = the wrapper that calls Steel CLI by default
• Python runtime = a fallback path for custom Playwright logic when CLI steps are not enough

First checks

1. Run the doctor command before the first real task in a new environment:

   python3 {baseDir}/scripts/main.py doctor
   

2. Prefer stateless commands for one-shot extraction or capture.
3. Prefer named sessions for multi-step interaction.
4. Keep the same --session value across every step in one workflow.
5. Never bake private cookies, profile names, or local paths into the skill itself.

Runtime selection

• auto: prefer installed steel, otherwise fall back to npx @steel-dev/cli
• cli: same as auto, but fail if no CLI path is available
• node: force the Node-distributed CLI path through npx @steel-dev/cli
• python: use Steel SDK + Playwright through run-python-plan

Read references/runtime-modes.md only when runtime choice or env resolution matters. Read references/official-docs.md when you need the authoritative Steel CLI or Playwright-Python upstream reference.

Preferred commands

Health check

python3 {baseDir}/scripts/main.py doctor

Stateless commands

python3 {baseDir}/scripts/main.py scrape --url https://example.com --format markdown --json
python3 {baseDir}/scripts/main.py screenshot --url https://example.com --full-page --json
python3 {baseDir}/scripts/main.py pdf --url https://example.com --json

Named-session workflow

python3 {baseDir}/scripts/main.py start-session --session demo --stealth --json
python3 {baseDir}/scripts/main.py browser --session demo -- open https://example.com
python3 {baseDir}/scripts/main.py browser --session demo -- snapshot -i -c
python3 {baseDir}/scripts/main.py browser --session demo -- fill @e2 "hello"
python3 {baseDir}/scripts/main.py browser --session demo -- click @e5
python3 {baseDir}/scripts/main.py browser --session demo -- wait --load-state networkidle
python3 {baseDir}/scripts/main.py stop-session --session demo --json

Python Playwright plan

python3 {baseDir}/scripts/main.py run-python-plan \
  --plan-file {baseDir}/references/example-plan.json \
  --url https://example.com

Read references/python-plan.md only when the CLI path is insufficient.

Guardrails

• Start with scrape, screenshot, or pdf when the task is stateless.
• For interactive workflows, follow start-session -> browser commands -> stop-session.
• After any navigation or meaningful DOM change, take a fresh snapshot -i before using another @eN ref.
• Keep secrets in env vars or an explicit --env-file, not in the skill files.
• Pass cookies only through --cookies-file or STEEL_BROWSER_COOKIES_FILE.
• Use the Python runtime only for tasks that genuinely benefit from custom Playwright logic.
• Record confirmed improvements in maintenance.log.

References

• references/official-docs.md — upstream Steel CLI and Playwright-Python references
• references/runtime-modes.md — runtime choice, env loading, and privacy rules
• references/cli-workflows.md — reliable Steel CLI patterns
• references/python-plan.md — JSON plan schema and supported actions
• references/troubleshooting.md — install/auth/runtime recovery