How Webcmd Works
Webcmd gives an agent one rule: reuse what already exists before exploring.The Agent’s Decision Flow
- Load
webcmd-usageand discover relevant existing adapters. - Use an existing command when it already satisfies the request.
- Explore through a browser only when the surface is unfamiliar or broken.
- Retain sitemap knowledge when it will help future browser work.
- Create or repair an adapter when the workflow should become repeatable.
From Exploration to a Command
Exploration is for understanding an unfamiliar surface. A verified, reusable workflow becomes an adapter command, so the next agent can use a stable CLI instead of repeating browser work.Adapters and Stable Output
An adapter turns a website, app, API, or local surface into one or more commands. Site adapters are installed as plugins; the core package bundles none. Legacy private adapters in~/.webcmd/clis/ remain discoverable, and local tools can also be exposed as external CLIs.
Commands should have clear names, stable inputs, useful errors, and JSON-friendly output. Stable output is the contract that lets another agent reuse a successful workflow.
Execution Strategies
The agent chooses the strategy; the human describes the outcome and constraints.Profiles, Sessions, And Tabs
A Profile is the browser identity and storage bucket, such asdefault or work. A Session is a named browser workspace inside a Profile. Create one with webcmd --profile work session create "Work Project", then use its returned readable ID with webcmd --profile work --session work-project-k7 browser tabs. Session IDs are immutable and Profile-scoped. Adapter commands without --session reuse adapter-default; raw browser commands require an explicit readable selector. A tab is one page inside that Session.
Adapter browser commands can use siteSession: 'ephemeral' for an isolated tab or siteSession: 'persistent' for a longer same-site workflow. Those adapter site-session modes are separate from raw browser Sessions.