CtrlK
BlogDocsLog inGet started
Tessl Logo

run-api-e2e-tests

Run e2e tests for the API service. Use when the user wants to run API E2E tests.

62

Quality

72%

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

Fix and improve this skill with Tessl

tessl review fix ./.cursor/skills/run-api-e2e-tests/SKILL.md
SKILL.md
Quality
Evals
Security

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.

The content is a strong, highly actionable runbook: every command is executable, the specific-test workflow is concretely sequenced, and there is no padding or concept explanation. The main weaknesses are verbatim command repetition (four copies of the same mocha invocation) and the absence of failure/recovery guidance in the workflow.

Suggestions

Define the mocha command once (or use a shell variable) and have the location-specific variants and Examples reference it, cutting roughly a third of the body's tokens.

Add a short failure-path note: what to do when the glob finds no matching file, or when a test fails (e.g., re-run the single test, check setup.ts requirements).

Clarify step 3 of the specific-test workflow with the actual check (e.g., 'ls src/**/<name>.e2e.ts' vs 'ls e2e/enterprise/**/<name>.e2e.ts') so location detection is deterministic.

DimensionReasoningScore

Conciseness

The body is lean and assumes Claude's competence (no explanations of mocha, e2e, or pnpm), but the full ~200-character mocha command is repeated verbatim four times across the location instructions and the Examples section. That repetition is minor over-inclusion that could be trimmed, matching the efficient-with-minor-trimming anchor rather than the every-token-earns-its-place anchor at 5.

4 / 5

Actionability

All commands are fully executable and copy-paste ready, including the exact glob patterns for finding test files, the env-prefixed mocha invocation for both source locations, and worked examples with real test filenames (trigger-event-preferences, billing). The only placeholder, <name-of-the-test>, is explicitly explained with replacement instructions.

5 / 5

Workflow Clarity

The specific-test workflow is a clear numbered sequence (find file, extract name, determine location, run command) with concrete commands. However, there are no validation checkpoints or error-recovery guidance (e.g., what to do when no file matches the glob, or when a test fails), keeping it at clear-sequence-with-minor-gaps rather than score 5's explicit feedback loops. Running tests is not a destructive or batch operation, so the score-3 cap does not apply.

4 / 5

Progressive Disclosure

The ~53-line body has well-organized sections and no bundle files, so no external references are needed. The minor gap is that the duplicated mocha commands and the two worked examples could be consolidated (or factored into a reference), leaving it just short of the clear-and-appropriately-split anchor at 5.

4 / 5

Total

17

/

20

Passed

Description

62%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 clear and correctly structured with an explicit 'Use when' clause, but it is thin: it describes a single action, offers no synonyms or variations on the trigger, and omits the novu-v2 scope that would distinguish it from generic test-running skills.

Suggestions

Add trigger variations users would actually say, e.g. 'Use when the user mentions e2e tests, end-to-end tests, novu-v2 tests, or wants to run a specific API test file'.

Mention the novu-v2 test pattern and the apps/api location in the description to distinguish this skill from other test-running skills.

Briefly enumerate the two modes of use (running all tests vs. targeting one specific test) to improve completeness.

DimensionReasoningScore

Specificity

The description names the domain ("API service") and one concrete action ("Run e2e tests"), matching the anchor for 1-2 concrete actions without comprehensive coverage. It does not list multiple capabilities (e.g., running all tests vs. a specific test, enterprise suites), so it falls below score 4.

3 / 5

Completeness

Both the what ("Run e2e tests for the API service") and an explicit when ("Use when the user wants to run API E2E tests") are present. However, the when clause merely restates the what rather than naming concrete triggering situations, so it does not reach the explicit concrete-trigger level of score 5.

4 / 5

Trigger Term Quality

"e2e tests" and "API E2E tests" are relevant keywords users would naturally say, but the description misses common variations and synonyms such as "end-to-end", "integration tests", or the novu-v2 pattern that this skill actually targets. This matches the anchor for some relevant keywords with missing variations, below the good-coverage anchor at 4.

3 / 5

Distinctiveness Conflict Risk

Naming a specific service ("API service") and test type ("e2e") makes it mostly distinct with only minor overlap risk against closely related test-running skills. It lacks a distinguishing qualifier such as "novu-v2" that would give it the clear niche of score 5, but it is more specific than the overlap-prone generality of score 3.

4 / 5

Total

14

/

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.

Repository
novuhq/novu
Reviewed

Table of Contents

Is this your skill?

If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.