{
  "markdown": "# OpenTelemetry Skills for AI Coding Agents\n\nVendor-neutral skills that teach AI coding agents how to instrument applications with OpenTelemetry.\nCovers SDK setup across languages, semantic conventions, Collector pipelines, and OTTL transformations.\nWorks with any OTLP-compatible backend.\n\nSkills are packaged instructions and scripts that extend agent capabilities, following the [Agent Skills](https://agentskills.io/) format.\nMaintained by [Dash0](https://www.dash0.com).\n\n> [!TIP]\n> These skills have been improved using [Tessl](https://tessl.io).\n> Try it out for your own agent skills, it's worth it.\n\n[![tessl](https://img.shields.io/endpoint?url=https%3A%2F%2Fapi.tessl.io%2Fv1%2Fbadges%2Fdash0%2Fagent-skills)](https://tessl.io/registry/dash0/agent-skills)\n\n## Installation\n\n**Install with [skills](https://skills.sh/) CLI** (universal, works with any [Agent Skills](https://agentskills.io)-compatible tool):\n\n```bash\nnpx skills add https://github.com/dash0hq/agent-skills --all\n# or a single skill:\nnpx skills add https://github.com/dash0hq/agent-skills --skill otel-semantic-conventions\n```\n\nFor tool-specific installation instructions (Claude Code, Cursor, Tessl, and others), see [INSTALL.md](./INSTALL.md).\n\n**Consume programmatically via npm** (for agent runtimes that embed the skills rather than install them into a tool):\n\n```bash\nnpm install @dash0/agent-skills\n```\n\nThe package ships the `skills/` directory trees verbatim — no code. Resolve a skill's location at runtime, for example:\n\n```js\nconst { createRequire } = require(\"node:module\");\nconst path = require(\"node:path\");\n\nconst pkgJson = createRequire(__filename).resolve(\"@dash0/agent-skills/package.json\");\nconst skillDir = path.join(path.dirname(pkgJson), \"skills\", \"otel-instrumentation\");\n```\n\n## How to use\n\nOnce installed, skills load automatically and the agent picks them up when a task matches.\n\n**Examples:**\n```\nAdd OpenTelemetry instrumentation to my app\n```\n```\nMy traces are broken — spans show up as separate roots instead of a connected trace\n```\n```\nSet up an OpenTelemetry Collector pipeline that forwards to Dash0\n```\n```\nWrite an OTTL expression to redact credit card numbers from log bodies\n```\n```\nEnsure that my HTTP server spans have the correct attributes\n```\n```\nHelp me fix high-cardinality metrics that are blowing up my costs\n```\n\n## Why vendor-neutral OpenTelemetry\n\nThese skills are built around the OpenTelemetry specification, not any single backend.\nThe output is standard OTLP telemetry that any OpenTelemetry-compatible backend can ingest.\n\nVendor lock-in in observability comes from proprietary agents and attribute schemas.\nSkills in this repository avoid both: they guide agents to use OpenTelemetry SDKs and the OpenTelemetry Collector, and to follow the upstream [Semantic Conventions](https://opentelemetry.io/docs/specs/semconv/) for attribute, span, and metric naming.\n\n## Why semantic conventions matter\n\n[OpenTelemetry Semantic Conventions](https://opentelemetry.io/docs/specs/semconv/) define standardized names, types, and semantics for telemetry attributes, metric names, span names, and status codes.\nFollowing them is the single highest-leverage thing you can do for observability quality.\n\nWhen instrumentation follows semantic conventions:\n- Auto-instrumentation libraries, dashboards, and alerting rules work out of the box.\n- Service maps, operation grouping, and error tracking derive correct results without manual configuration.\n- Cross-service queries return consistent results because every service speaks the same attribute language.\n\nWhen conventions are missing or inconsistent, these capabilities degrade silently: no errors, just incomplete data, broken topology views, and fragmented queries.\n\n## Instrumentation score\n\nGuidance in these skills aligns with the [Instrumentation Score](https://github.com/instrumentation-score/spec) specification, a vendor-neutral corpus of guidance that quantifies how well a service follows OpenTelemetry best practices.\nThe spec defines impact-weighted rules across resources, spans, metrics, and logs.\nFollowing this guidance helps your services score higher, which means better observability outcomes downstream.\n\n## Available skills\n\n### [otel-instrumentation](./skills/otel-instrumentation/SKILL.md)\n\nExpert guidance for implementing high-quality, cost-efficient OpenTelemetry telemetry.\nCovers backend and browser instrumentation across multiple languages.\n\n**Use when:**\n- Setting up observability for a new service\n- Adding traces, metrics, or logs to an application\n- Debugging instrumentation issues\n- Optimizing telemetry costs (cardinality, sampling)\n- Connecting browser traces to backend traces\n\n**Rules covered:**\n- Telemetry (signal overview and correlation)\n- Resources (service identity, environment, Kubernetes attributes)\n- Metrics (instrument types, naming, units, cardinality)\n- Logs (structured logging, severity, trace correlation)\n- Node.js (auto-instrumentation, environment variables, Kubernetes)\n- Go (SDK setup, instrumentation libraries, context propagation)\n- Python (auto-instrumentation, Flask, Django, FastAPI)\n- Java (javaagent, Spring Boot, JVM system properties)\n- .NET (auto-instrumentation, ASP.NET Core, ActivitySource)\n- Ruby (SDK setup, Rails, Sinatra)\n- PHP (auto-instrumentation, Laravel, Symfony)\n- Browser (OpenTelemetry JS, Dash0 SDK, server correlation)\n- Next.js (App Router, full-stack instrumentation, common gotchas)\n\n**Platforms:**\n- Node.js (Express, Fastify, NestJS, etc.)\n- Go (net/http, gin, echo, fiber, etc.)\n- Python (Flask, Django, FastAPI, etc.)\n- Java (Spring Boot, Servlet, JAX-RS, etc.)\n- .NET (ASP.NET Core, Entity Framework, etc.)\n- Ruby (Rails, Sinatra, etc.)\n- PHP (Laravel, Symfony, etc.)\n- Browser (React, Vue, Next.js, etc.)\n- Any OTLP-compatible backend\n\n### [otel-semantic-conventions](./skills/otel-semantic-conventions/SKILL.md)\n\nExpert guidance for selecting, applying, and reviewing OpenTelemetry semantic conventions: the standardized names, types, and semantics for telemetry attributes, span names, and status codes.\n\n**Use when:**\n- Choosing attributes for spans, metrics, or logs\n- Naming spans or selecting span kinds\n- Mapping HTTP status codes to span status\n- Reviewing telemetry for semantic convention compliance\n- Migrating from old to new attribute names\n- Understanding Dash0 derived attributes\n\n**Rules covered:**\n- Attributes (registry, selection, placement, common attributes by domain, namespaces)\n- Spans (naming patterns, span kind, status code mapping)\n- Versioning (stability levels, migration, Dash0 semantic convention upgrades)\n- Dash0 (derived attributes, feature dependencies)\n\n### [otel-collector](./skills/otel-collector/SKILL.md)\n\nExpert guidance for configuring and deploying the OpenTelemetry Collector to receive, process, and export telemetry.\nCovers pipeline configuration, deployment patterns, and forwarding to any OTLP-compatible backend.\n\n**Use when:**\n- Setting up an OpenTelemetry Collector pipeline\n- Configuring receivers, processors, or exporters\n- Deploying the Collector to Kubernetes or Docker\n- Forwarding telemetry to any OTLP-compatible backend\n- Tuning Collector performance (memory, batching, queuing)\n\n**Rules covered:**\n- Receivers (OTLP, Prometheus, filelog, hostmetrics)\n- Exporters (OTLP/gRPC, debug, authentication, retry, queuing)\n- Processors (memory limiter, batch, resource detection, Kubernetes attributes, ordering)\n- Pipelines (service section, per-signal configuration, connectors, fan-out)\n- Deployment (agent vs gateway, DaemonSet, Deployment, Docker Compose, health checks)\n\n### [otel-ottl](./skills/otel-ottl/SKILL.md)\n\nExpert guidance for writing and debugging OpenTelemetry Transformation Language (OTTL) expressions for the OpenTelemetry Collector's transform and filter processors.\n\n**Use when:**\n- Writing OTTL expressions to transform, filter, or enrich telemetry\n- Redacting sensitive data from spans, metrics, or logs\n- Configuring transform or filter processors in the Collector\n- Debugging OTTL syntax or runtime errors\n- Optimizing Collector pipeline performance\n\n**Capabilities:**\n- Transform (modify attributes and values)\n- Filter (drop unwanted telemetry)\n- Redact (hide sensitive information)\n- Enrich (add contextual metadata)\n- Convert (change data types and formats)\n\n**Contexts:** resource, scope, span, spanevent, metric, datapoint, log\n\n## Automation with Claude Code\n\nYou can configure [Claude Code](https://docs.anthropic.com/en/docs/claude-code) to apply these skills automatically, both in interactive sessions and in headless CI/CD pipelines.\n\n### Project instructions via CLAUDE.md\n\nAdd a `CLAUDE.md` file to your repository root with instructions that tell Claude Code when to use the skills.\nClaude Code loads this file at the start of every session.\n\n```markdown\n# Observability\n\nThis project uses OpenTelemetry for observability.\nWhen adding or modifying instrumentation, follow the guidance from the installed `dash0hq/agent-skills` skills.\n\nWhen working on application code or deployment specs, use the `otel-instrumentation` skill.\nWhen working on Collector configuration, use the `otel-collector` skill.\nWhen choosing or reviewing telemetry attributes, use the `otel-semantic-conventions` skill.\nWhen writing or debugging OTTL expressions, use the `otel-ottl` skill.\n```\n\n### Headless mode in CI/CD\n\nUse `claude -p` to run Claude Code non-interactively in a pipeline.\nThis enables automated instrumentation reviews, skill-guided code generation, and PR checks.\n\n```bash\n# Review instrumentation quality on a pull request\nclaude -p \"Review the OpenTelemetry instrumentation changes in this PR. \\\n  Check for missing context propagation, incorrect span status handling, \\\n  and semantic convention violations.\" \\\n  --allowedTools \"Read,Grep,Glob\"\n```\n\n#### GitHub Actions example\n\n```yaml\nname: Instrumentation review\n\non: [pull_request]\n\njobs:\n  review:\n    runs-on: ubuntu-latest\n    steps:\n      - uses: actions/checkout@v4\n\n      - name: Install skills\n        run: npx skills add dash0hq/agent-skills\n\n      - name: Review instrumentation\n        run: |\n          claude -p \"Review the OpenTelemetry instrumentation in this PR \\\n            for correctness and semantic convention compliance. \\\n            Post your findings as a summary.\" \\\n            --allowedTools \"Read,Grep,Glob\" \\\n            --output-format json > review.json\n\n      - name: Comment on PR\n        run: |\n          findings=$(jq -r '.result' review.json)\n          gh pr comment \"$PR_NUMBER\" --body \"## Instrumentation review\"$'\\n\\n'\"$findings\"\n        env:\n          PR_NUMBER: ${{ github.event.pull_request.number }}\n```\n\n## Skill structure\n\nEach skill contains:\n- `SKILL.md` - Instructions for the agent\n- `rules/` - Focused guidance documents\n- `README.md` - Human-readable documentation\n\n## Contributing\n\nSee [CONTRIBUTING.md](CONTRIBUTING.md) for authoring rules and for running the evals locally to judge whether the skills work.\n",
  "bytes": 10979,
  "sha": "3d779edb29694208e9d3587fe754bd2b77e0be7a442738125ada4c7eda4766b6",
  "repo_slug": "dash0hq/agent-skills",
  "fonte": "repo",
  "truncated": false,
  "api": "https://agentalog.com/api/listings/plg_dash0hq_agent_skills_643cb79e/readme"
}