CtrlK
BlogDocsLog inGet started
Tessl Logo

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).

75

Quality

92%

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

SKILL.md
Quality
Evals
Security

Quality

Content

85%

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

A highly actionable, well-sequenced normative spec with executable code and explicit validation checkpoints. Its main weakness is token efficiency — the rationale-heavy intro and patterns list could be tightened without losing instructional value.

Suggestions

Tighten the opening paragraph and the "Patterns applied" list to state what to emit rather than why each pattern matters; move justification to a sentence or drop it, since the normative rules in §1–§5 already encode the intent.

Consider condensing the 12 pattern bullets into a short table or a one-line-each list, keeping only the metric names and the rule, to cut tokens while preserving actionability.

The "To see these conventions already in practice, grep ..." paragraph could be shortened to the stable-contract principle plus the grep instruction, removing the inline enumeration of every metric family.

DimensionReasoningScore

Conciseness

Mostly efficient with concrete code, but the intro paragraph and the 12-item "Patterns applied" list spend tokens on rationale ("A producer that emits nothing makes downstream starvation explainable rather than mysterious") that justifies design rather than instructing.

2 / 3

Actionability

Executable Java snippets (meter builders, deferContextual, reactive enqueue), concrete metric names, naming conventions, test-stubbing patterns, and the `mvn -o compile` command make it copy-paste ready.

3 / 3

Workflow Clarity

Ordered sections (Model → Backend metrics → Tests → Constraints → Delivery) with explicit validation checkpoints (`mvn -o compile` MUST succeed before delivery; §3.1 test-restoration guidance).

3 / 3

Progressive Disclosure

No bundle files exist; the single SKILL.md is well-organized into clear sections with no nested/deep references and is self-contained as a normative spec.

3 / 3

Total

11

/

12

Passed

Description

100%

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, third-person, and gives explicit what/when guidance with clear conflict-avoidance boundaries against sibling skills. Trigger terms align with how a user would naturally request this work.

DimensionReasoningScore

Specificity

Lists multiple concrete actions — "per-stage throughput/latency/error counters and native histograms, dimensioned per-customer (workspace)" — rather than vague language.

3 / 3

Completeness

Explicitly answers both what (instrumenting a workflow with OTel metrics) and when ("Use when a pipeline ... needs per-stage visibility"), with an explicit trigger clause.

3 / 3

Trigger Term Quality

Natural domain triggers are present ("Use when a pipeline (scoring, ingestion, experiments, jobs) needs per-stage visibility"), matching terms a user would say when needing instrumentation.

3 / 3

Distinctiveness Conflict Risk

Clearly carves a niche ("Covers metric emission only; building the Grafana dashboard ... is a separate skill. Distinct from analytics-instrumentation (PostHog product events)") and is unlikely to trigger for the wrong skill.

3 / 3

Total

12

/

12

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.

Validation16 / 16 Passed

Validation for skill structure

No warnings or errors.

Repository
comet-ml/opik
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.