CtrlK
BlogDocsLog inGet started
Tessl Logo

testland/launchdarkly-testing

Wraps LaunchDarkly server-side SDK testing patterns: TestData data source for hermetic tests (no network), file-based data source for fixture-driven tests, flag override patterns (TestData.update for per-test flag values), and assignment-integrity tests. Use when writing tests for code that uses LaunchDarkly flags; to decide which flag combinations those tests should cover in the first place, see feature-flag-test-matrix-reference.

72

Quality

90%

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

82%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-organized body: executable TypeScript throughout, a valuable anti-patterns table doubling as race/validation checkpoints, and honest limitations. The main improvements are tightening the low-value sections and stating the per-test workflow once explicitly.

Suggestions

State the canonical per-test sequence explicitly (init once → waitForInitialization → td.update per test → assert → client.close in afterAll) as a short numbered list, instead of leaving it implicit across examples and the anti-patterns table.

Cut or fold the 'Running' section's bare 'npm test' into the CI section, and trim the Overview's restatement of SDK behavior to a single clause.

Separate the npm and pip install lines by language label so the two-SDK install block is unambiguous.

DimensionReasoningScore

Conciseness

The body is lean and SDK-specific rather than explaining general concepts, but minor padding remains — the 'Running' section's bare 'npm test' adds nothing Claude doesn't know, and the Overview prose ('everything else about the SDK... runs the real code paths') could be trimmed to a clause.

4 / 5

Actionability

Every section gives copy-paste-ready, complete code: install commands, TestData initialization with waitForInitialization, variation/targeting/rollout tests, FileDataSource setup, teardown, and CI yaml, plus a concrete anti-patterns table with fixes. Common cases are fully covered; only the mixed npm/pip install block is slightly ambiguous.

5 / 5

Workflow Clarity

The install → init(wait) → td.update → assert → close(afterAll) sequence is evident from section order, and the anti-patterns table encodes ordering/race checkpoints ('Always update first', 'Always wait'). It falls short of a 5 because the canonical per-test sequence is never stated once explicitly as a numbered workflow; the reader must assemble it from examples and the anti-pattern table.

4 / 5

Progressive Disclosure

A single-file skill with well-organized sections and a clearly signaled References section linking external LaunchDarkly docs and sibling skills. It is ~180 lines with CI integration, targeting-rule, and rollout sections that could be split into reference files, so structure is good but not the ideal quick-start-plus-references split.

4 / 5

Total

17

/

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: third-person voice, concrete enumerated capabilities, an explicit 'Use when' trigger clause, and proactive boundary disambiguation. The only gap is a handful of missing natural synonyms (e.g., 'feature flag') that would broaden trigger coverage.

Suggestions

Add natural synonyms such as 'feature flags' or 'flag variations' to the trigger phrasing so users who say 'test my feature flags' match as readily as those who say 'LaunchDarkly flags'.

Consider naming the test frameworks or languages covered (Node/TypeScript, Python) in the description so users can quickly confirm applicability to their stack.

DimensionReasoningScore

Specificity

The description enumerates four concrete capabilities — 'TestData data source for hermetic tests (no network)', 'file-based data source for fixture-driven tests', 'flag override patterns (TestData.update for per-test flag values)', and 'assignment-integrity tests' — which comprehensively covers the skill's scope with concrete API-level detail.

5 / 5

Completeness

It explicitly answers both: what ('Wraps LaunchDarkly server-side SDK testing patterns: TestData data source... file-based data source... flag override patterns... assignment-integrity tests') and when ('Use when writing tests for code that uses LaunchDarkly flags'), with concrete trigger phrasing and explicit boundary routing to feature-flag-test-matrix-reference.

5 / 5

Trigger Term Quality

Natural phrases like 'LaunchDarkly server-side SDK', 'writing tests for code that uses LaunchDarkly flags', 'hermetic tests', and 'fixture-driven tests' match what a user would say, but common synonyms such as 'feature flag'/'feature flags' or 'variation' are absent, so coverage is good rather than comprehensive.

4 / 5

Distinctiveness Conflict Risk

It occupies a clear niche (LaunchDarkly-specific test tooling) with distinct triggers, and explicitly disambiguates the adjacent concern ('to decide which flag combinations those tests should cover in the first place, see feature-flag-test-matrix-reference'), minimizing wrong-skill activation.

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