CtrlK
BlogDocsLog inGet started
Tessl Logo
PluginPublic

testland/test-framework-architecture-audit

Use for any question or task about reviewing a test automation framework's structure, such as before a big refactor or after years of growth without review, when its written conventions may no longer match the code. Grades eight axes PASS, WARN or FAIL: page objects, base classes, fixtures, helpers, naming, waits and retries, convention drift and CI.

Quality

85%

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

Overview
Quality
Evals
Security
Files

Quality

Content

75%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, well-structured audit methodology: every axis has a measurement procedure, numeric bands, and a complete output format, with the bulky worked example correctly split into a one-level-deep reference file. The main cost is token weight — extensive block quotes and per-cut rationale prose make it noticeably longer than the operational core requires.

Suggestions

Trim the multi-sentence block quotations from Fowler, Selenium, Cypress, and Playwright down to the operative rule plus a citation link — the A1 section alone carries three full quotes where the rules and their citations would carry the same authority at a fraction of the tokens.

Move the per-cut reasoning paragraphs (e.g., the blast-radius arithmetic for the depth-2 limit, the 300-line module rationale) into references/audit-detail.md, keeping only the cut values inline since the output format already mandates printing every convention with its value.

Condense the 'What this owns, and what it does not' boundary section (~30 lines including the three-capability table) to the table plus one or two sentences, since the disambiguation examples largely repeat what the table's rows already state.

DimensionReasoningScore

Conciseness

The body is dense and operational, but multi-paragraph rationales for every numeric cut ("The reasoning is blast radius, and it is arithmetic rather than taste: every class in the chain is a place a change can originate") and full block quotations from Fowler, Selenium, and Playwright run longer than execution requires. It avoids explaining concepts Claude already knows (it explicitly declines to restate what a Page Object is), so it sits above anchor 2, but the verbosity exceeds anchor 4's "minor instances".

3 / 5

Actionability

Every axis carries a concrete measurement procedure ("Count the distinct explicit timeout values. Three or more means nobody owns the timeout policy"), a numeric banding table, an exact output template with placeholders, and a worked example in the reference file covering a common case (Playwright + TypeScript). For an instruction-only skill the guidance is fully executable with no gaps — even file-versus-test counting is specified.

5 / 5

Workflow Clarity

The workflow is well sequenced: explicit preconditions ("Before scoring: what the baseline is"), ordered axes A1–A8, an explicit rollup rule, a ranked fix order, and conditional checks such as "Ask whether a migration is running before scoring A5 and A7". It scores 4 rather than 5 because the sequence is distributed across sections rather than presented as one explicit step list with validation checkpoints, though the read-only nature of the audit means the destructive-operation cap does not apply.

4 / 5

Progressive Disclosure

The single reference ("[references/audit-detail.md](references/audit-detail.md)") is real, clearly signaled for exactly what it contains (worked audit plus anti-pattern table), and nests no further references — one level deep. It scores 4 rather than 5 because the ~455-line main file still inlines content (lengthy source quotations, boundary discussion) that could itself be externalized.

4 / 5

Total

16

/

20

Passed

Description

88%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 strong description that explicitly answers both what (grade eight named axes) and when (framework structure review, pre-refactor, post-growth) with concrete trigger scenarios. Its only weaknesses are modest: a few missing natural synonyms and residual overlap risk against sibling audit skills on generic phrasing.

DimensionReasoningScore

Specificity

The description enumerates all eight concrete measurement targets ("page objects, base classes, fixtures, helpers, naming, waits and retries, convention drift and CI") plus the grading scheme ("PASS, WARN or FAIL"), giving comprehensive coverage of what the skill does with no gaps in the axis list.

5 / 5

Completeness

Both halves are explicit: the "Use for any question or task about..." clause with concrete scenarios ("such as before a big refactor or after years of growth without review, when its written conventions may no longer match the code") answers when, and the eight-axis enumeration answers what. The when-clause is specific rather than generic, matching anchor 5 rather than 4.

5 / 5

Trigger Term Quality

Natural phrases like "reviewing a test automation framework's structure", "before a big refactor", and "after years of growth without review" would plausibly be said by users, but common synonyms such as "audit", "test framework", or "tech debt" are missing. Good coverage, not comprehensive — anchor 4, clearly above 3 and short of 5's synonym completeness.

4 / 5

Distinctiveness Conflict Risk

"Test automation framework's structure" carves a clear niche distinct from per-file review, but closely related skills (suite-level audits, general code review) could still capture generic "review my tests" phrasing since the description alone does not fully disambiguate them. Mostly distinct with minor overlap risk — anchor 4, not 5.

4 / 5

Total

18

/

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