CtrlK
BlogDocsLog inGet started
Tessl Logo

webapp-testing

Start/reuse a local app, wait for readiness, inspect rendered state/console/network, act from observed selectors, and verify with evidence.

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 ./crates/tui/assets/skills/webapp-testing/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

72%

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

The body is concise and well-organized for a simple instruction-only skill, but the workflow is more descriptive than actionable and lacks concrete commands or error-recovery checkpoints. Adding tool/command specifics and a retry-on-failure step would raise actionability and workflow clarity.

Suggestions

Add concrete, executable guidance for at least the load-bearing steps: a readiness-poll command/pattern, a tool or approach for inspecting DOM/console/network, and how evidence is recorded.

Add a feedback loop after readiness inspection and after the flow (e.g. "If not ready, re-check readiness; if selectors are not found, re-observe before retrying") to satisfy the validation-checkpoint expectation.

Optionally name a default tool/approach (e.g. a headless browser or HTTP readiness probe) so Claude has copy-paste-ready starting points.

DimensionReasoningScore

Conciseness

The body is lean and assumes Claude's competence — sections are minimal, no concepts are over-explained, and every line is purposeful with no padding. It is not 2 because there is no unnecessary explanation to tighten.

3 / 3

Actionability

The workflow names concrete inspection targets (DOM/console/network) and gives a clear sequence, but provides no executable commands, tools, or examples (e.g. how to start the app, how to poll for readiness), so guidance is incomplete. It is above 1 because it does point at specific things to inspect rather than only describing abstractly.

2 / 3

Workflow Clarity

A clear five-step sequence is present with an explicit verification step ("Record evidence of pass/fail"), but there is no feedback loop or error-recovery checkpoint (e.g. what to do when readiness fails), so checkpoints are implicit. It does not reach 3 because anchor 3 requires explicit validation steps with feedback loops.

2 / 3

Progressive Disclosure

The skill is under 50 lines with no external references and is organized into clear sections (When to use, Non-goals, Workflow), which per the rubric guidelines lets progressive disclosure score 3 for a simple skill. No bundle files exist, so there are no nested or mis-signaled references to penalize.

3 / 3

Total

10

/

12

Passed

Description

67%

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 concrete with a clear niche, but lacks an explicit "Use when..." trigger and leans on operational jargon over natural user terms. Adding a trigger clause and friendlier keywords would lift completeness and trigger-term quality.

Suggestions

Append an explicit trigger clause, e.g. "Use when the user asks to test a web app flow end-to-end, debug a frontend in a real browser, or verify a UI change with evidence."

Add natural user-facing terms ("web app", "browser", "end-to-end test", "UI flow") alongside the operational jargon to improve trigger-term quality.

Keep the concrete action list but consider leading with the highest-traffic trigger term so the skill surfaces for common phrasings.

DimensionReasoningScore

Specificity

The description lists multiple concrete actions — "Start/reuse a local app, wait for readiness, inspect rendered state/console/network, act from observed selectors, and verify with evidence" — matching the anchor that expects several specific concrete actions rather than a single vague verb.

3 / 3

Completeness

It clearly answers "what" (start/reuse, wait, inspect, act, verify) but provides no "Use when..." clause or equivalent explicit trigger guidance, so per the judging guidelines completeness is capped at 2. It is above 1 because the "what" is explicit and concrete.

2 / 3

Trigger Term Quality

It uses operational jargon ("rendered state", "observed selectors", "readiness") rather than natural phrases a user would say (e.g. "test a web app", "browser test", "e2e"), so it has some relevant keywords but misses common variations. It does not reach 3 because the natural-user-term coverage is thin, and is above 1 because it does name concrete testing surface areas.

2 / 3

Distinctiveness Conflict Risk

The framing around a local app, rendered state, console/network, and observed selectors carves out a distinct browser/runtime testing niche unlikely to trigger for unrelated skills. It is not 2 because the scope is more specific than a generic "works with document files" example.

3 / 3

Total

10

/

12

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