CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

cli-eval

Create and run evaluation suites, watch live benchmark progress, view scorecards, compare model performance, and integrate eval runs with CI workflows from the CLI.

Quality

68%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide
SecuritybySnyk

Low

Low-risk findings worth noting

Fix and improve this skill with Tessl

tessl review fix ./skills/cli-eval/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

50%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 curated half of this skill is genuinely strong — executable examples, CI gating, and error recovery — but it is undermined by an auto-generated subcommand listing that duplicates and contradicts it and doubles the token cost. Deduplicating the two halves and moving the flag reference to a bundle file would fix the lowest-scoring dimensions at once.

Suggestions

Delete or merge the auto-generated 'Subcommands' section into the curated one, resolving the contradictory command forms ('eval get <suiteId>' vs 'eval get <runId>', duplicated 'eval list' with different flags).

Move the per-subcommand flag reference into a references/ file (e.g., references/cli-reference.md) and keep SKILL.md as an overview with common workflows.

Drop the Overview section that repeats the frontmatter description verbatim, and embed the poll-until-'completed' checkpoint as an explicit step in the run workflow instead of only mentioning it in Errors.

DimensionReasoningScore

Conciseness

The ~150-line auto-generated 'Subcommands' section duplicates the curated section ('eval list' documented twice with different flags, 'eval get <suiteId>' vs 'eval get <runId>'), the Overview repeats the frontmatter description verbatim, and 'Example:' blocks merely restate the heading command — substantial padding beyond the 'some unnecessary explanation' of a 3.

2 / 5

Actionability

The curated half gives concrete, executable commands (suite creation with flags, JSONL sample format, RUN_ID capture via jq, a CI score-threshold gate, and an Errors section with recovery commands), but examples in the generated half omit the flags they document (e.g., 'omniroute eval create' shown without --file), leaving minor gaps.

4 / 5

Workflow Clarity

The create → run → poll/watch → scorecard sequence is present, but it is split across two redundant sections with contradictory command forms ('eval run <suiteId>' vs 'eval suites run <suiteId>'), and validation checkpoints like polling until 'completed' live only in the Errors section rather than embedded as workflow steps — checkpoints are implicit, matching anchor 3.

3 / 5

Progressive Disclosure

No bundle files exist and the ~260-line body inlines a full subcommand/flag reference that belongs in a separate file, with only one external URL link; real section structure keeps it above anchor 2, but the inlined bulk reference prevents a 4.

3 / 5

Total

12

/

20

Passed

Description

71%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 specific, action-rich description that clearly conveys what the skill does, weakened only by the complete absence of any 'when to use this' trigger guidance and thin synonym coverage. Adding an explicit 'Use when...' clause would lift the two weakest dimensions.

Suggestions

Append a trigger clause such as 'Use when the user mentions evals, benchmarks, scorecards, or wants to compare model performance or gate CI on eval scores.'

Include natural synonyms users would say — 'evals', 'LLM testing', 'regression testing', 'benchmarking models' — alongside the existing terms.

Clarify the tool context early (e.g., 'using the omniroute CLI') so the description is distinguishable from generic eval-framework skills.

DimensionReasoningScore

Specificity

Lists five concrete actions ('create and run evaluation suites', 'watch live benchmark progress', 'view scorecards', 'compare model performance', 'integrate eval runs with CI workflows') with comprehensive coverage of the CLI eval domain, matching the top anchor rather than the 'minor gaps' anchor below it.

5 / 5

Completeness

The 'what' is clear and concrete, but there is no 'Use when...' clause or equivalent explicit trigger guidance, which per the judging guidelines caps completeness at 3.

3 / 5

Trigger Term Quality

Good natural domain keywords ('evaluation suites', 'benchmark', 'scorecards', 'CI workflows', 'eval runs') but common variations and synonyms like 'evals', 'testing LLM outputs', or 'regression testing' are missing, so it falls between the 'some relevant keywords' (3) and 'comprehensive synonym coverage' (5) anchors.

4 / 5

Distinctiveness Conflict Risk

The eval/benchmark/scorecard CLI niche is mostly distinct with only minor overlap risk against general testing or benchmarking skills; it lacks the sharply distinct triggers of a 5.

4 / 5

Total

16

/

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

diegosouzapw/OmniRoute

Path

skills/cli-eval/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.