Webcmd

Least privilege: the README describes a sandboxed session model, explicit session IDs, and a browser-only default skill — measured layering (2). User confirmation (1): profiles are cookie jars reused to hand logged-in state to agents; no explicit confirmation mechanism for sensitive operations is documented. Data flow transparency (2): profile/session semantics are explained, but Webcmd Cloud data handling gets one sentence. Sensitive data handling (2): isolation and explicit session close are described, but no on-disk/encryption policy for cookie jars is shown. Dependency security (1): exact versions pinned for cloakbrowser and playwright-core, but no lockfile audit, SBOM, or rationale; postinstall/preuninstall lifecycle scripts (including a local HTTP shutdown call) are present without their implementations in evidence. External effects (1): the tool drives real browsers against real sites including authenticated social accounts ('Keep it read-only' appears only in one prompt example), with no systematic guardrail description. Rollback (1): plugins can be searched and installed, but no documented uninstall/rollback path. Source attribution (2): LICENSE carries clear copyright lines (jackwener / AgentR) consistent with package. author/repository.

Self-consistency (2): the 0–3 layer model and profile/session semantics are internally consistent and match package., but the README has a visible break — the Community section's 'Search and install them with:' is followed by an unrelated compatibility sentence. Dependency availability (2): Node 20.6+ stated, CI covers three OSes plus Bun; however, cloakbrowser 0.4.5 is a single hard dependency with no fallback path documented. Failure messages (2): benchmark tests verify cleanup/termination on startup failure, and structured -f output is shown, but the product's own error-message quality is not visible in the provided files.

Audience and scenarios (3): the layer table clearly spans unfamiliar sites to deterministic CLIs, with research/social/shopping example prompts. Capability boundaries (2): Cloud instability, illustrative plugin list, and plugin-dependent availability are noted, but the 'up to 90%' framing is vague. Trigger precision (2): explicit guidance to load the webcmd-browser skill only for live browser work, and precise example prompts. Environment fit (2): Node and Bun, three-OS CI, multiple harness targets for skills; but the browser engine is a single dependency (CloakBrowser) with no stated fallback.

Information architecture (3): README is well structured (layers → quick start → examples → benchmark → docs → community → contributing → license) with a documented docs site. Install notes (3): Node version, global install, plugin install, and skills install are all complete. Naming stability (2): @agentrhq/webcmd and the webcmd bin are consistent, but the project is pre-1.0 with an explicit 'Use Webcmd 0.7.11 or newer' compatibility break. Examples and FAQ (2): rich 'What You Can Ask' and X→CLI examples, but no FAQ or troubleshooting section. Known limitations (1): only one sentence about Cloud instability; applicability conditions of the 90% claim and plugin availability risks are under-disclosed. License (3): full Apache-2.0 text present and consistent across README, package., and badges. Versioning/changelog (1): version 0.8.2 exists but no CHANGELOG file is in evidence, only a release-notes generation script. Maintenance responsibility (2): SECURITY.md defines a private reporting channel and supported version (latest), CONTRIBUTING.md is referenced but not shown; maintenance cadence is only inferable from CI.

Output usability (2): examples specify required fields and source links; -f structured output recurs in CLI samples, but no actual output samples are shown. Marginal value (2): the learn-and-compile-to-deterministic-commands mechanism is genuinely differentiated; the benchmark chart claims best accuracy and lowest cost, but the methodology lives outside the provided files. Cost benefit (2): quantified anchors (90% token cut, $0.255/completed task) exist, yet the self-built stronger judge and judge-excluded cost accounting weaken comparability.

Claim traceability (2): the benchmark claim links to an in-repo report and external benchmark and states controlled conditions (same controller, model, judge, engine); but the headline '90%' has no inline derivation. Cross-source corroboration (1): the benchmark is self-reported and the plugin catalog lives in the same publisher's ecosystem; no independent third-party corroboration is in evidence. Fact/inference separation (2): the benchmark section defines its metrics ('accuracy is passed tasks out of 100') and explicitly contrasts its judge with the original setup; but marketing numbers and verifiable facts are not explicitly tiered in the text.