A browser skill should compile exploration into a contract

The second browser run should be less uncertain than the first

Most browser-agent demos celebrate the first successful run. Production teams care about the fiftieth: did the same task complete under a changed layout, an expired session, a partial API response, and a modal that was not present yesterday? A reusable skill is the bridge between those two standards.

The browser agent is useful during discovery because it can interpret a goal, inspect a page, try a path, recover from surprises, and find the data or action surface. That flexibility is also expensive. Every fresh exploration consumes tokens and time, exposes the model to untrusted page content, and creates another opportunity to choose the wrong account, cross an origin boundary, or perform a side effect before the operator understands what happened.

A skill should reduce that uncertainty. It turns a successful exploration into a named capability with typed inputs, structured outputs, a preferred execution path, a recovery ladder, explicit stop conditions, evidence, and verification. The skill may still call a model when judgment is necessary, but it should not ask the model to rediscover known facts on every run.

This is the most useful interpretation of BrowserAct's July Skill Forge push. The company describes a framework that discovers real website endpoints where possible and combines them with DOM manipulation when necessary. Its public skill package is designed for CLI agents including Codex, Claude Code, Cursor, Gemini CLI, and others. The portability story is attractive, but portability of instructions is not the same as portability of browser state, credentials, policies, or test evidence. Those remain deployment responsibilities.

Why BrowserAct skills became a timely developer topic

Fresh developer signals appeared in several places during the research window. BrowserAct's official materials added a detailed Skill Forge guide on July 14 and published updated skill catalog entries later in the month. A July 28 Show HN submission linked the public browser-act/skills repository. Between July 15 and July 30, pull requests added the official skill to multiple Codex and Claude skill catalogs, emphasizing authenticated browser automation, session isolation, network capture, human handoff, and reuse across agent runtimes.

These are adoption signals, not proof of production reliability. The HN submission received 16 points and two comments; many GitHub items were catalog additions rather than independent deployments. One more concrete artifact was a July 24 end-to-end test contribution that used BrowserAct to drive an authenticated gallery flow: sign in, create an album, upload a photo, and verify the result. That is closer to the evidence teams should demand because it names a complete outcome and exercises real browser state.

The broader research also supports the reusable-skill direction. WebXSkill identifies a grounding gap: text-only skills are understandable but not directly executable, while code-only skills execute but are opaque when an agent must recover. Its proposed middle ground pairs parameterized action programs with step-level natural-language guidance. ContractSkill reaches a similar operational conclusion through preconditions, postconditions, recovery rules, and termination checks.

The community remains cautious about browser agents. Recent discussions ask for replayable artifacts, authenticated-state isolation, hard approval gates, logged screenshots and tool calls, and deterministic fallbacks for known paths. Those requests matter more than a generic claim that a browser layer can handle “the real web.” They describe the acceptance test for such a layer.

Skill forging is a compilation pipeline, not a recording feature

Bounded task definition
  goal, inputs, allowed sites, forbidden effects
                 |
                 v
Read-only exploration in an isolated browser
  inspect UI, network, schemas, auth and failure states
                 |
                 v
Capability extraction
  prefer stable API - use DOM for irreducible interaction
                 |
                 v
Skill contract
  typed inputs, structured outputs, preconditions,
  steps, evidence, recovery, termination, approvals
                 |
                 v
Sandboxed tests and adversarial fixtures
  happy path, changed layout, expired login, injection,
  partial result, duplicate request, blocked side effect
                 |
                 v
Versioned release with provenance and rollback

Start with a task that has a stable business meaning: retrieve the five newest invoices, export a report for a specified date range, or draft a support reply without sending it. “Browse this website” is not a capability. Neither is “do whatever is necessary.” A forge cannot create a trustworthy boundary if the requested outcome has none.

Explore under a read-only or disposable account when possible. Observe the browser's network traffic and page structure, but treat all page text, DOM attributes, downloads, and API responses as untrusted data. The exploration should identify which steps are stable, which require interpretation, where authentication changes, and which controls create irreversible effects.

Extract the narrowest interface. A direct, documented API is usually better than a hidden endpoint; a hidden endpoint is often more stable and efficient than visual clicking but carries its own terms-of-service, schema, and access risks. DOM automation remains necessary for flows without suitable APIs. The skill should state which path it uses and what fallback is allowed rather than silently switching execution modes.

Finally, compile the discoveries into a package. The package should not contain captured credentials, browser profiles, raw session cookies, or environment-specific absolute paths. It should declare dependencies, supported versions, permissions, external domains, and the evidence returned to the caller. Release it with a source commit or checksum so an operator can tell what changed after an update.

Write the skill as an enforceable contract

A useful SKILL.md tells the agent when to invoke the capability and how to operate it. Enforcement must also exist below the prose: command allowlists, isolated profiles, scoped credentials, domain restrictions, output validation, and approval services. The model can follow instructions; it cannot be the sole authority that decides whether its own action is permitted.

name: invoice-report-export
version: 1.2.0
source_commit: 4e9c0d1
allowed_origins:
  - https://billing.example.com
inputs:
  account_id: {type: string, pattern: "^[A-Z0-9-]+$"}
  start_date: {type: date}
  end_date: {type: date}
execution:
  preferred: documented_api
  fallback: constrained_dom
side_effects:
  download_report: allow
  change_filters: allow
  email_report: require_confirmation
  modify_invoice: deny
evidence:
  - request_ids
  - record_count
  - report_sha256
  - final_url
termination:
  success: report hash and source count verified
  stop: origin change, auth challenge, schema mismatch

