Lean and code-driven: docker commands, API tables, and executable Python tests with minimal prose. The one background line ("Zipkin is the original distributed-tracing system...") is brief, and the inline notes are non-obvious gotchas (string-typed tags, lazy dependency aggregation) rather than basic concepts. Not score 2 because there is little expendable explanation.

Fully executable, copy-paste-ready guidance throughout: docker run command, GitHub Actions service block, SDK exporter setup, and complete pytest-style test functions with real endpoints and params. Not score 2 because the code is concrete and complete rather than pseudocode.

Steps 1-7 are clearly sequenced (run Zipkin → query API → configure SDK → assert → B3 tests → dependency graph → isolation), with verification built into the test assertions and a dedicated anti-patterns table giving fixes. Not capped at 2 because the operations are non-destructive test flows that include explicit assertions/checkpoints rather than batch or destructive changes missing validation.

Well-organized into clear sections with one-level-deep external references ([Zipkin quickstart docs], [Zipkin API spec], [B3 propagation spec]), but the ~200-line body keeps the full API endpoint table and several complete test templates inline with no bundle files to split into. Not score 3 because for a skill this size, the endpoint reference and full test templates could live in reference files to keep the overview leaner; not score 1 because organization and navigation are clear and references are not deeply nested.

Lists multiple concrete actions: "Author integration tests that query Zipkin", "B3 propagation header tests (single-header and multi-header X-B3-* form)", and "dependency-graph assertions", plus specific endpoints (/api/v2/traces, /api/v2/services, /api/v2/dependencies). Not score 2 because it goes beyond naming a domain to enumerating several distinct, concrete test activities.

Explicitly answers both what (author B3 header tests, REST API trace queries, dependency-graph assertions) and when ("Use when the team uses Zipkin (legacy or Spring Cloud Sleuth heritage)"). Not score 2 because the trigger is explicit, not merely implied.

Contains natural terms the target audience would say — "Zipkin", "trace verification", "integration tests", and "Spring Cloud Sleuth heritage". Not score 2 because these cover the common variations a user would actually invoke rather than only jargon.

Clear Zipkin-specific niche with B3 propagation and /api/v2 endpoints; the "Use when the team uses Zipkin" trigger and sister-skill mention distinguish it from the jaeger-trace-tests skill. Not score 2 because the triggers are specific enough to avoid overlapping with generic tracing skills.