CtrlK
BlogDocsLog inGet started
Tessl Logo

oma-observability

Intent-based observability + traceability router across layers, boundaries, and signals. Routes to vendor-specific skills via category taxonomy; owns transport tuning, meta-observability, incident forensics. Use for observability, traceability, telemetry, APM, RUM, metrics, logs, traces, profiles, SLO, incident forensics, tracing architecture work.

66

Quality

79%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

SecuritybySnyk

Passed

No findings from the security scan

Fix and improve this skill with Tessl

tessl review fix ./benchmarks/runs/oma/.agents/skills/oma-observability/SKILL.md
SKILL.md
Quality
Evals
Security

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 document with concrete intent routing, explicit guardrails, and a clear scene-based workflow, and it correctly pushes detail into per-topic reference files. Its weaknesses are scaffolding overhead and inline time-sensitive claims that hurt token efficiency, and reference targets that cannot be verified against the bundle as provided.

Suggestions

Trim scaffolding that doesn't aid routing decisions — the 'Actions | SSL primitive' table, the large ASCII architecture diagram, and the 'Resource scope'/'Effects' sections — to cut token cost without losing actionability.

Move time-sensitive status claims ("as of 2026-Q2", "Graduated 2024-11", "CNCF 2025-10") out of guardrail prose into the Versioning & Deprecation section so they age in one place.

Ensure the ~40 referenced resources/ files ship with the skill bundle and remove the internal repo path (docs/plans/designs/005-oma-observability.md), which is unreachable for skill consumers; make the VERIFY/checklist checkpoints concrete (what to check, what to do on failure).

DimensionReasoningScore

Conciseness

The body is mostly dense routing metadata rather than concept explanation, but it carries notable scaffolding overhead — the 'Actions | SSL primitive' table, the 54-line ASCII architecture diagram, and 'Resource scope'/'Effects' tables add tokens without actionability. Inline time-sensitive claims ("as of 2026-Q2", "OpenFeature (Graduated 2024-11)", "CNCF 2025-10") sit outside the Versioning & Deprecation section.

3 / 5

Actionability

The per-intent Routes table gives concrete file targets with fallbacks, the Invocation section shows exact slash-command examples, and guardrails cite specific thresholds ("clock sync (< 100 ms drift)", burn-rate alert rules). Most guidance is executable-as-routing, though the actual implementation depth is deferred to the resource files.

4 / 5

Workflow Clarity

A clear Entry → Scenes (PREPARE through FINALIZE) → Transitions → Failure and recovery → Exit sequence is present, with a dedicated VERIFY scene and a pre-submit checklist gate ("Before submitting, run resources/checklist.md"). Checkpoints are referenced rather than fully inline, leaving minor validation gaps.

4 / 5

Progressive Disclosure

References are well-signaled, categorized (transport/layers/boundaries/signals), and one level deep, and heavy content like the 112-cell matrix is correctly deferred to resources/matrix.md. However, none of the ~40 referenced resource files exist in the bundle, and a stray internal repo path (docs/plans/designs/005-oma-observability.md) appears in the Contribution Protocol, leaving minor navigation gaps.

4 / 5

Total

15

/

20

Passed

Description

91%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.

A strong description with an explicit trigger clause and comprehensive natural keywords that clearly communicate both capability and scope. Its main weakness is slightly abstract phrasing of the 'what' (router/taxonomy language rather than user-facing actions) and minor conflict risk with the vendor-specific skills it routes to.

DimensionReasoningScore

Specificity

The description lists several concrete functional actions — "Routes to vendor-specific skills via category taxonomy; owns transport tuning, meta-observability, incident forensics" — but phrases them at an abstract altitude ('intent-based router', 'owns') rather than fully concrete operations, leaving minor coverage gaps.

4 / 5

Completeness

It explicitly answers both questions: the 'what' ("Routes to vendor-specific skills... owns transport tuning, meta-observability, incident forensics") and an explicit 'when' ("Use for observability, traceability, telemetry, APM, RUM...") with concrete trigger phrases.

5 / 5

Trigger Term Quality

"Use for observability, traceability, telemetry, APM, RUM, metrics, logs, traces, profiles, SLO, incident forensics, tracing architecture work" provides comprehensive coverage of natural terms and synonyms users would actually say when they need this skill.

5 / 5

Distinctiveness Conflict Risk

The routing/meta-observability/transport niche is mostly distinct from vendor-specific setup skills, but broad observability keywords (APM, RUM, SLO, logs, traces) create minor overlap risk with vendor-owned observability skills it delegates to.

4 / 5

Total

18

/

20

Passed

Validation

100%

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
Reviewed

Table of Contents

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.