CtrlK
BlogDocsLog inGet started
Tessl Logo
PluginPublic

testland/k6-load-testing

Use whenever HTTP, WebSocket or gRPC load tests should be written in JavaScript with k6, or a k6 threshold passes but the system still feels slow: VU scripts with checks, stages for ramps, thresholds on p95 latency and errors as the CI gate, and how to read tail latency and coordinated omission.

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

92%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 a model skill document: runnable code at every step, tables instead of prose, explicit pass/fail gate semantics, and detail correctly pushed into two real, well-summarized one-level-deep reference files. The only defect is slight redundancy (repeated VU-iteration semantics and repeated '(Per [k6-running])' citations) keeping it just short of fully lean.

DimensionReasoningScore

Conciseness

The body is dense and assumes competence — compact tables for stage patterns, aggregation methods, CLI flags, and anti-patterns, with no padding about what load testing is. Minor trims remain: 'runs once per virtual-user iteration' is stated twice (once in the intro, again after the minimal script) and the '(Per [k6-running][running].)' citation is repeated after several blocks, fitting the 'efficient with minor over-explanation' anchor rather than the lean level 5.

4 / 5

Actionability

Everything is copy-paste executable: a complete minimal script, working stages/thresholds/abortOnFail options blocks, concrete run commands ('k6 run --vus 10 --duration 30s script.js'), a flags table, a summary-export JSON shape, and a full jq gate-report command. The common cases (author, run ad-hoc, run in CI, parse the gate result) are each covered with runnable artifacts.

5 / 5

Workflow Clarity

The section order mirrors the real lifecycle (Install → Author → Run → Parse → CI → Interpret → Limitations), and validation checkpoints are explicit: thresholds 'exit non-zero - the canonical CI gate signal', abortOnFail with delayAbortEval as mid-run error recovery, a jq PASS/FAIL report for parsed summaries, and an anti-patterns table acting as a pitfall checklist. This matches the anchor requiring clear sequence with explicit validation and feedback loops.

5 / 5

Progressive Disclosure

Verified against the actual bundle: references/ci-integration.md (real 54-line GitHub Actions workflow) and references/latency-percentiles.md (real 266-line interpretation workflow) both exist, are one level deep, and are clearly signaled in the body with content summaries of what each contains. SKILL.md stays a genuine overview while detail is appropriately split out, matching the top anchor.

5 / 5

Total

19

/

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.

The description is exemplary: it pairs an explicit 'Use whenever' trigger clause (including the nuanced 'threshold passes but the system still feels slow' case) with a concrete, comma-separated capability list in third-person voice. Its only gap is omission of the performance-testing synonym family (stress/soak test, benchmarking), which slightly limits natural-trigger coverage.

DimensionReasoningScore

Specificity

Lists multiple concrete capabilities spanning the full workflow — 'VU scripts with checks', 'stages for ramps', 'thresholds on p95 latency and errors as the CI gate', 'read tail latency and coordinated omission' — with no vague filler. Coverage is comprehensive across authoring, gating, and interpretation, matching the top anchor rather than the 'minor gaps' level 4.

5 / 5

Completeness

Explicitly answers 'when' with concrete triggers ('Use whenever HTTP, WebSocket or gRPC load tests should be written in JavaScript with k6, or a k6 threshold passes but the system still feels slow') and 'what' with the enumerated capabilities after the colon. This matches the anchor requiring both what and when with concrete trigger phrases.

5 / 5

Trigger Term Quality

Includes the tool name 'k6' plus strong natural phrases users would say ('load tests', 'p95 latency', 'threshold', 'CI gate', 'tail latency'). A few natural synonyms are missing — 'performance testing', 'stress test', 'soak test', 'benchmarking' — so it falls just short of the comprehensive-synonym level 5 anchor while clearly exceeding level 3.

4 / 5

Distinctiveness Conflict Risk

Names the specific tool (k6), language (JavaScript), and protocols (HTTP, WebSocket, gRPC), giving it a clear niche with distinct triggers. It would not fire for JMeter/Gatling/Locust or general performance contexts, matching the minimal-conflict-risk 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

On this page