CtrlK
BlogDocsLog inGet started
Tessl Logo

testland/compatibility-budget

Pure-reference for deciding how large a compatibility matrix a team can afford and for publishing that commitment - defines tier-1 (must work; per-PR) vs tier-2 (must work; nightly) vs tier-3 (should work; pre-release) vs unsupported, with example budgets per product type (web / desktop / mobile / library), the matrix-size cost / coverage trade-off, and 'what we support' external templates. Use when a team must cap how many browser / OS / runtime combos it commits to, or must publish a support policy. This is the BUDGET and support-statement gate - for the traffic-share analysis that picks WHICH specific browsers belong in each tier use browser-matrix-strategy-reference; to execute the resulting matrix use the runners browser-matrix-runner (bundled engines) or selenium-grid-4-runner (self-hosted).

75

Quality

94%

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

85%

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

A well-structured reference/gate skill: actionable templates and thresholds, a clearly sequenced workflow with budget-cost and review checkpoints, and clean one-level-deep progressive disclosure into a verified reference file. The main weakness is conciseness - the body is longer than necessary with some motivational and restated content.

Suggestions

Tighten the Overview: the four 'compatibility creeps' bullets restate the skill's motivation that is already implicit in 'When to use'; condense to one or two sentences.

Cut or merge the 'Worked example' section, since it re-applies the §2 template, §3 cost check, §4 publication, and §5 review that are already documented step-by-step; a one-line pointer would preserve the value.

Consider moving the full §4 markdown template into the reference file and leaving a short 'see references for the copy-paste support statement' note in the body to reduce inline length.

DimensionReasoningScore

Conciseness

The body is mostly purposeful and does not explain concepts Claude already knows, but at ~185 lines it could be tightened - the Overview motivation bullets and the 'Worked example' section restate mechanics already covered in §2, §4, and §6. It is not a 3 because not every token earns its place, and not a 1 because it avoids generic filler and Claude-known concept padding.

2 / 3

Actionability

Provides concrete, executable guidance: a 6-step 'How to use' procedure, a copy-paste §4 markdown support template, a CI-cost formula, and explicit telemetry thresholds ('if a configuration has <1% usage, Tier 3 or unsupported. If <0.1%, unsupported'). It is not a 2 because the guidance is specific and copy-ready rather than vague or pseudocode.

3 / 3

Workflow Clarity

The 'How to use' steps are clearly sequenced (pick product type → assign tiers → count combos vs budget → reconcile with telemetry → publish → schedule review) with an explicit checkpoint ('if CI cost exceeds budget, demote the lowest-value combos') plus a §5 quarterly review trigger→action table. It is not a 2 because validation checkpoints and the review feedback loop are explicit rather than implicit.

3 / 3

Progressive Disclosure

The body is an overview that points to a single, clearly-signaled, one-level-deep reference - [references/compatibility-budget-tiers.md] (verified to exist and contains the detailed tier tables) - with no nested-reference chains. It is not a 2 because content is appropriately split and navigation is easy, not monolithic or inline-heavy.

3 / 3

Total

11

/

12

Passed

Description

100%

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, information-dense description that hits every score-3 anchor: concrete actions, natural 'Use when' triggers, explicit what-and-when, and clear demarcation from sibling skills. Its only weakness is verbosity - it is markedly longer than the reference 'good' examples - but no dimension anchor penalizes length directly.

DimensionReasoningScore

Specificity

Lists multiple concrete actions - 'defines tier-1 (must work; per-PR) vs tier-2 (must work; nightly) vs tier-3 (should work; pre-release) vs unsupported', 'example budgets per product type', 'the matrix-size cost / coverage trade-off', and "'what we support' external templates" - matching the score-3 anchor for multiple specific concrete actions. It is not a 2 because the actions are comprehensive and domain-specific, not merely naming a domain.

3 / 3

Completeness

Clearly answers both 'what' (decides matrix size, publishes commitment, defines tiers, trade-off, templates) and 'when' via the explicit 'Use when' trigger clause. It is not a 2 because the 'when' is explicit, not merely implied.

3 / 3

Trigger Term Quality

The 'Use when a team must cap how many browser / OS / runtime combos it commits to, or must publish a support policy' clause gives good coverage of natural terms users would say (browser, OS, runtime, support policy, compatibility). It is not a 2 because common natural variations are present rather than only technical jargon.

3 / 3

Distinctiveness Conflict Risk

States a clear niche ('the BUDGET and support-statement gate') and explicitly routes adjacent work to siblings - 'browser-matrix-strategy-reference' for traffic-share analysis, 'browser-matrix-runner' / 'selenium-grid-4-runner' for execution - making conflict unlikely. It is not a 2 because the demarcation from neighboring skills is explicit rather than just 'somewhat specific'.

3 / 3

Total

12

/

12

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.

Validation16 / 16 Passed

Validation for skill structure

No warnings or errors.

Reviewed

Table of Contents