CtrlK
BlogDocsLog inGet started
Tessl Logo

omni-api-keys

Create, list, rotate, and revoke OmniRoute API keys. Control per-key scopes, spending limits, and expiration. Keys gate access to all proxy and management endpoints.

61

Quality

71%

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-api-keys/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

80%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 body is a lean, well-structured API reference with executable curl examples and good deferred reference to the OpenAPI spec. Its weaknesses are stubbed request payloads for the mutating endpoints and the absence of validation checkpoints for destructive key operations like deletion and rotation.

Suggestions

Replace the `-d '{}'` stubs on POST and PATCH with a representative payload showing the scopes, spending-limit, and expiration fields the description advertises.

Add brief validation cues for destructive actions, e.g. 'Confirm the key is revoked/disabled before DELETE' and 'Verify rotation succeeded by calling GET /api/keys/{id}'.

Consider a one-line note on idempotency or error responses so Claude can handle failed curl calls without guessing.

DimensionReasoningScore

Conciseness

Lean and token-efficient: terse endpoint headers, minimal one-line descriptions, and curl snippets with no padding explaining what an API key or Bearer token is. Fits 'lean and efficient; assumes Claude's competence' (5).

5 / 5

Actionability

Every endpoint ships an executable curl command with the auth header, but POST/PATCH use `-d '{}'` empty bodies, leaving out the scopes/limits/expiration fields the description promises control over and deferring them to the OpenAPI spec. Fits 'mostly executable... with minor gaps' (4), not 5 because the key payload details are stubbed.

4 / 5

Workflow Clarity

This is a flat API reference rather than a multi-step workflow, but it includes destructive operations (DELETE, rotation) with no validation checkpoints (e.g. confirm rotation succeeded, verify key state before deletion). Per the rubric, missing validation for destructive operations caps workflow_clarity at 3 even for single-purpose skills.

3 / 5

Progressive Disclosure

No bundle files exist; the body is well-organized into Overview/Authentication/Endpoints/Payloads and cleanly defers detailed schemas to a one-level-deep reference (GET /api/openapi/spec or docs/openapi.yaml). As an under-50-line, well-organized single-purpose skill, this meets the simple-skill exception for a 5.

5 / 5

Total

17

/

20

Passed

Description

63%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 specific and well-scoped to OmniRoute key management, but it omits an explicit 'Use when...' trigger clause and relies on product jargon over user-natural language, capping completeness and trigger-term quality. Adding a usage trigger would materially raise the score.

Suggestions

Append an explicit trigger clause, e.g. 'Use when managing OmniRoute API keys, or when the user asks to create, rotate, revoke, or scope keys.'

Weave in user-natural synonyms for the domain (e.g. 'API tokens', 'credentials') so the description surfaces on natural phrasing, not just the product name.

Replace product-internal framing ('gate access to all proxy and management endpoints') with a brief, user-facing trigger cue.

DimensionReasoningScore

Specificity

Lists multiple specific concrete actions — 'Create, list, rotate, and revoke OmniRoute API keys' plus 'Control per-key scopes, spending limits, and expiration' — giving comprehensive coverage of the key-management domain. Not below 5 because coverage is broad and concrete; not a 4 because there are no meaningful gaps.

5 / 5

Completeness

Has a clear 'what' (concrete actions on keys) but no 'Use when...' trigger clause; 'Keys gate access to all proxy and management endpoints' is weak context, not usage guidance. Per the rubric, a missing explicit trigger clause caps completeness at 3.

3 / 5

Trigger Term Quality

'API keys' is a natural user term, but the rest leans on product-internal jargon ('OmniRoute', 'proxy and management endpoints', 'spending limits') rather than phrases a user would naturally say, and it omits common synonyms. Fits the 'some relevant keywords but missing common variations' anchor better than 4 (good coverage) because few user-natural terms are present.

3 / 5

Distinctiveness Conflict Risk

'OmniRoute API keys' carves a clear niche with minimal conflict risk, but the brand name carries most of the distinctiveness rather than the description itself. Fits 'mostly distinct; minor overlap risk' (4) better than the fully-distinct anchor (5).

4 / 5

Total

15

/

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.

Validation16 / 16 Passed

Validation for skill structure

No warnings or errors.

Repository
diegosouzapw/OmniRoute
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.