CtrlK
BlogDocsLog inGet started
Tessl Logo

testland/feature-flag-test-matrix-reference

Feature-flag test matrix design: the flag-state combinatorics problem (N flags × M variants × K user-segments = N×M×K test cases), the canonical coverage strategies (pairwise interaction coverage; default-only smoke; full matrix; risk-driven matrix), the workflow for building the coverage suite from a flag inventory (grep-based inventory, per-flag classification, PICT pairwise generation, per-cell test skeletons), the dedicated kill-switch test categories (references/killswitch.md: graceful degradation, fail-static default, kill latency, mid-flight consistency), and the flags-vs-experiments distinction. Use when designing the flag-test surface for a new project, building or auditing flag-test coverage, or authoring kill-switch tests.

66

Quality

83%

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

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

The body is well-structured, dense, and largely actionable with concrete code, but is held back by missing validation/feedback loops in a batch-generation workflow and by a large mostly-inline reference body with only one split-out file. Minor conciseness redundancy between the two workflow sections also keeps it from the top tier.

Suggestions

Add an explicit validation/verification step to the 'Building the coverage suite' workflow (e.g., 'verify the generated matrix covers all known-interacting flag pairs before committing') to introduce a feedback loop and lift workflow_clarity above the batch cap.

Consolidate the overlapping 'How to use' and 'Building the coverage suite' sections into a single sequenced workflow, or clearly distinguish them as high-level vs implementation to remove redundancy and tighten conciseness.

Consider splitting the worked example and detailed strategy/anti-pattern tables into a separate reference file alongside killswitch.md to improve progressive disclosure and reduce the inline body length.

DimensionReasoningScore

Conciseness

The body is dense and table-driven without padding basic concepts, but includes minor over-explanation — the illustrative combinatorics arithmetic ('500... 1500') and two overlapping workflow sections ('How to use' vs 'Building the coverage suite') — fitting the 4 anchor 'efficient; minor instances of over-explanation that could be trimmed' rather than the 5 anchor's 'every token earns its place'.

4 / 5

Actionability

Provides concrete executable guidance (grep command, 'pict pict.txt > matrix.tsv', TypeScript test skeleton, YAML inventory) but the skeleton references undefined helpers like clientWith and authFlow, matching the 4 anchor 'mostly executable guidance; concrete code with minor gaps' rather than the 5 anchor's fully copy-paste-ready examples.

4 / 5

Workflow Clarity

Both workflows are clearly sequenced with some checkpoints (size-the-problem, commit-and-document-gaps), but there is no explicit validate/verify-coverage feedback loop, and the suite-building is a batch generation operation that the rubric caps at 3 when validation is missing — fitting the 3 anchor 'steps listed but validation gaps; checkpoints missing or implicit'.

3 / 5

Progressive Disclosure

references/killswitch.md is a real, well-signaled, one-level-deep reference with clear section structure and a References section, but the body is dense (~245 lines) with strategies, worked example, and anti-patterns all inline and only one split-out bundle file, matching the 4 anchor 'good structure; minor organization gaps' rather than the 5 anchor's fully appropriate content split.

4 / 5

Total

15

/

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.

The description is comprehensive and concrete, explicitly covering both what the skill does and when to use it with a clear Use-when clause. It is slightly held back by missing common trigger synonyms/platform names and minor overlap risk with closely related sibling skills.

DimensionReasoningScore

Specificity

Lists multiple concrete actions with comprehensive coverage — 'grep-based inventory, per-flag classification, PICT pairwise generation, per-cell test skeletons' and 'graceful degradation, fail-static default, kill latency, mid-flight consistency' — matching the anchor for multiple specific concrete actions rather than the 4 anchor's 'minor gaps'.

5 / 5

Completeness

Explicitly answers both what (combinatorics, coverage strategies, suite-building workflow, kill-switch categories, flags-vs-experiments distinction) and when ('Use when designing the flag-test surface for a new project, building or auditing flag-test coverage, or authoring kill-switch tests'), with a present Use-when clause so the 3-cap does not apply.

5 / 5

Trigger Term Quality

Includes natural terms a user would say ('feature-flag test matrix', 'flag-test coverage', 'kill-switch tests', 'auditing flag-test coverage') but omits common synonyms/platforms like 'rollout testing', 'LaunchDarkly', or 'A/B flags', fitting the 4 anchor's 'good keyword coverage; a few natural terms missing' rather than the 5 anchor's comprehensive synonym coverage.

4 / 5

Distinctiveness Conflict Risk

Occupies a clear niche (flag-test matrix design) but explicitly borders on closely related sibling skills it names — launchdarkly-testing, openfeature-sdk-testing, and the flags-vs-experiments distinction near ab-test-validity-checklist — giving minor overlap risk that fits the 4 anchor rather than the 5 anchor's 'minimal conflict risk'.

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.

Validation16 / 16 Passed

Validation for skill structure

No warnings or errors.

Reviewed

Table of Contents