CtrlK
BlogDocsLog inGet started
Tessl Logo

browser-automation

Local OpenWork Electron browser automation with CDP. Use when driving a local Electron dev app, browser_list, browser_snapshot, browser_eval, composer automation, or local UI smoke tests.

65

Quality

78%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

SecuritybySnyk

Passed

No findings from the security scan

Fix and improve this skill with Tessl

tessl review fix ./.opencode/skills/browser-automation/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

82%Weight 40%Scale 1-5

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

A tight, highly actionable skill body: exact commands, ports, selectors, and a complete happy-path automation snippet with a defined smoke test and expected response. The main gaps are a small executable bug in the snippet's error branches and the absence of explicit error-recovery/retry guidance in the workflow.

Suggestions

Fix the browser_eval snippet's error branches: declare the variable (or use a literal) so '{ ok: false, reason: 'Run task not found', inserted }' does not throw a ReferenceError when the happy path fails.

Add a short retry/poll loop for waiting on the CDP port (e.g., a bounded 'until lsof shows LISTEN' check) and a one-line recovery hint for browser_eval ok:false results to close the workflow's validation loop.

DimensionReasoningScore

Conciseness

The body is lean and entirely operational — commands (pnpm dev, nohup, lsof), URLs, ports, a numbered flow, and one working code snippet — with zero explanation of concepts Claude already knows (no CDP or Electron tutorials, no filler). Not a 4 because there is no over-explanation to trim; every section carries non-obvious, project-specific facts.

5 / 5

Actionability

The guidance is largely copy-paste ready: exact shell commands, the CDP URL, target-selection steps, a full browser_eval snippet, and a known-good smoke prompt with its expected response. It falls short of fully executable because the snippet's error branches reference an undeclared shorthand variable 'inserted' ('Run task not found', inserted), which throws a ReferenceError if taken — a minor gap in an otherwise complete example.

4 / 5

Workflow Clarity

The 'Browser Tool Flow' gives a clear numbered 6-step sequence with a verification step ('Confirm the session response by checking document.body.innerText or the current URL'), and background launch includes a port-listen check plus a known-good expected response in Notes. It does not reach 5 because there is no explicit error-recovery loop (e.g., what to do when browser_eval returns ok:false, or how to poll/retry while waiting for the CDP port rather than a single lsof check).

4 / 5

Progressive Disclosure

The body is well-organized into scannable sections (What I Do, Local Dev Setup, Background Launch, Browser Tool Flow, Send A Session, Notes) with everything needed inline and no bundle files to navigate — appropriate since the content is a single coherent procedure, not separable reference material. It is not a 5 because, at ~95 lines, the full browser_eval snippet and smoke-test expectations sit inline in SKILL.md where a small scripts/ or references/ split could keep the overview tighter, and there is no explicit pointer structure to evaluate.

4 / 5

Total

17

/

20

Passed

Description

73%Weight 40%Scale 1-5

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

A tightly scoped, distinctive description with an explicit and concrete 'Use when' trigger clause. Its main weakness is that the capability side is expressed as a domain label plus tool names rather than enumerated concrete actions, which limits specificity and keeps completeness just below the top anchor.

Suggestions

State the 'what' as concrete third-person actions, e.g., 'Attaches OpenCode browser tools to the local OpenWork Electron app and drives its UI over CDP — sending composer tasks and confirming responses.'

Enumerate the core capabilities in the description (attach to the CDP port, select the OpenWork target, fill the Lexical composer, click Run task, verify the session response) so the what-side matches the trigger-side specificity.

Add a few natural synonyms to the trigger clause, such as 'CDP', 'DevTools', or 'UI test', to broaden the natural-term coverage toward the top trigger anchor.

DimensionReasoningScore

Specificity

The description names the domain precisely ("Local OpenWork Electron browser automation with CDP") and lists concrete tool names (browser_list, browser_snapshot, browser_eval), but it is a capability noun phrase rather than concrete actions — the actual verbs (attach, drive, send, confirm) only appear in the body, matching 'names domain and 1-2 concrete actions, but not comprehensive'. It is not a 2 because the tool names and 'composer automation' go beyond minimal/generic domain naming, and not a 4 because no specific action verbs are enumerated.

3 / 5

Completeness

Both parts are present: 'what' via 'Local OpenWork Electron browser automation with CDP' and an explicit 'when' clause ('Use when driving a local Electron dev app, browser_list, browser_snapshot, browser_eval, composer automation, or local UI smoke tests'). It does not reach 5 because the 'what' is a terse noun phrase without explicit capability statements (e.g., 'Attach browser tools to the app and drive the UI via CDP'), leaving the what-side weaker than the concrete trigger phrases on the when-side.

4 / 5

Trigger Term Quality

The 'Use when' clause covers natural trigger terms users would say in this context: 'driving a local Electron dev app', 'composer automation', 'local UI smoke tests', plus the three browser tool names. It falls short of the 5 anchor because common synonyms are missing (e.g., 'DevTools', 'CDP attach', 'end-to-end/UI test', 'OpenWork app'), and it is above 3 because several natural phrases beyond bare tool jargon are present.

4 / 5

Distinctiveness Conflict Risk

The description carves out a clear niche — the specific OpenWork Electron app, local development, and its named browser tools — so it would not trigger for generic browser automation, web testing, or other skills. Triggers are distinct and app-specific, matching the 'clear niche with distinct triggers; minimal conflict risk' anchor.

5 / 5

Total

16

/

20

Passed

Validation

100%

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation — 16 / 16 Passed

Validation for skill structure

No warnings or errors.

Repository
different-ai/openwork
Reviewed

Table of Contents

Is this your skill?

If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.