CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

omni-models

Query available AI models across all configured providers. List models, resolve model aliases, and browse the full model catalog including provider-specific variants.

Quality

69%

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 ./skills/omni-models/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

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

A reasonably efficient, well-organized API reference with executable curl commands for every endpoint. It falls short on executable completeness — POST payloads are empty placeholders and schemas are deferred to an external spec — and on decision guidance, since near-duplicate listing endpoints are listed without explanation of when to use each.

Suggestions

Replace the empty "-d '{}'" POST bodies with one concrete, representative request per endpoint (e.g., a /api/v1/models/query body showing capability, min_context, kind, and q filters).

Add a short decision guide or table differentiating /api/v1/models, /api/models, /api/models/catalog, and /api/models/openrouter-catalog so the reader knows which to call when.

Include a trimmed sample response for at least the primary listing endpoint, or ship the referenced schema (docs/openapi.yaml) inside the skill as a reference file so the Payloads section's pointer resolves.

DimensionReasoningScore

Conciseness

The body is lean — no concept explanations, direct endpoint listings, and executable curl commands — with only minor trim candidates: the Overview duplicates the description verbatim and stub headings like "POST models › test" and "GET models › <model>" add tokens without information.

4 / 5

Actionability

GET endpoints are copy-paste ready, but all four POST examples send an empty body ("-d '{}'") with no field guidance, and the Payloads section defers entirely to an external OpenAPI spec not included in the bundle — missing key request details rather than minor gaps.

3 / 5

Workflow Clarity

The auth-then-call structure is present, but four overlapping listing endpoints (/api/v1/models, /api/models, /api/models/catalog, /api/models/openrouter-catalog) are never differentiated, so selecting the right one is guesswork, and no response examples are given to verify results against.

3 / 5

Progressive Disclosure

No bundle files exist, and the Overview/Authentication/Endpoints/Payloads sections are well organized with a single one-level pointer to the OpenAPI spec; docked from 5 only because the referenced docs/openapi.yaml is not part of the skill and its availability is unverified.

4 / 5

Total

14

/

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.

A clear, specific, third-person description of what the skill does, with good natural keyword coverage. Its main weakness is the complete absence of any 'when to use' trigger guidance, and it lacks distinctive anchoring (no product name or context) that would separate it from generic model-selection skills.

Suggestions

Append an explicit trigger clause, e.g.: "Use when the user asks which models are available, wants to list or compare models across providers, or needs to resolve a model alias to its concrete ID."

Mention the alias-management and model-testing capabilities (or drop them from the served API) so the description's coverage matches the skill's actual surface.

Add a distinguishing context term (e.g., the product/deployment name such as "Omniroute") so the description does not overlap with generic LLM model-selection skills.

DimensionReasoningScore

Specificity

Lists several concrete third-person actions ("Query available AI models", "List models", "resolve model aliases", "browse the full model catalog including provider-specific variants"), matching the 'several specific actions; minor gaps' anchor rather than the comprehensive-coverage anchor, since alias creation and model-testing capabilities go unmentioned.

4 / 5

Completeness

The 'what' is clearly stated (query, list, resolve aliases, browse catalog) but there is no 'Use when...' clause or equivalent explicit trigger guidance, which the judging guidelines cap at 3.

3 / 5

Trigger Term Quality

Natural terms like "list models", "model catalog", "model aliases", and "available AI models" are present, but common user phrasings such as "which models", "compare models", or "model routing" are missing — good coverage with a few natural terms absent.

4 / 5

Distinctiveness Conflict Risk

"Query available AI models across all configured providers" is somewhat specific, but it overlaps with the broad space of model-selection/provider skills and names no product or deployment context, so it could still trigger for the wrong skill.

3 / 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

diegosouzapw/OmniRoute

Path

skills/omni-models/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.