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.
78
66%
Does it follow best practices?
Impact
100%
1.35xAverage score across 3 eval scenarios
Advisory
Suggest reviewing before use
Optimize this skill with Tessl
npx tessl skill review --optimize ./tests/ext_conformance/artifacts/agents-wshobson/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 niche (Linkerd service mesh) and includes an explicit 'Use when' clause with relevant trigger scenarios. The main weakness is that the 'what' portion could be more specific about concrete actions (e.g., sidecar injection, mTLS configuration, traffic splitting) rather than using the somewhat abstract 'implement patterns' phrasing.
Suggestions
Replace 'Implement Linkerd service mesh patterns' with more concrete actions like 'Inject Linkerd sidecars, configure mTLS, define traffic splits, and set up service profiles'.
| 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—'implement patterns' and 'deployments' are not as concrete as listing specific actions like 'inject sidecars, configure mTLS, define traffic splits'. | 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 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) or general Kubernetes networking skills. The mention of 'lightweight' and 'minimal overhead' further distinguishes it. | 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, concrete templates for Linkerd deployment patterns, which is its primary strength. However, it is excessively verbose for a skill file — it includes architectural diagrams, concept tables, and generic best practices that Claude already knows, consuming significant token budget. The monolithic structure with no supporting bundle files means everything is crammed into one large document with no progressive disclosure.
Suggestions
Cut the architecture diagram, 'When to Use This Skill' list, 'Core Concepts' table, and generic best practices — Claude already understands these concepts. Focus the SKILL.md on the templates and commands only.
Split detailed templates (ServiceProfile, authorization policies, multi-cluster) into separate bundle files and reference them from a concise overview in SKILL.md.
Add explicit validation/rollback steps to the canary deployment and multi-cluster workflows (e.g., 'verify traffic split with `linkerd viz stat` before increasing canary weight').
Remove version-specific documentation links (2.14) or note them as potentially outdated to avoid stale references.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is very verbose at ~200+ lines. The architecture diagram, 'When to Use This Skill' list, 'Core Concepts' table, and best practices sections explain things Claude already knows. The 'Do's and Don'ts' are generic advice rather than novel information. Much content could be cut without losing actionable value. | 1 / 3 |
Actionability | Templates are fully concrete with copy-paste ready YAML manifests and bash commands. Installation steps, service profiles, traffic splits, authorization policies, and multi-cluster setup are all executable as written with specific resource definitions. | 3 / 3 |
Workflow Clarity | The installation template has a clear sequence with validation (`linkerd check --pre`, `linkerd check`), but other workflows like canary deployment and multi-cluster setup lack explicit validation/rollback checkpoints. There's no feedback loop for what to do if `linkerd check` fails or if traffic splits cause issues. | 2 / 3 |
Progressive Disclosure | This is a monolithic wall of text with all content inline — seven templates, monitoring commands, debugging, best practices, and resources all in one file. There are no bundle files to offload detailed templates or reference material, and the external links at the bottom point to versioned docs (2.14) which may become stale. | 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
- Dicklesworthstone/pi_agent_rust
- Commit
99da384
- 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.