omni-settings

Read and update global application settings: system prompts, thinking budget, IP filters, payload rules, combo defaults, and require-login configuration.

Quality

61%

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-settings/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, well-structured API reference with executable curl examples, but it inlines a massive endpoint catalog, uses empty payload bodies for write operations, and lacks validation guidance for destructive/batch endpoints. Splitting the catalog into a reference file and adding verification steps would raise the weakest dimensions.

Suggestions

Move the bulk endpoint catalog into a `references/endpoints.md` file and keep SKILL.md as a concise overview pointing to it, improving both progressive disclosure and conciseness.

Replace placeholder `-d '{}'` bodies on key write endpoints (settings, ip-filter, payload-rules) with a representative real payload, or link each to the exact OpenAPI schema section.

Add explicit validation/verification steps and warnings for destructive and batch operations (purge-*, batch-delete, database/vacuum) so workflow clarity can exceed the cap of 3.

Dimension	Reasoning	Score
Conciseness	The body is a ~1390-line catalog that avoids explaining concepts Claude already knows, but it repeats identical auth-header blocks across 100+ endpoints and includes many zero-description stubs (e.g. "GET settings › database"), so it is mostly efficient yet could be tightened significantly by factoring shared headers or moving bulk endpoints to a reference.	3 / 5
Actionability	Every endpoint ships a copy-paste-ready curl command, and the curated thinking-budget section includes a real payload; however, the write endpoints use placeholder `-d '{}'` bodies with payloads deferred to the OpenAPI spec, a minor-to-moderate gap that keeps it below fully executable.	4 / 5
Workflow Clarity	This is a flat API reference with no multi-step workflow, and it exposes destructive/batch operations (purge-request-history, purge-call-logs, batch-delete, database/vacuum) with no validation or verification guidance, which per the rubric caps workflow clarity at 3.	3 / 5
Progressive Disclosure	Section headers (Overview, Authentication, Endpoints, Payloads) provide structure and the body points to `docs/openapi.yaml` and a thinking-budget guide, but the entire endpoint catalog is inlined in SKILL.md with no bundle files split out, so content that belongs in a separate reference is inline.	3 / 5
	Total	13 / 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 specific and enumerates concrete setting categories with natural trigger terms, but it omits any explicit "Use when..." guidance, capping its completeness. Adding a trigger clause would lift the weakest dimension.

Suggestions

Append an explicit trigger clause, e.g. "Use when the user asks to change global app settings such as system prompts, thinking budget, IP filters, payload rules, combo defaults, or require-login."

Broaden action verbs beyond "Read and update" to reflect concrete operations (e.g., "toggle require-login", "add or remove IP bans", "set the thinking budget") to push specificity toward comprehensive.

Add a few natural synonyms users might say (e.g., "rate limits", "auth settings", "proxy config") to improve trigger-term coverage.

Dimension	Reasoning	Score
Specificity	Names the domain and enumerates many concrete setting categories ("system prompts, thinking budget, IP filters, payload rules, combo defaults, and require-login configuration"), but the action verbs are limited to "Read and update" rather than a fuller set of concrete actions, leaving a minor coverage gap versus the comprehensive anchor 5.	4 / 5
Completeness	It clearly answers "what" (read and update global application settings with an enumerated list) but provides no "Use when..." clause or equivalent explicit trigger guidance, which per the judging guidelines caps completeness at 3.	3 / 5
Trigger Term Quality	Includes natural, user-sayable terms such as "system prompts", "thinking budget", "IP filters", "payload rules", and "require-login", giving good keyword coverage; a few natural synonyms or file-extension-style triggers are missing, so it sits just below the comprehensive anchor 5.	4 / 5
Distinctiveness Conflict Risk	The enumerated, specific setting categories give it a fairly distinct niche unlikely to trigger for unrelated skills; "global application settings" is still somewhat broad, so minor overlap risk with closely related admin skills keeps it just below 5.	4 / 5
	Total	15 / 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 (1391 lines); consider splitting into references/ and linking	Warning

	Total	15 / 16 Passed

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