CtrlK
BlogDocsLog inGet started
Tessl Logo
PluginPublic

testland/otel-collector-config-tester

Use when an OpenTelemetry Collector config changes (a new receiver, processor or exporter) and must be verified before deploy. Runs otelcol validate, uses the debug or file exporter to assert spans flow through the pipeline, and wires the check into CI.

Quality

88%

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

Overview
Quality
Evals
Security
Files

Quality

Content

78%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, mostly executable procedure with clear sequencing and exemplary use of a single one-level-deep reference file. Its weaknesses are moderate: the test-span payload and sender script are referenced but never provided, some guidance is repeated two to three times, and error-recovery iteration is left implicit.

Suggestions

Provide the span-sending artifacts the workflow depends on: inline a minimal test-span.json payload for the grpcurl example, and either ship tests/send_test_spans.py in the bundle (e.g. scripts/) or inline a short OTel SDK snippet that emits the two status-code spans used in Step 4.

State the flush_interval (wait >= 2s) and version-pin guidance once each - keep them in the Anti-patterns table and drop the duplicate mentions in Step 3, Step 5, and Limitations.

Add a brief explicit feedback loop for the CI step, e.g. "if the assertion fails, re-run with debug exporter verbosity: detailed and inspect the collector logs for the dropped span's trace ID", to close the retry-on-failure gap in Step 5.

DimensionReasoningScore

Conciseness

The body is dense and code-first, but the flush_interval warning appears three times (Step 3, Anti-patterns, Limitations), version-pinning advice repeats in Step 5, Anti-patterns, and the reference file, and Steps 1-2 duplicate the identical receiver YAML block - minor trimmable redundancy rather than "every token earns its place".

4 / 5

Actionability

Concrete executable commands throughout (otelcol validate, grpcurl, jq -e assertion, wc -l gate, docker run), but the span-sending half of the flow is not copy-paste ready: "< test-span.json" references an undefined payload and "python3 tests/send_test_spans.py" does not exist in the bundle.

4 / 5

Workflow Clarity

Steps 1-5 are clearly sequenced with explicit checkpoints (non-zero exit gating CI, grep/jq/wc assertions, wait-2s timing) and the Anti-patterns table maps failures to fixes, but there is no explicit retry-on-failure loop and the send-spans step depends on the undefined script - minor validation gaps versus the feedback-loop anchor.

4 / 5

Progressive Disclosure

The body keeps a "minimal shape" for CI and offloads the full workflow to references/ci-integration.md, a clearly signaled, one-level-deep, verified-real reference; the References section is a well-organized external link list, matching the top anchor.

5 / 5

Total

17

/

20

Passed

Description

92%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 is strong: third-person voice, concrete named actions, and an explicit Use-when trigger clause with specific conditions. Its only shortcoming is slightly incomplete keyword coverage (no "traces"/"OTLP" synonyms).

DimensionReasoningScore

Specificity

"Runs otelcol validate", "uses the debug or file exporter to assert spans flow through the pipeline", and "wires the check into CI" are multiple concrete, named actions covering the skill's full scope, matching the comprehensive-coverage anchor rather than the minor-gaps level below.

5 / 5

Completeness

An explicit "Use when..." clause with concrete triggers ("a new receiver, processor or exporter", "must be verified before deploy") plus a clear statement of what the skill does; both halves are explicit, matching the top anchor rather than the could-be-more-specific level.

5 / 5

Trigger Term Quality

Good natural keyword coverage ("OpenTelemetry Collector config", "receiver, processor or exporter", "spans", "pipeline", "CI"), but common variations like "traces", "OTLP", or "config validation" are absent, so it falls just short of the comprehensive-synonyms anchor.

4 / 5

Distinctiveness Conflict Risk

A clear niche (Collector config verification before deploy) with distinct, domain-specific triggers; only negligible overlap risk with closely related trace-assertion skills.

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.

Reviewed

On this page