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.

71

Quality

86%

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

SKILL.md
Quality
Evals
Security

Quality

Content

87%

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 operational runbook with executable code and a clear step sequence. The main gap is an explicit error-recovery loop in the workflow, and one command carries a machine-specific path that limits copy-paste portability.

Suggestions

Add an explicit feedback loop after step 6: instruct Claude on what to do when the session response is not confirmed (e.g. re-list targets, re-select the OpenWork target, or re-check that CDP is listening) before retrying.

Replace the hardcoded log path in the nohup command (/var/folders/d9/.../openwork-dev.log) with a portable placeholder like "$(mktemp -d)/openwork-dev.log" or $TMPDIR so the command is copy-paste ready across machines.

Spell out the recovery action for the JS guard reasons (editor not found / Run task disabled) so the verification step connects to a concrete next action rather than just returning a reason.

DimensionReasoningScore

Conciseness

The body is lean: terse bullets, short focused code blocks, and direct commands with no padding or explanation of concepts Claude already knows (no 'what is Electron/CDP' prose). Every section earns its tokens.

3 / 3

Actionability

It provides fully executable guidance — env-var setup, `pnpm dev`, `lsof -nP -iTCP:9823 -sTCP:LISTEN`, a `browser_list` call with an explicit browser_url, and a complete runnable JS IIFE with concrete selectors and button text — copy-paste ready.

3 / 3

Workflow Clarity

A clear 6-step sequence exists with a readiness checkpoint (lsof LISTEN) and a verification step (confirm response via innerText/URL), but there is no explicit error-recovery feedback loop telling Claude what to do when confirmation fails or a JS guard returns not-ok; the recovery path is implicit.

2 / 3

Progressive Disclosure

The content is organized into clear, navigable sections (What I Do as overview, then Setup, Background Launch, Tool Flow, Send A Session, Notes) with no nested references and no need for external files for this self-contained runbook.

3 / 3

Total

11

/

12

Passed

Description

85%

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 strong, specific description that clearly states capability and trigger conditions with low conflict risk. Its only weakness is trigger-term naturalness, leaning on exact tool names over broadly natural user phrasings.

Suggestions

Soften the jargon-heavy triggers by adding natural user phrasings such as 'automate the local app UI' or 'run a UI smoke test against the Electron app' alongside the tool identifiers.

Keep browser_list/browser_snapshot/browser_eval as supplementary keywords rather than the primary trigger terms, so a user who describes the goal in plain language still matches.

DimensionReasoningScore

Specificity

The description lists multiple concrete actions/tools — "browser_list, browser_snapshot, browser_eval, composer automation, or local UI smoke tests" — alongside the named domain (OpenWork Electron + CDP), matching the 'lists multiple specific concrete actions' anchor.

3 / 3

Completeness

It states both what ("Local OpenWork Electron browser automation with CDP") and an explicit when ("Use when driving a local Electron dev app, ..."), satisfying the 'clearly answers both what AND when with explicit triggers' anchor.

3 / 3

Trigger Term Quality

Relevant keywords are present ("local UI smoke tests", "composer automation", "local Electron dev app") but the dominant triggers are exact tool identifiers (browser_list/snapshot/eval) that read as jargon; common natural variations a user might say (e.g. 'automate the app UI', 'test the local app') are missing.

2 / 3

Distinctiveness Conflict Risk

The niche is highly specific (local OpenWork Electron app via CDP) with distinct, tool-specific triggers, making it unlikely to fire for unrelated skills.

3 / 3

Total

11

/

12

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.

Validation16 / 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.