CtrlK
BlogDocsLog inGet started
Tessl Logo

otel-telemetrygen

Build safe, version-pinned telemetrygen commands for synthetic OTLP traces, metrics, and logs. Use for “send sample traces to this collector,” “load-test an OTLP endpoint,” “generate traffic to verify a processor, OTTL transform, or tail sampling,” and “produce test data for dashboards.” Also use when choosing telemetrygen transport, TLS, attributes, counts, duration, or rate. Not for application SDK instrumentation or production collection that does not use telemetrygen.

76

Quality

93%

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

92%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 strong operational skill body: every section carries non-obvious, load-bearing facts (rate arithmetic, duration-overrides-count, env-var leakage, tag availability), the commands are executable and cover all three signals, and detailed material is correctly pushed to two well-signaled, verified reference files. The main improvable area is the environment-variable section, which repeats itself and could be tightened by roughly a third.

Suggestions

Tighten the 'Make environment behavior explicit' section: it states the flags-cover-endpoint/path/TLS/timeout vs. env-driven-headers/compression fact twice (in the 'For a reproducible command' paragraph and again in its closing 'Explain both facts in the answer' sentence); merge into one statement to save tokens.

Move the date-stamped version availability notes ('v0.162.0 is published as of 2026-10-03', 'as of 2026-10-03 the plain 0.162.0 contrib tag is not published') into a short 'Version status' note or the referenced flags.md so the main body stays stable and lean.

DimensionReasoningScore

Conciseness

The body is dense with non-obvious operational facts Claude cannot be assumed to know (rate math 'workers * rate / (n + 1)', duration overriding count, exporter env-var behavior, which container tags are actually published) and never pads with basics, fitting the 4 anchor's 'efficient; minor instances of over-explanation that could be trimmed'. It is not a 5 because the 'Make environment behavior explicit' section restates the same flags-vs-env-var fact twice ('Explain both facts in the answer: explicit flags cover endpoint, signal path, TLS, and timeout, while common or signal-specific headers and compression can otherwise remain inherited') and inline date-stamped version notes ('as of 2026-10-03') are time-sensitive details not isolated in a dedicated section.

4 / 5

Actionability

Fully executable, copy-paste-ready commands cover the common cases: one bounded example per signal (traces, metrics, logs) with exact flags, plus install, docker pull, and a complete docker run invocation. The 6-step construction procedure names exact flags and defaults. This matches the 5 anchor ('fully executable; copy-paste ready; specific examples cover the common cases') and exceeds the 4 anchor, which tolerates minor gaps.

5 / 5

Workflow Clarity

Command construction is a clear 6-step numbered sequence with hard constraints, and the safety gate defines explicit validation checkpoints (finite budget, refuse '--rate 0' and '--duration inf') followed by a pre-finalization checklist ('Before finalizing a response, check that: every proposed command has its own finite count or duration...'). Verification includes error-recovery-relevant controls (known-positive control, preserve command failures, inspect only after flush), matching the 5 anchor's 'explicit validation steps; feedback loops; checklists for complex processes' rather than the 4 anchor's 'minor validation gaps'.

5 / 5

Progressive Disclosure

The body stays a concise overview with minimal command shapes, and bulk detail is appropriately split into two real, one-level-deep references, both clearly signaled at point of need: [references/flags.md](references/flags.md) for flag lookup (verified to exist with its own table of contents) and [references/collector-verification.md](references/collector-verification.md) for the full verification procedure (verified to exist, well-sectioned). No nested references and no API-reference material inlined in the body, matching the 5 anchor.

5 / 5

Total

19

/

20

Passed

Description

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

An exemplary description: third-person, concrete, explicit both about what the skill does and when to use it, with verbatim trigger phrasings users would actually say and a well-drawn negative boundary. The only softness is that the capability surface is one core action plus its configuration knobs rather than several distinct capabilities, which slightly limits specificity.

DimensionReasoningScore

Specificity

Concrete action verbs are present ('Build safe, version-pinned telemetrygen commands', 'choosing telemetrygen transport, TLS, attributes, counts, duration, or rate') tied to a clearly named domain, matching the 'lists several specific actions; minor gaps in coverage' anchor. It falls short of the 5 anchor because the capability list is really one core action (command construction) plus its configuration dimensions, rather than multiple distinct comprehensive actions as in the 5 example.

4 / 5

Completeness

It explicitly answers both what ('Build safe, version-pinned telemetrygen commands for synthetic OTLP traces, metrics, and logs') and when ('Use for...' with four concrete trigger phrases, plus 'Also use when choosing...'), matching the 5 anchor's 'clearly and explicitly answers both what AND when with concrete trigger phrases'. It even adds a negative boundary ('Not for application SDK instrumentation or production collection'), so it is not the 4 anchor where 'when' could be more explicit.

5 / 5

Trigger Term Quality

It embeds four verbatim natural user phrasings ('send sample traces to this collector', 'load-test an OTLP endpoint', 'generate traffic to verify a processor, OTTL transform, or tail sampling', 'produce test data for dashboards') plus a configuration keyword list (transport, TLS, attributes, counts, duration, rate), giving comprehensive coverage with synonyms. File extensions are inapplicable to this domain, so nothing natural is missing; this is a clear match to the 5 anchor, not the 4 anchor's 'a few natural terms missing'.

5 / 5

Distinctiveness Conflict Risk

A clear niche (telemetrygen synthetic telemetry) with distinct quoted triggers and an explicit exclusion clause ('Not for application SDK instrumentation or production collection that does not use telemetrygen') that actively prevents overlap with adjacent skills. This matches the 5 anchor ('clear niche with distinct triggers; minimal conflict risk') and exceeds the 4 anchor's 'minor overlap risk'.

5 / 5

Total

19

/

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
ollygarden/opentelemetry-agent-skills
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.