distributed-tracing

Implement distributed tracing with Jaeger and Tempo to track requests across microservices and identify performance bottlenecks. Use when debugging microservices, analyzing request flows, or implementing observability for distributed systems.

1.29x

Quality

68%

Does it follow best practices?

Impact

100%

1.29x

Average score across 3 eval scenarios

Securityby

Passed

No findings from the security scan

Fix and improve this skill with Tessl

tessl review fix ./tests/ext_conformance/artifacts/agents-wshobson/observability-monitoring/skills/distributed-tracing/SKILL.md

The canonical home for this skill is distributed-tracing in wshobson/agents

Quality

Content

53%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 content is actionable with concrete deployment configs and runnable instrumentation code, but it underperforms on structure and efficiency. It functions as a monolithic document: the three bundle files it cites do not exist, and the inline content duplicates what those files should contain, while also explaining tracing concepts Claude already knows and omitting any explicit deploy-instrument-verify workflow.

Suggestions

Actually create references/jaeger-setup.md, references/instrumentation.md, and assets/jaeger-config.yaml.template, and move the full Jaeger/Tempo deployment YAML and the per-language instrumentation code into them, leaving SKILL.md as a concise overview with clearly signaled links.

Add an explicit sequenced workflow with validation checkpoints (deploy backend → instrument one service → verify its traces appear in the Jaeger UI → instrument remaining services), turning the Troubleshooting section into a feedback loop.

Remove the 'Distributed Tracing Concepts' definitions and ASCII trace diagram (concepts Claude already knows), trim the best-practices list to the non-obvious items, and drop the pinned v1.51.0 operator version or move version guidance into the reference file.

Dimension	Reasoning	Score
Conciseness	The body is mostly code and commands, but includes unnecessary material: the 'Distributed Tracing Concepts' section defines trace/span/context/tags/logs that Claude already knows, an ASCII teaching diagram, a padded 10-item best-practices list, and a pinned operator version URL (v1.51.0) that will age. Not a 4 because these sections are more than minor trimmable instances; not a 2 because the bulk is concrete, useful content rather than padded prose.	3 / 5
Actionability	Provides concrete kubectl commands, deployment YAML, docker-compose, and full instrumentation examples in Python, Node.js, and Go. Not a 5 because of minor execution gaps: the Node example calls trace.getTracer without importing trace from @opentelemetry/api, and the Go example uses attribute.String without importing go.opentelemetry.io/otel/attribute. Not a 3 because the guidance is genuinely executable, not pseudocode.	4 / 5
Workflow Clarity	Sections imply a rough order (deploy Jaeger/Tempo, instrument, analyze, troubleshoot) but there is no explicit sequenced workflow and no validation checkpoints such as verifying traces appear in the Jaeger UI before moving on. The Troubleshooting section is reactive guidance, not a checkpoint. Not a 4 because checkpoints are absent rather than minor-gapped; not a 2 because a rough sequence is present via section ordering.	3 / 5
Progressive Disclosure	The body references references/jaeger-setup.md, references/instrumentation.md, and assets/jaeger-config.yaml.template, but none of these files exist in the bundle, and it inlines the very content they should hold — full Jaeger/Tempo deployment YAML and three complete language-specific instrumentation codebases (~450 lines). This matches the anchor 'content that clearly belongs in separate files is inlined'. Not a 3 because the split is signaled but not actually realized: the referenced files are missing and the body duplicates their scope.	2 / 5
	Total	12 / 20 Passed

Description

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

A strong description that clearly states what the skill does and when to use it, with specific tools and concrete trigger phrases. Its only weaknesses are minor: missing common synonyms (traces, spans, latency) and a slightly broad 'observability' trigger that could overlap with related monitoring skills.

Dimension	Reasoning	Score
Specificity	Names concrete actions ('Implement distributed tracing with Jaeger and Tempo', 'track requests across microservices', 'identify performance bottlenecks') with specific tools, but coverage has minor gaps — sampling, context propagation, and trace analysis are not mentioned. Not a 5 because the action list is not comprehensive; not a 3 because it goes well beyond 1-2 generic actions.	4 / 5
Completeness	Explicitly answers 'what' ('Implement distributed tracing with Jaeger and Tempo to track requests... and identify performance bottlenecks') and 'when' with a concrete 'Use when...' clause listing trigger scenarios, matching the anchor-5 example structure. Not a 4 because the when-clause is explicit and specific rather than merely adequate.	5 / 5
Trigger Term Quality	Includes natural phrases users would say — 'debugging microservices', 'analyzing request flows', 'observability', plus tool names Jaeger and Tempo. Not a 5 because common synonyms like 'traces', 'spans', 'latency', or 'monitoring' are missing; not a 3 because keyword coverage is good rather than partial.	4 / 5
Distinctiveness Conflict Risk	Distributed tracing is a clear niche and naming Jaeger/Tempo distinguishes it, but the trigger 'implementing observability for distributed systems' is broad and overlaps with metrics/monitoring skills. Not a 5 due to this overlap risk; not a 3 because the core triggers are distinctive.	4 / 5
	Total	17 / 20 Passed

Validation

93%

Warnings & errors only

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation — 15 / 16 Passed

Validation for skill structure

Criteria	Description	Result
referenced_paths_exist	Referenced path issues: 6 missing	Warning

	Total	15 / 16 Passed

Repository: Dicklesworthstone/pi_agent_rust
Path: tests/ext_conformance/artifacts/agents-wshobson/observability-monitoring/skills/distributed-tracing/SKILL.md
Commit: a65ce00

Reviewed: 6 days ago

Table of Contents

Discovery Implementation Validation

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.