oma-observability

Design or troubleshoot telemetry, SLOs, and incident diagnostics. Route to the relevant signal, system boundary, or vendor guide.

Quality

60%

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 ./.agents/skills/oma-observability/SKILL.md

Quality

Content

67%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 well-structured router skill: intent classification, a concrete route table, explicit guardrails with validation checkpoints, and disciplined loading instructions that keep detail in referenced files. Its main weaknesses are ceremony sections that inflate token cost without adding actionability, and the inability to verify the referenced resource files since no bundle was provided.

Suggestions

Cut the "Logical Operations" SSL-primitive table and compress the Scenes/Transitions scaffolding into the existing canonical workflow path — they restate the routing logic in abstract vocabulary without adding guidance.

Move the per-skill integrations table and the versioning/deprecation detail into a resource file (e.g. resources/integrations.md) and keep a one-line pointer, keeping SKILL.md strictly a routing overview.

Verify the resources/ tree ships with the skill bundle; every route in the Routes table points to a resources/ file, so a missing bundle breaks all actionable navigation.

Dimension	Reasoning	Score
Conciseness	Genuinely useful routing content ("When NOT to use", Routes table, Guardrails) is mixed with ceremony that adds little actionable value, such as the "Actions \| SSL primitive \| Evidence" table and the Scenes/Transitions scaffolding ("Notify result \| NOTIFY \| Routed recommendation"). It is not 2 because most sections carry domain-specific routing substance, and not 4 because the SSL-primitive and scene formalism is padding Claude does not need.	3 / 5
Actionability	The Routes table maps each intent (setup, migrate, investigate, alert, trace, tune, route) to specific primary and fallback files, guardrails give concrete defaults ("Use W3C Trace Context by default", "Apply PII redaction and sampling-aware baggage controls at collection"), and an invocation example is provided. It is not 5 because it contains no executable commands or config snippets and some guidance ("Route vendor/category") stays abstract, and not 3 because the navigation-level guidance is specific and covers the common cases.	4 / 5
Workflow Clarity	The Entry → PREPARE/ACQUIRE/REASON/ACT/VERIFY/FINALIZE sequence includes an explicit VERIFY checkpoint ("pipeline health, clock synchronization, cardinality limits, and retention... Record checks that could not run") and a failure-and-recovery section with feedback loops ("If telemetry samples are missing, provide instrumentation/collection steps before analysis"). It is not 5 because steps are named scenes rather than explicit commands and the detailed checklist is delegated to an external file.	4 / 5
Progressive Disclosure	The body is an overview with a well-signaled, one-level-deep reference index grouped by transport/layers/boundaries/signals, plus an explicit load-order protocol ("Read resources/execution-protocol.md first... Do not load all transport, layer, boundary, and signal guides together"). It is not 5 because no bundle files were provided to verify the resources/ paths, and some inline content (the full integrations table, the SSL-primitives table) could live in a resource file.	4 / 5
	Total	15 / 20 Passed

Description

53%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 uses third person and names a coherent domain, but it is capped by the absence of any explicit use-when guidance and by missing the field's most natural trigger terms (observability, monitoring, metrics, logs, traces). It reads as a moderate-quality router description with clear distinctiveness but incomplete trigger coverage.

Suggestions

Add an explicit trigger clause, e.g. "Use when the user mentions observability, telemetry, metrics, logs, traces, OTel, SLOs, alerting, or incident investigation."

Include the most common natural synonyms — observability, monitoring, metrics, logs, traces, OpenTelemetry/OTel — so the skill triggers on the phrases users actually say.

List one or two more concrete actions (e.g., "tune collector transport", "write burn-rate SLO alerts") to sharpen the what-clause beyond generic design/troubleshoot verbs.

Dimension	Reasoning	Score
Specificity	"Design or troubleshoot telemetry, SLOs, and incident diagnostics" names the domain and a few actions, but the verbs are generic and concrete capabilities like metrics/logs/traces setup, alerting, or migration are absent. It is not 4 because it lacks the several distinct, specific actions of that anchor, and not 2 because the domain and multiple actions are explicitly named.	3 / 5
Completeness	The "what" is clear (design/troubleshoot telemetry, SLOs, incident diagnostics; route to signal/boundary/vendor guide), but there is no "Use when..." clause or equivalent explicit trigger guidance, which caps completeness at 3. The second sentence describes routing behavior, not when to invoke the skill.	3 / 5
Trigger Term Quality	"telemetry", "SLOs", and "incident diagnostics" are natural user phrases, but the most common synonyms — "observability", "monitoring", "metrics", "logs", "traces", "OTel/OpenTelemetry" — are all missing. It is not 4 because a user would plausibly say several of those missing terms when needing this skill.	3 / 5
Distinctiveness Conflict Risk	The telemetry/SLO/incident-diagnostics framing carves a mostly distinct niche with minimal overlap risk, though it could collide with general debugging or incident-response skills. It is not 5 because the description does not state triggers tightly enough to fully separate it from adjacent on-call/debug tooling.	4 / 5
	Total	13 / 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: first-fluke/oh-my-agent
Path: .agents/skills/oma-observability/SKILL.md
Commit: ce19702

Reviewed: 4 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.