The contract separates four questions that agents often collapse. Can the skill reach the system? May it perform this operation? Did the operation produce the expected result? Can the result be trusted enough for the next step? Authentication answers only the first question. A confirmation dialog partly addresses the second. Postconditions and evidence address the last two.

Put judgment around deterministic islands

The best production browser architecture is rarely “agent all the way down.” Keep deterministic operations deterministic: schema validation, API requests, selector-based clicks, file hashing, record counts, retry policy, and permission checks. Use the model at ambiguity boundaries such as identifying the relevant row after a layout change, interpreting a novel modal, or deciding which recovery branch fits the observed state.

Run each account or tenant in an isolated browser profile. Do not let a research task inherit the same authenticated session that can access payroll, banking, source control, or customer administration. If Chrome takeover is necessary, make the profile and origin scope visible to the operator and narrow the requested task. Local login reuse is convenient precisely because it inherits real authority.

Send every proposed external effect through a policy gateway. The gateway normalizes the action, target, parameters, account, data class, and origin; evaluates them under server-side rules; and records the decision. A send, purchase, delete, submit, publish, or permission change should not occur merely because the skill text says “ask first.” The execution function should require an approval token tied to an immutable action digest.

Retain artifacts outside the model context. Screenshots, selected DOM snapshots, network logs, downloaded files, and structured results belong in an evidence store with retention and access controls. The agent receives only what it needs. This reduces context cost, limits cross-origin data mixing, and lets reviewers inspect the original evidence later.

Test the contract, not the narration

A skill test should start from a resettable fixture or disposable account and assert observable outcomes. “The model said it completed the export” is not an assertion. Verify the final URL, record count, file type, cryptographic hash, expected server record, absence of forbidden mutations, and the recorded approval trail.

given expired_session and report_range("2026-07-01", "2026-07-31"):
    result = run_skill(max_steps=20, side_effects="deny")

    assert result.status == "needs_human_login"
    assert result.external_writes == []
    assert result.retry_count <= 1
    assert result.evidence.contains("final_url")
    assert no_secret_values(result.logs)

Build a compact regression matrix: current layout, renamed control, slow response, empty result, partial API response, expired session, CAPTCHA, unexpected origin, indirect prompt injection, duplicate submission, and interrupted download. Run it against every supported browser and execution mode. A skill that uses an API-first path and a DOM fallback needs separate tests for both.

Measure more than task success. Track median steps, model tokens, wall time, recovery rate, false-success rate, unintended-side-effect rate, approval frequency, and evidence completeness. A forged skill earns its keep when later runs reduce discovery work without increasing silent error or authority.

Browser capability expands the security boundary

University of Washington researchers studying agentic browsers found significant differences in how products expose same-origin and cross-origin information to models. Traditional browser security assumes scripts are confined by origin. An agent that can interpret multiple tabs, frames, histories, and saved memories may create a new data path across those boundaries even when ordinary page JavaScript remains confined.

That makes prompt injection an architectural problem, not a prompt-writing problem. Page content can contain instructions that compete with the user's goal. A reusable skill reduces some exposure by narrowing the allowed workflow, but executable skills add supply-chain risk of their own. Inspect scripts, hooks, binaries, network calls, environment-variable access, update behavior, and license. Pin a reviewed revision instead of installing an unbounded latest version in a privileged agent environment.

Anti-bot and CAPTCHA capabilities also require judgment. A technical ability to reach a protected site does not establish permission to automate it. Respect site terms, robots directives where applicable, contractual limits, rate limits, privacy rules, and account policies. Do not build a workflow whose business case depends on evading a service's access decisions.

• Use a dedicated low-privilege browser profile and service account for each workflow.
• Allowlist origins and block navigation to unapproved domains, schemes, and local network addresses.
• Keep secrets in a broker; do not write cookies or tokens into the skill package or model context.
• Strip unneeded cross-origin content and retrieved page instructions before model interpretation.
• Require immutable, expiring approval tokens for external writes and sensitive reads.
• Sign or checksum released skills and record the exact version used by each run.
• Retain a kill switch that revokes sessions and stops queued executions.

Common failure modes and the right response

Choose the least agentic method that survives the task

The practical sequence is API, deterministic browser automation, constrained skill, and only then broad autonomous browsing. BrowserAct can participate in several layers, but the architecture should preserve that ordering. A flexible browser is a recovery tool and discovery environment; it should not erase deterministic paths that already work.

Teams adopting BrowserAct should begin with one read-heavy, repeated task and a disposable account. Write the contract before forging, inspect the generated package, add outcome assertions, test adversarial states, and publish a pinned internal version. If the second run is not cheaper, more reviewable, and less surprising than the first, the skill has not yet earned reuse.

FAQ

What is the main benefit of BrowserAct Skill Forge?

It provides a path from live website exploration to a reusable agent capability, using real endpoints where appropriate and DOM interaction where necessary. The benefit is reduced rediscovery; the team must still add policy, tests, provenance, and environment controls.

Does a SKILL.md file enforce permissions?

No. It guides behavior and routing. Actual enforcement belongs in the browser profile, sandbox, credential broker, network policy, tool gateway, and approval service.

Should a skill reuse my normal Chrome session?

Only for a tightly scoped, visible task when a separate account or profile is impractical. A normal session may expose email, payments, internal systems, and extensions. Dedicated profiles are safer and easier to revoke.

How often should a browser skill be revalidated?

Run contract tests on every skill or dependency update, after a target-site change, and on a schedule proportional to business impact. Monitor schema mismatch, recovery, false success, and side effects in production.