CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

acceptance-test-buckets

Use when a dashboard test starts to use a helper from another file, when a new domain directory is added under internal/provider/, or when a pull request skips acceptance jobs it should run. Keeps .github/scripts/detect-test-scope.sh correct.

Quality

87%

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

SKILL.md
Quality
Evals
Security

Quality

Content

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

An exemplary lean, repo-specific skill: a decision table maps each triggering change to an exact script edit, a verifiable command with expected output is provided, and a brief 'Why' section explains the failure mode and its safety net. The only gaps are minor: the verification command is not explicitly framed as a post-edit step, and the deps-gates row is less concrete than the other two.

DimensionReasoningScore

Conciseness

Every token earns its place: table rows state the change and the exact edit with no padding, the code block is a single verifiable command, and the 'Why' section delivers non-obvious rationale ("The nightly run and every push to master run both buckets, so a miss shows up there") in three sentences. No explanations of concepts Claude already knows.

5 / 5

Actionability

Concrete, executable guidance throughout: "Add its name to `domains`", "Add that file to `shared`", and a copy-paste verification command with expected output. Not 5 because the location/format of `domains`, `shared`, and `deps` in the script is not shown, and the third row ("Add its jobs to the `deps` gates in `acceptance-tests.yml`") leaves which jobs and where unspecified.

4 / 5

Workflow Clarity

The condition-to-edit table makes the single action unambiguous per scenario, and the printf command with expected output ("# code=true dashboards=false rest=true deps=false") is a real validation checkpoint. Not 5 because that verification is presented as a standalone example rather than an explicit 'run this after your edit' step in a sequence.

4 / 5

Progressive Disclosure

At 24 lines with no external references needed (no references/, scripts/, or assets/ bundle exists), the body is well-organized into Trigger / Fix / Why sections with a decision table, which merits a 5 under the under-50-lines guideline for single-purpose skills.

5 / 5

Total

18

/

20

Passed

Description

82%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, repo-anchored description with an explicit 'Use when' clause containing three concrete trigger conditions and a clear third-person statement of what it maintains. The only weakness is that the 'what' side compresses the skill's actions into a single clause rather than enumerating the specific edits involved.

DimensionReasoningScore

Specificity

The description names the domain and one concrete maintenance action ("Keeps .github/scripts/detect-test-scope.sh correct") with concrete artifacts like "internal/provider/" and "acceptance jobs", but it lists only a single action rather than the several specific edits the skill performs, matching the '1-2 concrete actions, not comprehensive' anchor. Score 4 would require several specific actions enumerated, which is not present.

3 / 5

Completeness

Explicitly answers both questions: 'when' via three concrete trigger clauses ("Use when a dashboard test starts to use a helper from another file, when a new domain directory is added under internal/provider/, or when a pull request skips acceptance jobs") and 'what' via "Keeps .github/scripts/detect-test-scope.sh correct". This clearly matches the anchor requiring both what and when with concrete trigger phrases.

5 / 5

Trigger Term Quality

Natural phrases a contributor would actually say are present: "dashboard test", "helper from another file", "new domain directory", "pull request skips acceptance jobs", plus concrete paths like ".github/scripts/detect-test-scope.sh". Not 5 because common variations such as "CI", "test scope", or "acceptance tests" are missing.

4 / 5

Distinctiveness Conflict Risk

The description is anchored to repo-specific artifacts ("detect-test-scope.sh", "internal/provider/", "acceptance jobs") giving it a clear niche with distinct triggers and minimal conflict risk with any other skill.

5 / 5

Total

17

/

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

coralogix/terraform-provider-coralogix

Path

.claude/skills/acceptance-test-buckets/SKILL.md

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.