OpenTelemetry skills give coding agents a dated answer when the network is gone
OllyGarden's latest skill update separates the newest configuration schema from what a specific runtime can parse, addressing a concrete failure in offline agent answers.
The latest schema is not the runtime’s schema
OllyGarden has merged an OpenTelemetry skill update aimed at a familiar coding-agent mistake: confidently choosing a configuration version from incomplete evidence. The October 15 change adds dated compatibility records so an agent without network access can report what was checked, instead of presenting a remembered value as today’s latest supported format.
The maintainer describes an offline Go question that produced file_format: "1.0" after the agent followed a misleading fixture reference. The new table distinguishes the schema repository’s v1.2.0 release from the older schema targeted by Go’s otelconf v0.27.0, whose recorded literal is "1.0-rc.3".
That example is a dated project finding, not a universal rule for every OpenTelemetry version. The snapshot also separates Java’s SDK from its agent and Spring Boot starter, and distinguishes the .NET SDK from .NET auto-instrumentation. Those products do not share one automatic compatibility answer.
References for the agent you already use
The Apache-2.0 package follows the Agent Skills specification and documents installation for Claude Code, Cursor, Codex and GitHub Copilot. Its general route is npx skills add ollygarden/opentelemetry-agent-skills; Claude Code also has a plugin-marketplace route. Individual skill folders can be installed separately.
These are reference files for a coding agent, not a new model or hosted observability backend. Installation does not supply inference credentials. Model access and charges depend on the chosen agent and provider; the compatibility lookup can be answered offline from the bundled snapshot, while checking a newer release needs upstream evidence.
The revised skill prioritizes parser behavior at a release tag or published artifact over changelogs, examples and broad language-support summaries. Offline answers should include the verification date and advise checking the release evidence before deployment. If the target runtime is unknown, the skill calls for a schematic rather than pretending the YAML is ready to deploy.
Better answers still missed requirements
The pull request reports tests using Hermes with DeepSeek V4 Flash, with skills withheld, the previous skills, and the proposed update. The proposed files met more individual expectations, but only two of twelve runs passed every requirement. Five of nine offline runs omitted the requested confirmation against release evidence before deploying.
Those are the maintainer’s evaluations on one model and harness, not independently reproduced results or proof that every host agent will load the skill correctly. The useful change is concrete: compatibility facts now carry a runtime identity, evidence and a date, making a stale answer easier to recognize.