omni-version-manager

Install, start, stop, restart, and update embedded services (9Router, CLIProxyAPI). Monitor service status, retrieve logs, and configure auto-start for local-only service endpoints.

Quality

64%

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-version-manager/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 an auto-generated, mostly executable endpoint reference with good per-endpoint curl examples, but it is verbose through heavy repetition, lacks sequenced workflows with validation, and inlines content that belongs in a separate reference file.

Suggestions

Move the bulk endpoint catalog into a separate reference file (e.g. references/endpoints.md) and keep SKILL.md as an overview with quick-start examples and a clearly signaled pointer, improving progressive disclosure and conciseness.

Factor out the shared auth header and 'LOCAL_ONLY — loopback only' note once at the top instead of repeating them in every curl block.

Document the request-body fields for mutating endpoints (e.g. what goes in the '{}' for auto-start or provider-expose) rather than deferring entirely to the OpenAPI spec.

Add a short sequenced quick-start workflow (install → start → GET status to verify → enable auto-start) with an explicit validation checkpoint after start.

Dimension	Reasoning	Score
Conciseness	Per-endpoint text is terse with no concept over-explanation, but the auth header block and 'LOCAL_ONLY — loopback only' are repeated across ~40 endpoints and could be factored out, so it could be tightened.	3 / 5
Actionability	Each endpoint ships a complete, copy-paste curl command, but request bodies are shown as '{}' with no field documentation and a few endpoints (e.g. /9router/models, /cliproxy/provider-expose) carry only a generated placeholder title with no description.	4 / 5
Workflow Clarity	The body is a flat endpoint catalog rather than a sequenced workflow, and destructive operations (stop/restart/update) lack validation checkpoints (e.g. verify status after start), so workflow clarity is capped at 3.	3 / 5
Progressive Disclosure	There is section structure per service and a single signaled one-level reference to the OpenAPI spec, but the ~600-line endpoint catalog is inlined in SKILL.md rather than split into a separate reference file.	3 / 5
	Total	13 / 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.

The description is specific and actionable with comprehensive concrete verbs, but it omits any 'Use when' trigger guidance, which caps completeness. It is distinct and largely uses natural language, though it leans on jargony service names.

Suggestions

Add a 'Use when...' clause naming the natural triggers (e.g. 'Use when managing local embedded services like 9Router or CLIProxyAPI — starting, stopping, updating, or checking their status and logs').

Mention all supported services (the body also covers mux, bifrost, and dario) or generalize the trigger terms so the description matches the skill's actual scope.

Include common synonyms or phrasings a user might say ('restart the proxy', 'tail service logs', 'turn on auto-start') to broaden trigger coverage.

Dimension	Reasoning	Score
Specificity	Lists multiple concrete lifecycle actions (install, start, stop, restart, update, monitor status, retrieve logs, configure auto-start) against named services, matching the comprehensive-coverage anchor.	5 / 5
Completeness	The 'what' is clear and concrete, but there is no 'Use when...' clause or equivalent trigger guidance, so completeness is capped at 3 per the rubric guideline.	3 / 5
Trigger Term Quality	Strong natural action verbs a user would say ('start', 'restart', 'check status', 'retrieve logs'), but no synonyms or 'Use when' phrasing and the named services lean technical, so a few natural terms are missing.	4 / 5
Distinctiveness Conflict Risk	A clear niche (managing specific embedded services via lifecycle actions) with distinct triggers; minor overlap risk with a generic service-management skill keeps it just below 5.	4 / 5
	Total	16 / 20 Passed

Validation

93%

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 — 15 / 16 Passed

Validation for skill structure

Criteria	Description	Result
skill_md_line_count	SKILL.md is long (666 lines); consider splitting into references/ and linking	Warning

	Total	15 / 16 Passed

Repository: diegosouzapw/OmniRoute
Path: skills/omni-version-manager/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.