webapp-testing

Toolkit for interacting with and testing local web applications using Playwright. Supports verifying frontend functionality, debugging UI behavior, capturing browser screenshots, and viewing browser logs.

Quality

72%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

Securityby

Low

Low-risk findings worth noting

Fix and improve this skill with Tessl

tessl review fix ./skills/webapp-testing/SKILL.md

Quality

Content

78%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 highly actionable, lean skill body with an excellent decision tree and copy-paste-ready commands. Its main defects are the missing examples/ files advertised in the Reference Files section and the absence of an explicit verification step after automation runs.

Suggestions

Ship the advertised example files or remove the 'Reference Files' section — the body points to examples/element_discovery.py, examples/static_html_automation.py, and examples/console_logging.py, none of which exist in the bundle.

Add a verification checkpoint to the workflow, e.g., 'After running automation, take a screenshot or assert an expected element is present to confirm the action succeeded; if not, re-inspect the rendered DOM and retry with corrected selectors.'

Tighten the Best Practices section and fix the 'abslutely' typo — drop reminders Claude already knows ('Always close the browser when done', 'Use sync_playwright() for synchronous scripts') to save tokens.

Dimension	Reasoning	Score
Conciseness	The body is efficient and assumes competence — no explaining what Playwright is or how libraries work — with only minor trimmable content (the context-pollution rationale, the 'Always close the browser' and 'Use sync_playwright()' reminders, and the 'abslutely' typo).	4 / 5
Actionability	Fully executable, copy-paste-ready guidance: concrete `python scripts/with_server.py --server ... --port ... --` commands for single and multiple servers, a complete Playwright script skeleton, and concrete reconnaissance snippets like `page.screenshot(path='/tmp/inspect.png', full_page=True)`.	5 / 5
Workflow Clarity	The decision tree clearly sequences static vs. dynamic and server-running states with an error-recovery branch ('Fails/Incomplete → Treat as dynamic') and an explicit pitfall checkpoint (wait for networkidle before inspection), but there is no explicit post-action verification step to confirm the automation succeeded.	4 / 5
Progressive Disclosure	Sections are well organized with one-level references and `scripts/with_server.py` is a real black-box script, but the 'Reference Files' section points to an `examples/` directory (element_discovery.py, static_html_automation.py, console_logging.py) that does not exist in the bundle, leaving dangling references that break navigation.	3 / 5
	Total	16 / 20 Passed

Description

66%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 solid description with good concrete capabilities and natural trigger terms in third person, but it lacks any explicit 'when to use' clause, capping its completeness. Adding a Use-when sentence and a few more common synonyms (e.g., browser automation, e2e) would raise it further.

Suggestions

Add an explicit trigger clause, e.g., 'Use when testing or debugging a locally running web app, taking browser screenshots, or checking browser/console logs.'

Include common synonyms users would say, such as 'browser automation', 'end-to-end (e2e) testing', and 'localhost', to broaden trigger term coverage.

Make the first capability as concrete as the others, e.g., replace 'interacting with' with specific actions like 'clicking elements, filling forms, and navigating pages'.

Dimension	Reasoning	Score
Specificity	Lists several concrete actions ('capturing browser screenshots, and viewing browser logs', 'debugging UI behavior'), but 'interacting with' and 'verifying frontend functionality' remain somewhat generic, leaving minor gaps in coverage.	4 / 5
Completeness	The 'what' is clearly stated (Playwright toolkit with four named capabilities), but there is no 'Use when...' clause or equivalent explicit trigger guidance, which caps completeness at 3 per the rubric guidelines.	3 / 5
Trigger Term Quality	Includes natural phrases users would say ('testing local web applications', 'screenshots', 'browser logs', 'UI'), but omits common variations like 'browser automation', 'end-to-end/e2e', 'localhost', or 'console errors'.	4 / 5
Distinctiveness Conflict Risk	'local web applications using Playwright' carves a fairly distinct niche with a named tool, but there is minor overlap risk with generic browser-automation or frontend-development skills.	4 / 5
	Total	15 / 20 Passed

Validation

93%

Warnings & errors only

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

Validation — 15 / 16 Passed

Validation for skill structure

Criteria	Description	Result
frontmatter_unknown_keys	Unknown frontmatter key(s) found; consider removing or moving to metadata	Warning

	Total	15 / 16 Passed

Repository: Galaxy-Dawn/claude-scholar
Path: skills/webapp-testing/SKILL.md
Commit: 9037873

Reviewed: 2 days ago

Table of Contents

Discovery Implementation Validation

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.