CtrlK
BlogDocsLog inGet started
Tessl Logo

testland/framework-choice-advisor

Reference catalog for picking a test automation framework or QA tool - covers Playwright / Cypress / Selenium / WebdriverIO / Appium / Espresso / XCUITest / RestAssured / Karate / k6 / Locust with side-by-side tradeoffs on speed, cross-browser, mobile, parallelisation, language support, ecosystem maturity, CI integration; a decision tree for matching project NFRs to framework choice; and reference directory / fixture / CI layouts for the chosen stack. references/ extends the same decision to commercial procurement (a seven-axis vendor evaluation matrix for TCM platforms, no-code tools, and visual-regression services) and to recording the outcome (an ADR-based tool-selection decision record with signal, one recommendation, and flip conditions). This is the **upstream selection step**: it decides which tool to adopt, not how to configure a tool already chosen, and not how to rebalance the unit / integration / E2E mix of an existing suite. Use when starting a new test-automation suite from scratch, evaluating commercial QA vendors, or writing down a tool decision.

67

Quality

84%

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

67%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 well-structured decision-support skill with a clear sequence, concrete conventions, and a healthy three-file reference layer. Its main weaknesses are unquarantined point-in-time market claims that pad the token budget, and fully-inlined matrices that make SKILL.md carry more than the overview role.

Suggestions

Move the dated market framing ('2026-recommendation tree', 'fastest-growing 2024-26') into a clearly labeled point-in-time section or the Limitations section, and drop trivia like the Puppeteer-origin aside.

Extract the per-layer matrices (mobile native, API/contract, performance) into a reference file, keeping only the web-E2E matrix and the recommendation tree in SKILL.md.

Add an explicit checkpoint after Step 1 (e.g. 'confirm the ranked NFR scores with the team before consulting the matrix') so the workflow has a visible validation gate.

DimensionReasoningScore

Conciseness

The body is mostly efficient tables, but carries time-sensitive framing ('2026-recommendation tree', 'fastest-growing 2024-26', 'the most common 2026 migration') not quarantined in a stale/deprecated section, plus some trivia Claude already knows ('the team that built Puppeteer started Playwright', 'Google's first-party. In-process, fast, deterministic.') and a 12-entry links list with explanatory asides. It could be tightened without losing meaning.

3 / 5

Actionability

Concrete, executable guidance throughout: score each NFR axis 1-5, a recommendation tree with explicit mappings, specific CI conventions ('Playwright `--shard=X/Y`', "trace: 'on-first-retry'", 'Retry once on first failure'), and pointers to real reference files. Falls short of 5 only because the NFR-to-matrix linkage and layout adoption steps lack a worked example.

4 / 5

Workflow Clarity

Steps 1-8 are clearly sequenced (frame NFRs → matrices → layouts → CI → defer → vendors → record), and Step 6's deferral conditions plus the anti-patterns table act as checkpoints. Validation is implicit rather than explicit — there is no 'confirm the scored NFRs before consulting the matrix' gate, and the retry/triage feedback loop lives in a convention table rather than the workflow.

4 / 5

Progressive Disclosure

Three real reference files are each linked once, one level deep, and clearly signaled ([references/directory-layouts.md], [references/vendor-evaluation.md], [references/decision-record-format.md]). Good, but the two large tradeoff matrices (Steps 2-3) are fully inlined in SKILL.md; a catalog this size could move the per-layer matrices to a reference file and keep only the decision tree inline.

4 / 5

Total

15

/

20

Passed

Description

92%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 excellent description: concrete capabilities, explicit use-when triggers, and an explicit boundary against adjacent configuration skills. The only gap is a handful of natural synonyms a user might say instead of the ones included.

Suggestions

Add one or two high-frequency user phrasings such as 'E2E testing framework' or 'migrating a Selenium suite' to the trigger terms.

Consider trimming the full eleven-tool list to the most-mentioned entries; the tradeoff axes alone already convey the catalog's scope.

DimensionReasoningScore

Specificity

The description lists multiple concrete capabilities: 'side-by-side tradeoffs on speed, cross-browser, mobile, parallelisation, language support, ecosystem maturity, CI integration', 'a decision tree matching project NFRs to framework choice', 'seven-axis vendor evaluation', and 'ADR-based tool-selection decision record'. Coverage is comprehensive with no vague filler language.

5 / 5

Completeness

Both 'what' (a reference catalog covering a tool matrix, decision tree, layouts, vendor evaluation, and ADR format) and 'when' ('Use when starting a new test-automation suite, evaluating commercial QA vendors, or writing down a tool decision') are explicitly and concretely stated.

5 / 5

Trigger Term Quality

Strong natural triggers ('picking a test automation framework', 'starting a new test-automation suite', 'evaluating commercial QA vendors') plus eleven named tools users would mention. A few common phrasings are missing, e.g. 'E2E framework', 'load testing tool', or 'migrating from Selenium', so it falls just short of the comprehensive-synonyms anchor.

4 / 5

Distinctiveness Conflict Risk

It draws a sharp boundary — 'This is the upstream selection step: it decides which tool to adopt, not how to configure one already chosen' — giving it a clear niche distinct from per-framework configuration skills, with triggers unlikely to fire for the wrong skill.

5 / 5

Total

19

/

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

Table of Contents