service-mesh-observability

Implement comprehensive observability for service meshes including distributed tracing, metrics, and visualization. Use when setting up mesh monitoring, debugging latency issues, or implementing SLOs for service communication.

1.39x

Quality

74%

Does it follow best practices?

Impact

95%

1.39x

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/cloud-infrastructure/skills/service-mesh-observability/SKILL.md

The canonical home for this skill is service-mesh-observability in wshobson/agents

Quality

Content

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

Highly actionable reference material with excellent copy-paste-ready templates across the major mesh observability tools, but it reads as a catalog rather than a guide: no setup sequence or verification steps, and everything is inlined in one long file instead of being split into reference files. The conceptual intro sections also spend tokens on knowledge Claude already has.

Suggestions

Replace the 'Three Pillars' ASCII diagram and 'Golden Signals' table with a one-line pointer to the alert thresholds already encoded in the PrometheusRule section, since Claude already knows these concepts.

Add a short ordered setup workflow (e.g., 1. deploy Prometheus and confirm scrape targets, 2. enable tracing and verify spans in Jaeger, 3. import dashboard and alerts) with verification commands like `kubectl get --raw /metrics` or `linkerd check`.

Move the large per-tool artifacts (Grafana dashboard JSON, Kiali/Jaeger/OTel manifests) into a references/ directory and keep one compact example of each inline, cutting SKILL.md to a navigable overview.

Dimension	Reasoning	Score
Conciseness	The 'Three Pillars' ASCII diagram and 'Golden Signals' table re-explain observability concepts Claude already knows, and PromQL queries are duplicated between Template 2 and the Grafana dashboard JSON. Not a 2 because the bulk of the file is dense template content rather than padded prose; not a 4 because the conceptual padding and duplication are noticeable.	3 / 5
Actionability	Seven templates of copy-paste-ready YAML, PromQL, bash, and JSON covering the common cases for Istio, Linkerd, Jaeger, Grafana, Kiali, and OpenTelemetry. Fully executable with specific values, matching the anchor for complete, common-case-covering examples.	5 / 5
Workflow Clarity	The body is a template catalog organized by tool rather than a sequenced setup workflow; there is no ordering guidance (e.g., install metrics stack, then enable tracing, then visualize) and no validation checkpoints such as verifying Prometheus scrape targets or trace ingestion. Not a 4 specifically because verification steps are absent, which caps it at 3.	3 / 5
Progressive Disclosure	Sections are clearly headed and easy to navigate, but the ~380-line body inlines content that belongs in separate reference files (the Grafana dashboard JSON, per-tool setup guides), and no bundle files exist to offload any of it. Not a 4 because content that should be split out is inline and no in-skill references are signaled.	3 / 5
	Total	14 / 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 with a clear capability statement and an explicit 'Use when...' clause containing three concrete trigger scenarios. Main weaknesses are the abstract 'comprehensive observability' phrasing and missing high-signal trigger terms like specific mesh names (Istio, Linkerd).

Dimension	Reasoning	Score
Specificity	Names the domain ('service meshes') and several concrete capabilities ('distributed tracing, metrics, and visualization'), but 'comprehensive observability' is abstract and coverage has minor gaps (no logging or alerting). Not a 5 because the capability list is not fully comprehensive; not a 3 because more than 1-2 specific actions are listed.	4 / 5
Completeness	Explicitly answers both: what ('Implement comprehensive observability... including distributed tracing, metrics, and visualization') and when ('Use when setting up mesh monitoring, debugging latency issues, or implementing SLOs for service communication'). Matches the anchor-5 pattern of a concrete what followed by explicit trigger phrases.	5 / 5
Trigger Term Quality	Includes natural phrases users would say ('setting up mesh monitoring', 'debugging latency issues', 'implementing SLOs'), but misses common variations like 'Istio', 'Linkerd', 'dashboards', or 'tracing'. Not a 5 because synonym/mesh-name coverage is incomplete; not a 3 because several natural trigger phrases are present.	4 / 5
Distinctiveness Conflict Risk	'service meshes', 'mesh monitoring', and 'SLOs for service communication' carve a distinct niche with low conflict risk against unrelated skills. Not a 5 because it could still overlap with general monitoring/observability or Kubernetes dashboards skills that lack mesh-specific triggers.	4 / 5
	Total	17 / 20 Passed

Validation

100%

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 — 16 / 16 Passed

Validation for skill structure

No warnings or errors.

Repository: Dicklesworthstone/pi_agent_rust
Path: tests/ext_conformance/artifacts/agents-wshobson/cloud-infrastructure/skills/service-mesh-observability/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.