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

58%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

Securityby

Passed

No findings from the security scan

Fix and improve this skill with Tessl

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

Quality

Content

57%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 highly actionable with concrete curl examples, MCP tool names, and response shapes, but suffers from duplicated endpoint documentation with conflicting auth env vars and lacks an explicit monitoring workflow. Progressive disclosure is adequate via external spec references but undermined by inline redundancy.

Suggestions

Reconcile the two parallel endpoint sections into one, using a single consistent auth env var (OMNIROUTE_KEY vs OMNIROUTE_TOKEN) and base URL convention.

Add a short sequenced monitoring workflow (e.g. health → circuit breakers → provider metrics → quota/budget) with an error-recovery checkpoint referencing the Errors section.

Move the bulk endpoint reference into a bundled reference file (or rely solely on the OpenAPI spec link) to reduce inline duplication.

Dimension	Reasoning	Score
Conciseness	Individual curl examples are lean, but the body duplicates two parallel endpoint sets (generated section using OMNIROUTE_TOKEN/localhost:20128 vs. migrated section using OMNIROUTE_KEY/$OMNIROUTE_URL) and includes some padded prose like the wordy compression-endpoint description, so it could be tightened.	3 / 5
Actionability	Provides copy-paste-ready curl commands with headers, a full POST body, JSON response shapes, and named MCP tools, but the inconsistent env-var names across sections introduce a minor gap in reliability.	4 / 5
Workflow Clarity	Content is organized by capability with a useful Errors section giving recovery guidance, but there is no explicit monitoring workflow sequence or validation checkpoints; the implied check-health-then-circuit-breakers-then-metrics flow is never sequenced.	3 / 5
Progressive Disclosure	References to the OpenAPI spec and the entry-point SKILL are clearly signaled and one level deep, but no bundle files exist and a large inline API reference is duplicated in-body rather than split into separate reference files.	3 / 5
	Total	13 / 20 Passed

Description

58%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 clearly conveys what the skill monitors with specific, domain-relevant terms, but it lacks any explicit 'when to use' trigger guidance. It is distinct and reasonably specific, yet not fully comprehensive in action verbs.

Suggestions

Add an explicit 'Use when...' clause, e.g. 'Use when checking OmniRoute provider health, diagnosing latency or circuit-breaker issues, or monitoring budget guard alerts.'

Broaden trigger terms with natural synonyms users might say (e.g. 'latency', 'slow responses', 'provider down', 'spend limit').

Vary action verbs beyond 'Monitor'/'Inspect' to reflect fuller capability coverage (e.g. 'Diagnose', 'Alert on', 'Reset').

Dimension	Reasoning	Score
Specificity	Names the monitoring domain plus several concrete targets ('circuit-breaker states', 'p50/p95/p99 latency metrics', 'budget guard alerts', 'connection cooldowns', 'model lockouts'), but the action verbs are limited to 'Monitor' and 'Inspect', leaving minor coverage gaps versus a fully comprehensive action list.	4 / 5
Completeness	The 'what' is clearly stated (monitor health, circuit breakers, latency, budget; inspect cooldowns and lockouts), but there is no 'Use when...' clause or equivalent trigger guidance, which caps completeness at 3 per the rubric.	3 / 5
Trigger Term Quality	Relevant domain keywords are present ('provider health', 'circuit-breaker', 'p50/p95/p99 latency', 'budget guard'), but the phrasing leans technical and omits common natural-language variations a user might actually say.	3 / 5
Distinctiveness Conflict Risk	The OmniRoute-specific monitoring niche (circuit breakers, p50/p95/p99, budget guards, model lockouts) is mostly distinct with only minor overlap risk against a generic health-check skill.	4 / 5
	Total	14 / 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: c3945a7

Reviewed: 3 days 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.