CtrlK
BlogDocsLog inGet started
Tessl Logo

testland/test-framework-blueprint

Build-an-X workflow that takes an SDET from no test suite to a complete framework design in seven steps - inventory the SUT, choose runner + language, directory layout + fixture architecture, object-model decision, test data + mocking wiring, reporting + CI integration, conventions doc + review gates - producing a written framework blueprint (directory tree, fixture list, chosen patterns, CI matrix) plus an implementation order. This is the whole-framework design workflow - not the Step 2 runner-choice decision on its own, not the Step 4 object-model pattern catalog it defers to, and not the scaffolder that generates the harness skeleton once the blueprint exists. Use when designing a test automation framework from scratch or re-architecting one that grew organically.

72

Quality

91%

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

86%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 strong build-an-X workflow: seven clearly sequenced steps, concrete commands and tables, per-step decision outputs, and a real worked example and fixture-mechanics reference correctly split out of the main file. The only room for improvement is trimming duplicated guidance and adding per-step validation beyond the Step 6 check.

DimensionReasoningScore

Conciseness

Mostly lean — tables, terse rules ('never share mutable fixtures across tests'), and no explanation of concepts Claude already knows — but it duplicates guidance ('prefer continuing with it unless there is a reason to switch' appears in both 'When to use' and Step 2) and spends tokens on meta-explanation of its own role versus sibling skills. Efficient with minor instances that could be trimmed, matching the 4 anchor rather than the every-token-earns-its-place 5.

4 / 5

Actionability

Copy-paste-ready specifics throughout: the exact directory tree, `reporter: [['junit', { outputFile: 'results.xml' }]]`, `npx playwright test --shard=1/4`, `gh run rerun <run-id> --failed`, and an example-shaped table for every step's 'Decision output'. For an instruction-only design skill, the guidance is fully executable and covers the common cases; not the 4 anchor because no concrete detail is missing for the worked stack.

5 / 5

Workflow Clarity

Seven explicitly numbered steps, each ending in a 'Decision output' checkpoint and keyed back to Step 1's inventory ('Every later decision keys off them'), with one explicit pre-record validation ('check every row has test retry 0 and distinct content') and a genuine drift-detection feedback loop in Step 7. It sits at 4 rather than 5 because explicit validation is confined to Step 6 — the other steps validate by recording the decision, not by verifying it.

4 / 5

Progressive Disclosure

The body keeps decisions inline and defers exactly two well-signaled, one-level-deep references ([references/fixture-mechanics.md] and [references/worked-example.md]), both of which exist in the bundle, stay one level deep, and open by pointing back to the SKILL.md steps they extend. This matches the clear-overview / one-level-deep anchor exactly.

5 / 5

Total

18

/

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.

A strong description: comprehensive concrete actions, an explicit 'Use when' clause, and explicit disambiguation from the three nearest competing skills. The only gap is trigger-term naturalness — 'Build-an-X workflow' and 'SDET' are author-side jargon rather than user-spoken phrases, and common synonyms like 'test harness' are missing.

DimensionReasoningScore

Specificity

It enumerates seven concrete actions ('inventory the SUT, choose runner + language, directory layout + fixture architecture, object-model decision, test data + mocking wiring, reporting + CI integration, conventions doc + review gates') plus concrete outputs ('directory tree, fixture list, chosen patterns, CI matrix') and 'an implementation order' — multiple specific concrete actions with comprehensive coverage, matching the 5 anchor.

5 / 5

Completeness

It explicitly answers what ('takes an SDET from no test suite to a complete framework design in seven steps... producing a written framework blueprint... plus an implementation order') and when ('Use when designing a test automation framework from scratch or re-architecting one that grew organically') with concrete trigger phrases — the 5 anchor verbatim.

5 / 5

Trigger Term Quality

Natural phrases a user would say are present ('test automation framework', 'from scratch', 're-architecting', 'no test suite'), but the opening leans on internal jargon ('Build-an-X workflow', 'SDET', 'SUT') and common synonyms like 'test harness' or 'set up automated tests' are absent. Good keyword coverage with a few natural terms missing — the 4 anchor, clearly above 'some relevant keywords' (3) and below comprehensive-with-synonyms (5).

4 / 5

Distinctiveness Conflict Risk

It fences off all three adjacent skills by name ('not the Step 2 runner-choice decision on its own, not the Step 4 object-model pattern catalog it defers to, and not the scaffolder that generates the harness skeleton'), claiming the whole-framework design niche with minimal conflict risk — the 5 anchor.

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