opentelemetry-ottl
OpenTelemetry Transformation Language (OTTL) for OTel Collector pipelines. Use when writing or debugging OTTL statements in the transform processor, filter processor, or routing connector in any collector configuration — context selection, path expression mistakes (`attributes` vs `resource.attributes`), `error_mode`, cardinality reduction with `keep_keys`, JSON body handling with `ParseJSON`, PII redaction with `SHA256` / `replace_pattern`, and span naming. Not for receiver/exporter connectivity, DNS, pipeline wiring, or telemetry that never reaches the processor — those are infra problems, not OTTL problems.
79
100%
Does it follow best practices?
Impact
—
No eval scenarios have been run
Passed
No known issues
Quality
Discovery
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.
This is an excellent skill description that excels across all dimensions. It provides highly specific capabilities with concrete technical terms users would naturally use, clearly delineates both when to use it and when NOT to use it, and carves out a distinct niche within the broader OpenTelemetry ecosystem. The explicit exclusion clause is particularly effective for disambiguation.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Lists multiple specific concrete actions: context selection, path expression mistakes, error_mode, cardinality reduction with keep_keys, JSON body handling with ParseJSON, PII redaction with SHA256/replace_pattern, and span naming. Very detailed and actionable. | 3 / 3 |
Completeness | Clearly answers both 'what' (OTTL statement writing/debugging across multiple processors with specific techniques) and 'when' (explicit 'Use when...' clause plus explicit exclusions for what it should NOT be used for, which further clarifies scope). | 3 / 3 |
Trigger Term Quality | Excellent coverage of natural terms a user would use: 'OTTL', 'transform processor', 'filter processor', 'routing connector', 'attributes vs resource.attributes', 'keep_keys', 'ParseJSON', 'SHA256', 'replace_pattern', 'span naming', 'error_mode'. These are exactly the terms someone debugging OTTL would mention. | 3 / 3 |
Distinctiveness Conflict Risk | Extremely well-scoped with explicit boundary-setting: it handles OTTL in OTel Collector pipelines but explicitly excludes receiver/exporter connectivity, DNS, pipeline wiring, and infra problems. This negative scoping makes it very unlikely to conflict with adjacent infrastructure or general OpenTelemetry skills. | 3 / 3 |
Total | 12 / 12 Passed |
Implementation
100%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This is an exceptionally well-crafted skill that demonstrates mastery of progressive disclosure, actionability, and conciseness. The error patterns table is particularly valuable as a diagnostic tool, mapping exact Collector error messages to root causes. The content maintains a tight scope (explicitly fencing out non-OTTL problems) while providing executable YAML for every common workflow, with defensive coding practices woven throughout.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The content is lean and efficient throughout. It assumes Claude's competence with YAML, OTel concepts, and programming. Tables are used effectively for dense information delivery. No unnecessary explanations of what OTTL is beyond the one-line opener. Every section earns its place. | 3 / 3 |
Actionability | Provides fully executable YAML snippets for every common workflow (JSON body parsing, cardinality reduction, PII redaction, resource attribute promotion). The error patterns table maps exact Collector error messages to root causes and first actions. Code examples are copy-paste ready with real OTTL functions and correct syntax. | 3 / 3 |
Workflow Clarity | The debug workflow is clearly sequenced with explicit steps (confirm problem scope → identify signal/context → match error → check guards → check prefixes → propose fix). Defensive OTTL practices serve as validation checkpoints (guard before indexing, check error_mode). The 'filter before transform' ordering and error_mode guidance provide explicit feedback loops for production safety. The error patterns table acts as a diagnostic decision tree. | 3 / 3 |
Progressive Disclosure | Excellent structure with a clear overview in SKILL.md and well-signaled one-level-deep references to six specific reference files under references/. Each reference is linked inline at the point of relevance AND collected in a footer. The 'When to Use' table immediately routes users to the right section or reference. Navigation is intuitive with inline arrows (→) pointing to deeper material. | 3 / 3 |
Total | 12 / 12 Passed |
Validation
90%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 10 / 11 Passed
Validation for skill structure
| Criteria | Description | Result |
|---|---|---|
metadata_field | 'metadata' should map string keys to string values | Warning |
Total | 10 / 11 Passed | |
- Repository
- coralogix/cx-skills
- Commit
6b2e359
- 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.