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.
52
57%
Does it follow best practices?
Impact
—
No eval scenarios have been run
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./plugins/cloud-infrastructure/skills/service-mesh-observability/SKILL.mdQuality
Discovery
100%Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.
This is a strong skill description that clearly defines its domain (service mesh observability), lists specific capabilities (distributed tracing, metrics, visualization), and provides explicit trigger guidance via a 'Use when' clause with natural, practitioner-oriented terms. It is well-scoped and distinctive enough to avoid conflicts with adjacent skills like general monitoring or application-level observability.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Lists multiple specific concrete actions: 'distributed tracing', 'metrics', 'visualization', 'mesh monitoring', 'debugging latency issues', and 'implementing SLOs for service communication'. These are concrete, actionable capabilities. | 3 / 3 |
Completeness | Clearly answers both 'what' (implement observability including distributed tracing, metrics, visualization) and 'when' (explicit 'Use when' clause covering mesh monitoring setup, debugging latency, implementing SLOs). | 3 / 3 |
Trigger Term Quality | Includes strong natural keywords users would say: 'service mesh', 'distributed tracing', 'metrics', 'monitoring', 'latency issues', 'SLOs', 'observability'. These are terms practitioners naturally use when seeking help in this domain. | 3 / 3 |
Distinctiveness Conflict Risk | The combination of 'service mesh' + 'observability' + specific triggers like 'SLOs for service communication' and 'mesh monitoring' creates a clear niche that is unlikely to conflict with general monitoring or generic observability skills. | 3 / 3 |
Total | 12 / 12 Passed |
Implementation
14%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This skill is essentially a conceptual overview of service mesh observability that explains things Claude already knows (three pillars, golden signals) while deferring all actionable content to a reference file that doesn't exist. It lacks executable code, concrete configuration examples, and any sequenced workflow. The skill would need a fundamental rewrite to provide actual implementation guidance rather than high-level descriptions.
Suggestions
Add concrete, executable configuration examples for at least one mesh (e.g., Istio telemetry YAML, Jaeger setup commands, Prometheus scrape configs) instead of deferring everything to a missing reference file.
Create a step-by-step workflow for a common task like 'Setting up distributed tracing' with explicit validation steps (e.g., verify spans appear in Jaeger, check trace propagation headers).
Remove the conceptual explanations Claude already knows (three pillars diagram, golden signals definitions) and replace with mesh-specific actionable guidance like actual PromQL queries for SLOs or EnvoyFilter configurations.
Either include the referenced 'references/details.md' file in the bundle or inline the most critical templates directly in the SKILL.md.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The ASCII diagram explaining the three pillars of observability and the golden signals table are things Claude already knows well. The 'When to Use This Skill' section is also somewhat redundant. However, the do's/don'ts section is reasonably tight. | 2 / 3 |
Actionability | There is no executable code, no concrete commands, no specific configuration examples, and no copy-paste ready templates. The skill describes concepts and lists best practices but never instructs Claude on how to actually implement anything. All concrete templates are deferred to a reference file that doesn't exist in the bundle. | 1 / 3 |
Workflow Clarity | There is no sequenced workflow for setting up observability, no step-by-step process, and no validation checkpoints. The skill is a collection of conceptual descriptions and best-practice lists without any clear operational sequence for multi-step tasks like setting up tracing or debugging latency issues. | 1 / 3 |
Progressive Disclosure | The skill references 'references/details.md' for all concrete templates and worked examples, but no bundle files are provided, meaning the reference is a dead link. The main file itself contains mostly conceptual content that Claude already knows, while all actionable content is deferred to a non-existent file. | 1 / 3 |
Total | 5 / 12 Passed |
Validation
100%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 11 / 11 Passed
Validation for skill structure
No warnings or errors.
- Repository
- wshobson/agents
- Commit
cf6059d
- Reviewed
Table of Contents
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.