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 skill description with clear 'what' and 'when' clauses, strong trigger terms, and a distinctive niche. Its main weakness is that the capability description could be more specific by listing concrete actions beyond just 'configure' (e.g., generate CA certificates, set up certificate rotation, validate mTLS handshakes). Overall it performs well for skill selection purposes.
Suggestions
Expand the 'what' portion with more specific concrete actions, e.g., 'Generate CA certificates, configure certificate rotation, set up mTLS between microservices, and troubleshoot TLS handshake failures.'
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names the domain (mTLS, zero-trust, service-to-service communication) and a few actions (configure, certificate management, securing), but doesn't list multiple specific concrete actions like generating certificates, configuring certificate authorities, setting up certificate rotation, or validating mTLS handshakes. | 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 terms a user would naturally use when needing this skill. | 3 / 3 |
Distinctiveness Conflict Risk | Highly distinctive with a clear niche around mTLS and zero-trust networking. The specific terms like 'mutual TLS', 'mTLS', and 'service-to-service communication' are unlikely to conflict with other skills such as general TLS/SSL setup or broader networking 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 excellent concrete, executable templates and debugging commands for mTLS across multiple service meshes, but suffers from being a monolithic reference dump rather than a well-structured guide. It lacks any sequential workflow for implementation, has no validation checkpoints, and includes extensive YAML that should be split into separate files. The conceptual diagrams and 'When to Use' section waste tokens on information Claude already knows.
Suggestions
Add a clear step-by-step implementation workflow with validation checkpoints (e.g., 1. Deploy in PERMISSIVE mode → 2. Verify with `istioctl authn tls-check` → 3. Switch to STRICT → 4. Verify no broken connections).
Move the large YAML templates into separate referenced files (e.g., `istio-mtls.md`, `spire-config.md`, `linkerd-mtls.md`) and keep only a concise overview with links in the main SKILL.md.
Remove the 'Core Concepts' ASCII diagrams and 'When to Use This Skill' section — Claude already understands TLS handshakes and certificate hierarchies, and the skill description already covers when to use it.
Add explicit verification/validation steps after each major configuration change, especially for the PERMISSIVE→STRICT migration path which is a destructive operation that 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 file significantly. | 1 / 3 |
Actionability | The skill provides fully executable YAML configurations, concrete bash commands for debugging and certificate rotation, and copy-paste ready templates for multiple service mesh implementations. Commands like `istioctl authn tls-check` and `linkerd viz edges` are specific and directly usable. | 3 / 3 |
Workflow Clarity | There is no clear sequenced workflow for implementing mTLS end-to-end. Templates are presented as isolated blocks without a step-by-step process. There are no validation checkpoints between steps (e.g., verify mTLS is working after enabling STRICT mode). The migration from PERMISSIVE to STRICT is mentioned in best practices but never given as a workflow with verification steps. | 1 / 3 |
Progressive Disclosure | This is a monolithic wall of text with all templates inline. The SPIRE configuration, cert-manager setup, Linkerd templates, and Istio templates should be in separate referenced files. There are no references to external files, and the content is over 200 lines of dense YAML that would benefit greatly from being split into focused sub-documents. | 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
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.