linkerd-patterns
Implement Linkerd service mesh patterns for lightweight, security-focused service mesh deployments. Use when setting up Linkerd, configuring traffic policies, or implementing zero-trust networking with minimal overhead.
87
73%
Does it follow best practices?
Impact
96%
1.15xAverage score across 6 eval scenarios
Advisory
Suggest reviewing before use
Optimize this skill with Tessl
npx tessl skill review --optimize ./plugins/cloud-infrastructure/skills/linkerd-patterns/SKILL.mdQuality
Discovery
89%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 solid skill description that clearly identifies its domain (Linkerd service mesh), includes an explicit 'Use when' clause with relevant triggers, and is distinctive enough to avoid conflicts with other skills. The main weakness is that the specific capabilities could be more granular—listing concrete actions like mTLS configuration, sidecar injection, traffic splitting, or service profiles would strengthen the specificity dimension.
Suggestions
Add more granular concrete actions such as 'inject sidecar proxies, configure mTLS, define service profiles, set up traffic splits and retries' to improve specificity.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names the domain (Linkerd service mesh) and some actions ('setting up Linkerd', 'configuring traffic policies', 'implementing zero-trust networking'), but these are somewhat high-level patterns rather than multiple concrete, granular actions like 'inject sidecar proxies, configure mTLS, define traffic splits, set up retry policies'. | 2 / 3 |
Completeness | Clearly answers both 'what' (implement Linkerd service mesh patterns for lightweight, security-focused deployments) and 'when' (explicit 'Use when' clause covering setup, traffic policy configuration, and zero-trust networking scenarios). | 3 / 3 |
Trigger Term Quality | Includes strong natural keywords users would say: 'Linkerd', 'service mesh', 'traffic policies', 'zero-trust networking', 'minimal overhead'. These cover the primary terms a user working with Linkerd would naturally use in their requests. | 3 / 3 |
Distinctiveness Conflict Risk | Linkerd is a specific service mesh technology distinct from Istio, Consul Connect, etc. The description clearly carves out a niche around Linkerd specifically with its emphasis on lightweight and security-focused deployments, making it unlikely to conflict with other service mesh or Kubernetes skills. | 3 / 3 |
Total | 11 / 12 Passed |
Implementation
57%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
The skill provides excellent actionable templates with real, executable YAML and bash commands covering a wide range of Linkerd patterns. However, it suffers from being a monolithic document that should leverage progressive disclosure by splitting advanced topics into separate files. Workflow clarity could be improved with explicit validation checkpoints and error recovery steps, especially for canary deployments and authorization policy changes.
Suggestions
Split content into separate files (e.g., TRAFFIC-SPLIT.md, AUTHORIZATION.md, MULTI-CLUSTER.md) and reference them from a concise overview in SKILL.md
Add explicit validation/verification steps after applying authorization policies and traffic splits (e.g., 'Verify with linkerd viz routes' after applying ServiceProfile, 'Verify split with linkerd viz stat' after TrafficSplit)
Remove the 'When to Use This Skill' and 'Core Concepts' architecture diagram sections - Claude already understands Linkerd's architecture and when to use a service mesh
Add error recovery guidance for common failure modes (e.g., what to do when `linkerd check` fails, when proxy injection doesn't work)
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The architecture diagram and key resources table add some value but the 'When to Use This Skill' section and 'Core Concepts' header are unnecessary padding. The 'Best Practices' Do's/Don'ts section includes obvious advice like 'enable mTLS everywhere - it's automatic' which is self-contradictory in its framing. Overall moderately efficient but could be tightened. | 2 / 3 |
Actionability | Templates are fully executable with real YAML manifests and bash commands that are copy-paste ready. Installation, injection, service profiles, traffic splits, authorization policies, HTTPRoutes, and multi-cluster setup all have concrete, complete examples with correct API versions and field values. | 3 / 3 |
Workflow Clarity | The installation template has a clear sequence with validation (`linkerd check --pre`, `linkerd check`), but other multi-step workflows like canary deployments lack validation checkpoints. The multi-cluster setup includes `linkerd multicluster check` at the end but doesn't have error recovery steps. There's no feedback loop for fixing issues when checks fail. | 2 / 3 |
Progressive Disclosure | This is a monolithic wall of content with no references to external files. All templates, monitoring commands, debugging, and best practices are inlined in a single document. For a skill this long (200+ lines covering installation, service profiles, traffic splits, authorization, HTTPRoutes, multi-cluster, monitoring, and debugging), content should be split across referenced files. | 1 / 3 |
Total | 8 / 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
70444e5
- 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.