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.
84
66%
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 highly distinctive due to the specific technology focus. The main weakness is that the capability listing could be more concrete — instead of 'implement patterns' and 'deployments', it could enumerate specific actions like configuring mTLS, creating service profiles, or setting up traffic splits.
Suggestions
Replace the vague 'implement Linkerd service mesh patterns' with specific concrete actions like 'inject Linkerd sidecars, configure mTLS, create service profiles, set up traffic splits, and manage retries/timeouts'.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names the domain (Linkerd service mesh) and some actions ('setting up Linkerd', 'configuring traffic policies', 'implementing zero-trust networking'), but the 'what' portion is somewhat vague with 'implement patterns' and 'deployments' rather than listing multiple concrete actions like injecting sidecars, configuring mTLS, creating service profiles, etc. | 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', 'lightweight', 'security-focused'. These are terms a user working with Linkerd would naturally use in their requests. | 3 / 3 |
Distinctiveness Conflict Risk | Highly distinctive — 'Linkerd' is a specific technology that clearly differentiates this from other service mesh skills (e.g., Istio, Consul). The mention of 'lightweight' and 'security-focused' further narrows the niche and reduces conflict risk. | 3 / 3 |
Total | 11 / 12 Passed |
Implementation
42%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
The skill provides highly actionable, executable templates covering a broad range of Linkerd use cases, which is its primary strength. However, it is excessively verbose for a skill file—much of the content (architecture diagrams, concept tables, best practices lists) is information Claude already knows or could infer. The monolithic structure with no progressive disclosure makes it a poor fit for the context window budget.
Suggestions
Remove the architecture diagram, 'When to Use This Skill' section, Core Concepts table, and best practices do/don't lists—Claude already knows these concepts and they consume significant tokens.
Split the seven templates into separate referenced files (e.g., templates/service-profile.yaml, templates/traffic-split.yaml) and keep SKILL.md as a concise index with one-line descriptions linking to each.
Add explicit validation/feedback loops to the canary deployment workflow (e.g., 'check success rate with linkerd viz stat before increasing canary weight') and multi-cluster setup.
Condense monitoring and debugging commands into a single quick-reference table rather than separate sections with bash blocks.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is very verbose with significant content Claude already knows. The architecture diagram, 'Core Concepts' table, 'When to Use This Skill' section, and best practices do/don't lists are largely padding. Explanations like 'the lightweight, security-first service mesh for Kubernetes' and the architecture ASCII art add little actionable value. The file is well over 200 lines with much that could be trimmed. | 1 / 3 |
Actionability | The templates provide fully executable, copy-paste ready YAML manifests and bash commands. Each template covers a specific use case with concrete resource definitions, correct API versions, and realistic field values. The monitoring and debugging sections also provide specific CLI commands. | 3 / 3 |
Workflow Clarity | The installation template has a clear sequence with validation steps (linkerd check --pre, linkerd check). However, other multi-step workflows like canary deployments and multi-cluster setup lack explicit validation checkpoints or feedback loops. The canary template shows the TrafficSplit resource but doesn't describe how to validate the canary is working before shifting more traffic. | 2 / 3 |
Progressive Disclosure | The entire skill is a monolithic wall of text with no references to external files. All seven templates, monitoring commands, debugging commands, and best practices are inlined in a single file. This would benefit greatly from splitting templates into separate referenced files, keeping SKILL.md as a concise overview. | 1 / 3 |
Total | 7 / 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
112197c
- 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.