metrics-instrumentation

Specification for instrumenting an opik-backend workflow with operational OpenTelemetry metrics — per-stage throughput/latency/error counters and native histograms, dimensioned per-customer (workspace). Use when a pipeline (scoring, ingestion, experiments, jobs) needs per-stage visibility. Covers metric emission only; building the Grafana dashboard from these metrics is a separate skill. Distinct from analytics-instrumentation (PostHog product events).

Quality

85%

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

Quality

Content

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

A dense, normative spec that is highly actionable with real code and named contracts, cleanly sectioned for navigation. It would benefit from a tighter feedback loop around the build/test validation step and trimming a few explanatory passages.

Suggestions

Add an explicit validate→fix→retry loop for `mvn -o compile` and the reactive-test breakage (e.g. 'if compile fails, run spotlessApply then recompile') to lift workflow_clarity to 5.

Tighten the 'Patterns applied' opener and rationale asides — some restate what the numbered sections already normatively specify.

Consider extracting the metric-name catalog (§1 producer/consumer/entrypoint list) into a references file so the body stays a lean overview.

Dimension	Reasoning	Score
Conciseness	Mostly lean and normative with crisp MUST/SHOULD rules and code snippets, though the opening 'Patterns applied' list and a few explanatory asides restate reasoning a reader could infer; minor trimming possible.	4 / 5
Actionability	Provides concrete, executable Java snippets for meter creation, workspace context resolution, reactive enqueue, and specific metric names plus a build command (`mvn -o compile`) and PR delivery steps — copy-paste ready guidance.	5 / 5
Workflow Clarity	Decompose → choose instrument → define dimensions → implement → test → deliver is a clear sequence with a validation checkpoint (`mvn -o compile` MUST succeed) and a reactive-test fix-up step, but there is no explicit validate-then-fix feedback loop for the build failure case.	4 / 5
Progressive Disclosure	Well-organized into numbered sections (Model, Backend metrics, Tests, Constraints, Delivery) with pointers to companion skills (dashboard-authoring, opik-backend) and repo paths; no bundle files exist, and inline content is appropriately sectioned with minor bulk that could live in a reference.	4 / 5
	Total	17 / 20 Passed

Description

87%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 precise, well-scoped description that cleanly states what to do, when to use it, and where its boundary lies. Minor jargon density slightly weakens natural trigger phrasing, but coverage and distinctiveness are excellent.

Dimension	Reasoning	Score
Specificity	Names the exact domain (opik-backend OpenTelemetry metrics) and multiple concrete actions: per-stage throughput/latency/error counters, native histograms, per-customer workspace dimensioning — comprehensive and concrete.	5 / 5
Completeness	Explicitly answers both 'what' (instrument workflow with per-stage OTel metrics) and 'when' ('Use when a pipeline ... needs per-stage visibility'), plus scope boundary and distinctness from analytics-instrumentation.	5 / 5
Trigger Term Quality	Includes natural triggers a user might say ('scoring, ingestion, experiments, jobs needs per-stage visibility') but leans on internal jargon ('opik-backend', 'analytics-instrumentation/PostHog') that a user would less often voice directly.	4 / 5
Distinctiveness Conflict Risk	Clear niche (metric emission only, not dashboard authoring) with an explicit distinction from analytics-instrumentation (PostHog product events), minimizing conflict risk.	5 / 5
	Total	19 / 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: comet-ml/opik
Path: .agents/skills/metrics-instrumentation/SKILL.md
Commit: 50de943

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