CtrlK
BlogDocsLog inGet started
Tessl Logo
PluginPublic

ai-unified-process/aiup-playwright

AI Unified Process end-to-end layer - Playwright browser tests for use cases and test case journeys of any web UI

90

1.02x
Quality

97%

Does it follow best practices?

Impact

94%

1.02x

2 of 3 eval scenarios. Add 1 more for a full score.

SecuritybySnyk

Passed

No findings from the security scan

Overview
Quality
Evals
Security
Files

Quality

Content

92%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 dense, highly actionable instruction set: concrete commands, code, and naming contracts everywhere, a ten-step workflow with genuine failure-recovery mechanics, and a clean split of full templates into real one-level-deep bundle files. The only weakness is mild duplication between the 'Run Directly' section and the Workflow's later steps, plus a few justification sentences that assume Claude needs convincing rather than instructing.

Suggestions

De-duplicate the failure/reporting rules: the 'Run Directly or from /use-case-test' section and Workflow steps 8 and 10 each restate mechanics and the report contract; state them once and cross-reference the other location, as the section already does for /use-case-test's rules.

Trim justification sentences that explain why rather than what to do, e.g. 'They are accessibility-first and work directly against the HTML and ARIA output of a client-side framework' and the Vaadin shadow-DOM parenthetical, which repeats the frontmatter's routing to /vaadin-e2e-test.

DimensionReasoningScore

Conciseness

The body is almost entirely non-derivable, project-specific rules — no filler about what Playwright or E2E testing is — so it is far above the 'mostly efficient' anchor and sits at 'efficient; minor instances that could be trimmed'. Examples of trimmable material: the justification "They are accessibility-first and work directly against the HTML and ARIA output", the Vaadin shadow-DOM parenthetical that repeats the frontmatter, and overlap between the "Run Directly or from /use-case-test" section and Workflow steps 8 and 10, which restate the failure mechanics and reporting rules.

4 / 5

Actionability

Fully executable throughout: exact commands ("npm install -D @playwright/test", "npx playwright test --grep \"@UC-010\""), a complete copy-paste playwright.config.ts, concrete locator snippets ("getByRole('combobox', { name: 'Room Type' }).click()"), an assertions table with real examples, exact file paths and naming patterns ("src/test/resources/db/testdata/R__uc<id>_<slug>.sql"), and section-to-code mapping tables for both artifact types. Matches the copy-paste-ready anchor covering the common cases; nothing concrete is missing.

5 / 5

Workflow Clarity

The 10-step Workflow is clearly sequenced with explicit validation and feedback loops: step 4 checks for an existing file before writing, step 7 runs the tests, and step 8 is a full error-recovery loop ("On a failure, apply 'When a Test Fails'... Mechanics first: is the frontend and the backend up, does the dev proxy forward /api/*..." with --headed --debug and MCP tooling), ending in an explicit report contract (step 10). Data cleanup is covered with idempotency and ordering rules ("Make the cleanup idempotent: the test may have failed midway", "dependent records before their parents"), matching the checkpoint-and-recovery anchor.

5 / 5

Progressive Disclosure

The body is a well-organized overview that pushes both full test templates to one-level-deep bundle files, all of which exist and are clearly signaled with purpose: references/use-case.spec.ts.md, references/test-case.spec.ts.md, and references/markers.md; verified none of them nest further references. The unreferenced references/layer.md is an infrastructure row consumed by /stack via glob, not buried content for this skill. Matches the clear-overview, well-signaled, one-level-deep anchor.

5 / 5

Total

19

/

20

Passed

Description

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

An exemplary description: it states concrete capabilities in third person, gives explicit and natural trigger phrases, defines both artifact types it serves, and explicitly fences off the sibling Vaadin skill. The only arguable cost is length, but every clause carries scoping or triggering information rather than padding.

DimensionReasoningScore

Specificity

Multiple concrete actions are named with the exact mechanics: "Writes end-to-end browser tests in TypeScript with @playwright/test", "one test per scenario", "one test.step per row", "Locates elements by role, label, and text", "cleans up only the data the test created". Matches the 'lists multiple specific concrete actions; comprehensive coverage' anchor; nothing above it exists and score 4 would understate the coverage of what is produced and how.

5 / 5

Completeness

Both what and when are answered explicitly and concretely: the what in the opening sentences (test types, locator strategy, cleanup discipline) and the when in the explicit "Use when the user asks to ..." clause with literal trigger phrases plus the scope boundary ("not Vaadin"). This is the anchor-5 example pattern; it is not score 4 because the when is fully explicit rather than merely present.

5 / 5

Trigger Term Quality

Natural phrases a user would actually say are quoted verbatim: "write Playwright tests", "create e2e tests", "test in the browser", "automate a test case", "test a user journey", "automate TC-001", plus the broader category terms end-to-end, browser, and UI integration tests. This covers synonyms and the concrete artifact prefix (TC-001), matching the comprehensive-coverage anchor; score 4 would apply only if common variations were missing, and none are.

5 / 5

Distinctiveness Conflict Risk

The description carves out a clear niche and actively disambiguates against the closest sibling skill: "for any web UI that is not Vaadin" and "For a Vaadin UI use /vaadin-e2e-test", and separates the two artifact types (UC-XXX vs TC-XXX) from each other. Minimal conflict risk with the explicit redirects; not score 4, since even the overlap with a generic e2e skill is addressed by naming the @playwright/test tool and the stack.md gating.

5 / 5

Total

20

/

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.

Reviewed

On this page