CtrlK
BlogDocsLog inGet started
Tessl Logo

browser-automation

Build reliable browser checks using observed UI state, semantic locators, bounded waits, isolated test data and explicit outcome verification.

60

Quality

70%

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

The body is well-structured and highly actionable, with executable Playwright examples, good/bad contrasts, a verified worked example with validation, and a clear one-level-deep reference to the detailed guide. Main improvements are relocating the inline changelog note and possibly splitting more reference material into bundle files.

Suggestions

Move the 'Modified by AAS maintainers on 2026-09-05...' editorial note out of the overview body (e.g., into a changelog section or file) to remove time-sensitive bloat from the main flow.

Consider extracting the locator good/bad examples or the worked example into a reference file to strengthen progressive disclosure toward a clearer overview-plus-reference split.

Add a short general numbered workflow (observe state -> choose locator -> act with bounded wait -> verify outcome) alongside the single worked example to make the feedback loop explicit for arbitrary tasks.

DimensionReasoningScore

Conciseness

The body is largely efficient with tight, non-obvious guidance and executable examples, but the inline date-stamped changelog note ('Modified by AAS maintainers on 2026-09-05: removed unverified comparisons...') is editorial bloat that belongs elsewhere, matching the 'efficient; minor instances that could be trimmed' anchor.

4 / 5

Actionability

Provides fully executable, copy-paste-ready Playwright code covering the common locator cases (getByRole, getByText, getByLabel, getByPlaceholder, getByTestId) plus concrete bad-example contrasts, fitting the 'fully executable; specific examples cover the common cases' anchor.

5 / 5

Workflow Clarity

The worked example lays out a clear sequence with explicit verification checkpoints ('register the download event before clicking', 'confirm that editing the input invalidates the old preview', 'Expected: one file...'), so the destructive-operation cap does not apply, but it is a single worked scenario rather than a general feedback-loop workflow, fitting anchor 4.

4 / 5

Progressive Disclosure

A dedicated 'Detailed Guide' section clearly signals a one-level-deep reference (references/detailed-guide.md, which exists), and the body is well-sectioned, but only one reference file is provided and substantial example content is inlined, matching 'good structure; mostly appropriately placed; minor organization gaps' rather than the multi-reference anchor 5.

4 / 5

Total

17

/

20

Passed

Description

58%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.

The description is specific and distinct, clearly stating what the skill does through several concrete techniques, but it omits any explicit 'Use when...' trigger guidance and relies on technical rather than natural user phrasing. Adding a trigger clause with user-facing terms would lift completeness and trigger-term quality.

Suggestions

Append a 'Use when...' clause with natural trigger phrases (e.g., 'Use when verifying a real browser workflow, diagnosing a UI timing failure, or automating a web interaction').

Add user-facing terms alongside the technical ones (e.g., 'browser automation', 'test a web app', 'web UI') so the description matches what a user would actually say.

Lead with one or two more action verbs (e.g., 'Verify, diagnose, and automate browser workflows...') to broaden the action coverage toward the comprehensive anchor.

DimensionReasoningScore

Specificity

Names the browser-checks domain plus several specific techniques ('observed UI state, semantic locators, bounded waits, isolated test data and explicit outcome verification'), but only one action verb ('Build') drives the list, leaving minor action-coverage gaps versus the comprehensive multi-verb anchor 5.

4 / 5

Completeness

A clear 'what' is present ('Build reliable browser checks...') but there is no 'Use when...' clause or equivalent explicit trigger guidance, so per the rubric cap completeness stays at 3 rather than 4.

3 / 5

Trigger Term Quality

Relevant domain keywords appear ('browser checks', 'UI state', 'locators', 'waits'), but they lean technical and omit the natural phrases a user would say ('automate the browser', 'test my website', 'scrape this page'), matching the 'some relevant keywords but missing common variations' anchor.

3 / 5

Distinctiveness Conflict Risk

The browser-automation/testing niche is mostly distinct with concrete discriminator terms, with only minor overlap risk against general web-testing skills, fitting the 'mostly distinct; minor overlap' anchor.

4 / 5

Total

14

/

20

Passed

Validation

93%

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

Validation15 / 16 Passed

Validation for skill structure

CriteriaDescriptionResult

frontmatter_unknown_keys

Unknown frontmatter key(s) found; consider removing or moving to metadata

Warning

Total

15

/

16

Passed

Repository
sickn33/agentic-awesome-skills
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.