CtrlK
BlogDocsLog inGet started
Tessl Logo

improve-test-coverage

Improve test coverage for shell features and commands using reference test suites from yash, GNU coreutils, and uutils/coreutils

42

Quality

43%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

SecuritybySnyk

—

The risk profile of this skill

Fix and improve this skill with Tessl

tessl review fix ./.claude/skills/improve-test-coverage/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

55%Scale 1-3

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

This skill is exceptionally thorough and actionable with a well-designed multi-phase workflow including resumability, validation checkpoints, and detailed decision criteria for every step. However, it is severely over-long — the ~600+ lines of inline content waste significant context window budget. The monolithic structure with no progressive disclosure means the entire document must be loaded even for simple single-target runs, and much of the content (gap category tables, YAML format rules, duplicate detection heuristics) could be extracted into referenced files.

Suggestions

Extract the gap category tables (Step 5), YAML format documentation (Step 6), duplicate/low-value detection criteria (Step 7), and skip_assert_against_bash review protocol (Step 8) into separate referenced markdown files to reduce the main SKILL.md to an overview with clear pointers.

Remove redundant instructions — the 'do not stop' protocol is stated at least 3 times in different forms; consolidate into a single concise block.

Trim explanatory prose that Claude already knows — e.g., the detailed explanation of what PDF edge cases are, how git push works, what 'table-driven tests' means in Go. Focus on project-specific conventions only.

Consider splitting Phase B's per-target steps into a separate PHASE_B_STEPS.md file, keeping only the phase overview and step names in the main SKILL.md.

DimensionReasoningScore

Conciseness

This skill is extremely verbose at ~600+ lines. It over-explains execution protocols, repeats instructions multiple times (e.g., 'do NOT ask the user questions' appears in multiple forms), includes extensive tables for concepts Claude already understands (like what edge cases to test), and contains lengthy bash snippets for routine operations like git commit/push. The security preamble, while important, is also verbose. Much of the content could be condensed to 30-40% of its current size without losing actionability.

1 / 3

Actionability

The skill provides highly concrete, executable guidance throughout: specific bash commands for every operation, exact YAML format with complete examples, precise file paths, exact git commit message templates, exact PR comment templates, and detailed decision tables for every classification step. Every step has copy-paste ready commands.

3 / 3

Workflow Clarity

The three-phase workflow (Setup → Per-target loop → Finalization) is clearly sequenced with explicit step numbering, task dependencies, validation checkpoints (Step 10 runs tests, Step 12 runs CI fixes), feedback loops (fix and re-validate), and a durable progress tracker (COVERAGE_PROGRESS.md) for crash recovery. The resume protocol is well-defined with explicit fresh vs resume mode detection.

3 / 3

Progressive Disclosure

The entire skill is a monolithic wall of text with no references to supporting files. The gap categories tables, YAML format documentation, layer selection rubric, and duplicate detection criteria could all be split into separate reference files. With no bundle files provided and everything inline, this is a single massive document that must be loaded entirely into context even when only a subset of steps is relevant.

1 / 3

Total

8

/

12

Passed

Description

32%Scale 1-3

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 identifies a specific domain (shell test coverage using reference suites) but lacks concrete actions and explicit trigger guidance. It reads more like a project goal than a skill description, missing the 'when to use' clause entirely and not detailing the specific operations the skill enables.

Suggestions

Add an explicit 'Use when...' clause, e.g., 'Use when the user wants to port tests from yash or coreutils reference suites, improve shell command test coverage, or validate POSIX compliance.'

List specific concrete actions the skill performs, e.g., 'Ports reference tests from yash/GNU coreutils/uutils, identifies coverage gaps in shell builtins, generates test cases for shell commands.'

Include additional natural trigger terms users might say, such as 'shell tests', 'POSIX compliance testing', 'coreutils tests', 'shell builtin testing', or specific command names.

DimensionReasoningScore

Specificity

Names the domain (test coverage for shell features/commands) and mentions specific reference test suites (yash, GNU coreutils, uutils/coreutils), but doesn't list concrete actions beyond 'improve test coverage' — e.g., it doesn't specify what improving entails (writing tests, porting tests, analyzing gaps, etc.).

2 / 3

Completeness

Describes what it does at a high level ('improve test coverage') but has no explicit 'Use when...' clause or equivalent trigger guidance, and the 'what' itself is vague. Per rubric guidelines, a missing 'Use when' clause caps completeness at 2, and the weak 'what' brings it to 1.

1 / 3

Trigger Term Quality

Includes relevant keywords like 'test coverage', 'shell', 'yash', 'GNU coreutils', 'uutils/coreutils' which are useful but somewhat niche. Missing common user-facing terms like 'shell tests', 'POSIX compliance', 'test porting', or 'shell builtins' that users might naturally say.

2 / 3

Distinctiveness Conflict Risk

The mention of specific reference test suites (yash, GNU coreutils, uutils/coreutils) provides some distinctiveness, but 'improve test coverage for shell features' is broad enough to potentially overlap with general testing or shell development skills.

2 / 3

Total

7

/

12

Passed

Validation

81%

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation — 9 / 11 Passed

Validation for skill structure

CriteriaDescriptionResult

skill_md_line_count

SKILL.md is long (789 lines); consider splitting into references/ and linking

Warning

frontmatter_unknown_keys

Unknown frontmatter key(s) found; consider removing or moving to metadata

Warning

Total

9

/

11

Passed

Repository
DataDog/rshell
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.