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.
73
59%
Does it follow best practices?
Impact
97%
1.02xAverage 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/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 a clear 'Use when' clause and good trigger term coverage for its niche domain. The main weakness is that the 'what' portion could be more specific about the concrete actions performed (e.g., generating CA certificates, configuring trust stores, cert rotation). Overall it is well-targeted and distinctive.
Suggestions
Expand the capability list with more specific concrete actions, e.g., 'generate CA certificates, configure trust stores, set up cert rotation, validate mTLS handshakes' to improve specificity.
| 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 trust stores, rotating certs, or setting up certificate authorities. | 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 | The description targets a very specific niche—mTLS and zero-trust service-to-service communication—with distinct trigger terms like 'mTLS', 'mutual TLS', and 'zero-trust networking' that are unlikely to conflict with other 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 is severely bloated with conceptual explanations Claude doesn't need, lacks a clear implementation workflow with validation checkpoints critical for a potentially disruptive operation, and dumps all content into a single monolithic file rather than using progressive disclosure.
Suggestions
Add a clear step-by-step implementation workflow (e.g., 1. Deploy in PERMISSIVE mode → 2. Verify traffic with `istioctl authn tls-check` → 3. Switch to STRICT → 4. Validate no broken connections) with explicit validation checkpoints and rollback steps.
Move the large platform-specific templates (SPIRE, cert-manager, Linkerd) into separate referenced files (e.g., SPIRE.md, CERT_MANAGER.md) and keep only the most common Istio template inline.
Remove the 'Core Concepts' section (mTLS flow diagram, certificate hierarchy) and 'When to Use This Skill' section — Claude already understands these concepts and the frontmatter covers the use cases.
Add a verification/validation step after each major configuration change, especially before switching from PERMISSIVE to STRICT mode, to prevent service outages.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is extremely verbose at ~300 lines. It includes unnecessary conceptual explanations (mTLS flow diagram, certificate hierarchy) that Claude already knows, a 'When to Use This Skill' section that restates the frontmatter, and extensive templates that could be split into referenced files. The ASCII diagrams and 'Core Concepts' section add significant token cost without teaching Claude anything new. | 1 / 3 |
Actionability | The templates are fully concrete and copy-paste ready YAML configurations for Istio, Linkerd, cert-manager, and SPIRE. The debugging section provides specific executable commands. All code examples are real, not pseudocode. | 3 / 3 |
Workflow Clarity | There is no clear sequenced workflow for implementing mTLS. The skill presents templates and commands but lacks a step-by-step process with validation checkpoints. For a complex, potentially service-disrupting operation like enabling strict mTLS, there are no verification steps between stages (e.g., verify PERMISSIVE works before switching to STRICT), no rollback guidance, and no feedback loops for error recovery. | 1 / 3 |
Progressive Disclosure | This is a monolithic wall of content with five large templates, debugging commands, and best practices all inline. The templates for SPIRE, cert-manager, and Linkerd should be in separate referenced files. The external resource links at the bottom don't compensate for the lack of internal content organization into separate files. | 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
- Dicklesworthstone/pi_agent_rust
- Commit
47823e3
- 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.