mtls-configuration
Configure mutual TLS (mTLS) for zero-trust service-to-service communication. Use when implementing zero-trust networking, certificate management, or securing internal service communication.
83
59%
Does it follow best practices?
Impact
98%
1.05xAverage score across 6 eval scenarios
Advisory
Suggest reviewing before use
Optimize this skill with Tessl
npx tessl skill review --optimize ./plugins/cloud-infrastructure/skills/mtls-configuration/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 description with a clear 'Use when' clause and good trigger term coverage for the mTLS/zero-trust domain. Its main weakness is that the 'what' portion is somewhat thin—it says 'configure' but doesn't enumerate specific sub-tasks like certificate generation, CA setup, or certificate rotation. Overall it performs well for skill selection purposes.
Suggestions
Expand the capability list with specific concrete actions, e.g., 'Configure mutual TLS (mTLS) for zero-trust service-to-service communication, including generating client/server certificates, setting up certificate authorities, and configuring certificate rotation.'
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names the domain (mTLS, zero-trust) and a general action ('Configure mutual TLS'), but doesn't list multiple specific concrete actions like generating certificates, configuring certificate authorities, setting up certificate rotation, or validating client certificates. | 2 / 3 |
Completeness | Clearly answers both 'what' (configure mutual TLS for zero-trust service-to-service communication) and 'when' (explicit 'Use when' clause covering zero-trust networking, certificate management, or securing internal service communication). | 3 / 3 |
Trigger Term Quality | Includes strong natural keywords users would say: 'mTLS', 'mutual TLS', 'zero-trust', 'certificate management', 'service-to-service communication', 'internal service communication'. These cover the main variations a user would naturally use. | 3 / 3 |
Distinctiveness Conflict Risk | mTLS and zero-trust service-to-service communication is a clear, specific niche. The triggers are distinct enough that this would not easily conflict with general networking, TLS/SSL, or broader security skills. | 3 / 3 |
Total | 11 / 12 Passed |
Implementation
29%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 YAML templates and debugging commands for multiple service mesh platforms, which is its primary strength. However, it suffers from being a monolithic reference dump with no clear workflow, no validation checkpoints for a potentially service-breaking operation (strict mTLS migration), and excessive inline content that should be split into separate files. The core concepts section wastes tokens explaining things Claude already understands.
Suggestions
Add a clear step-by-step migration workflow (e.g., 1. Deploy in PERMISSIVE → 2. Verify traffic with `istioctl authn tls-check` → 3. Switch to STRICT → 4. Validate no broken connections) with explicit validation checkpoints between steps.
Move platform-specific templates (Istio, Linkerd, SPIRE, cert-manager) into separate referenced files (e.g., ISTIO.md, LINKERD.md) and keep only a quick-start example inline.
Remove the 'Core Concepts' ASCII diagrams and 'When to Use This Skill' section — Claude already understands mTLS handshakes and certificate hierarchies.
Add a verification/rollback section for the STRICT mode migration, since enabling strict mTLS without verification can break service communication.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is excessively verbose with large template blocks that could be referenced externally. The 'Core Concepts' section with ASCII diagrams explains things Claude already knows (TLS handshake flow, certificate hierarchy). The 'When to Use This Skill' section is unnecessary padding. Multiple full YAML templates for different service meshes (Istio, Linkerd, SPIRE) bloat the content significantly. | 1 / 3 |
Actionability | The templates are concrete, copy-paste ready YAML configurations with specific field values. The debugging section provides executable bash commands. Certificate rotation commands are specific and directly usable. | 3 / 3 |
Workflow Clarity | There is no clear sequential workflow for implementing mTLS. The content is organized as a reference dump of templates without a step-by-step process. There are no validation checkpoints between steps (e.g., verify mTLS is working after enabling STRICT mode). For a potentially destructive operation (enabling STRICT mTLS can break services), the lack of a migration workflow with verification steps is a significant gap. | 1 / 3 |
Progressive Disclosure | This is a monolithic wall of text with all templates inline. The SPIRE, Linkerd, cert-manager, and Istio templates should be in separate referenced files. There are no cross-references to external files, and the content exceeds what should be in a single SKILL.md overview. | 1 / 3 |
Total | 6 / 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
27a7ed9
- 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.