omni-resilience

Monitor provider health, circuit-breaker states, p50/p95/p99 latency metrics, and budget guard alerts. Inspect connection cooldowns and model lockouts in real time.

Quality

63%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

Securityby

Medium

Suggest reviewing before use

Fix and improve this skill with Tessl

tessl review fix ./skills/omni-resilience/SKILL.md

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.

The body is a concrete, executable monitoring reference with good section structure and deferred OpenAPI detail, but it suffers from redundant overview/endpoint duplication and lacks an explicit diagnostic workflow. Tightening the duplication and framing a triage sequence would lift it further.

Suggestions

Remove the verbatim Overview repeat of the description and collapse the duplicated health-endpoint examples into one canonical block.

Add an explicit diagnostic triage sequence (e.g. check health → inspect circuitBreakers → review p95/p99 metrics → verify quota/budget) with a validation checkpoint.

Replace prose response descriptions on the health endpoint with a concrete JSON response example to match the metrics section.

Dimension	Reasoning	Score
Conciseness	Mostly efficient curl-based reference, but the Overview repeats the frontmatter description verbatim and the generated '## Endpoints' section duplicates the health endpoint already covered in the migrated section, creating noticeable redundancy that could be tightened.	3 / 5
Actionability	Provides copy-paste-ready curl commands with auth headers, a concrete POST body for the budget guard, JSON response shapes, and MCP tool names; minor gaps remain where some responses are described in prose rather than full JSON.	4 / 5
Workflow Clarity	Content is organized by topic in a sensible diagnostic order (health → circuit breakers → metrics → quota → budget → errors) and the Errors section gives recovery guidance, but there is no explicit sequenced workflow or validation checkpoints for diagnosing an incident.	3 / 5
Progressive Disclosure	Well-organized section headers and a clear one-level pointer to the OpenAPI spec ('docs/openapi.yaml', 'GET /api/openapi/spec') defer bulk schema detail out of the body; minor organization gaps from the duplicated health sections keep it just below 5.	4 / 5
	Total	14 / 20 Passed

Description

66%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 concrete and domain-specific with good trigger keywords, but it omits any explicit 'Use when...' guidance, which caps its completeness. Overall it is a solid, distinctive monitoring-skill description that would benefit from an explicit trigger clause.

Suggestions

Add an explicit 'Use when...' clause, e.g. 'Use when diagnosing provider outages, latency regressions, or budget-limit issues in OmniRoute.'

Broaden trigger-term coverage with synonyms users might say (e.g. 'rate limits', 'spend limits', 'provider errors').

Consider adding one more concrete action verb beyond Monitor/Inspect (e.g. 'Reset') to round out capability coverage.

Dimension	Reasoning	Score
Specificity	Lists several concrete monitoring targets ("provider health, circuit-breaker states, p50/p95/p99 latency metrics, and budget guard alerts", "connection cooldowns and model lockouts") but only two action verbs (Monitor, Inspect), leaving minor coverage gaps rather than fully comprehensive multi-action breadth.	4 / 5
Completeness	The 'what' is clear and concrete, but there is no 'Use when...' clause or equivalent explicit trigger guidance, which caps completeness at 3 per the judging guidelines.	3 / 5
Trigger Term Quality	Includes natural ops/monitoring terms a user would say ("provider health", "circuit-breaker", "latency", "budget guard", "model lockouts") with good coverage, though it lacks synonyms or common variations of these terms.	4 / 5
Distinctiveness Conflict Risk	The LLM-provider routing monitoring niche (circuit breakers, budget guard, model lockouts) is mostly distinct with only minor overlap risk against general monitoring skills.	4 / 5
	Total	15 / 20 Passed

Validation

100%

Warnings & errors only

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-resilience/SKILL.md
Commit: ea0cdc5

Reviewed: about 6 hours ago

Table of Contents

Discovery Implementation Validation

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.