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.

1.02x

Quality

71%

Does it follow best practices?

Impact

97%

1.02x

Average score across 3 eval scenarios

Securityby

Passed

No findings from the security scan

Fix and improve this skill with Tessl

tessl review fix ./tests/ext_conformance/artifacts/agents-wshobson/cloud-infrastructure/skills/mtls-configuration/SKILL.md

The canonical home for this skill is mtls-configuration in wshobson/agents

Quality

Content

65%Weight 40%Scale 1-5

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

A highly actionable reference with comprehensive, executable templates for the major mTLS stacks, but it reads as a dump of inline configurations rather than a guided skill. It lacks a sequenced migration/verification workflow and would benefit from moving the bulky templates into referenced files.

Suggestions

Add a numbered PERMISSIVE-to-STRICT migration workflow with explicit validation checkpoints (e.g. '1. Enable PERMISSIVE 2. Verify traffic with linkerd viz edges / istioctl authn tls-check 3. Only then switch to STRICT').

Move the five large templates into separate reference files (e.g. references/istio.md, references/linkerd.md, references/spire.md) and keep a short overview in SKILL.md.

Remove the ASCII mTLS flow and certificate-hierarchy diagrams plus the 'When to Use This Skill' section — they restate concepts Claude already knows and duplicate the frontmatter description.

Dimension	Reasoning	Score
Conciseness	The bulk is configuration templates, but the ASCII mTLS handshake diagram, the certificate-hierarchy diagram, and the 'When to Use This Skill' list (which duplicates the frontmatter description) explain concepts Claude already knows and could be trimmed.	3 / 5
Actionability	Five complete, copy-paste YAML templates (PeerAuthentication STRICT/PERMISSIVE/workload-level, DestinationRule ISTIO_MUTUAL/SIMPLE/MUTUAL, cert-manager issuer/certificate, SPIRE server config) plus executable verification commands ('istioctl proxy-config secret deploy/my-app -o json \| jq ...', 'linkerd viz edges deployment -n my-namespace') cover the common cases across Istio, Linkerd, cert-manager, and SPIRE.	5 / 5
Workflow Clarity	There is no sequenced workflow: 'Start with PERMISSIVE - Migrate gradually to STRICT' hints at a migration process, but no numbered steps or validation checkpoints tie the debugging commands into an explicit verify-then-proceed loop.	3 / 5
Progressive Disclosure	The ~345-line body is entirely inline with no bundle files; the five large templates are exactly the content that belongs in separate reference files. Section headers are clear and well-organized, but bulk detail is inlined rather than split out.	3 / 5
	Total	14 / 20 Passed

Description

78%Weight 40%Scale 1-5

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

A well-formed description with an explicit 'Use when' clause and concrete trigger phrases that clearly answer both what and when. Its main weakness is thin capability coverage — a single 'Configure' action — and a somewhat broad certificate-management trigger that could collide with a general cert skill.

Suggestions

List 2-3 more concrete capabilities in the description (e.g. 'enable strict mTLS in Istio or Linkerd, rotate workload certificates, debug TLS handshake failures') to raise specificity.

Add natural trigger variations such as 'cert rotation', 'TLS certificates', or 'service mesh security' that users would actually say.

Narrow the 'certificate management' trigger (e.g. 'mTLS certificate rotation and CA management') to reduce overlap with a general certificate-management skill.

Dimension	Reasoning	Score
Specificity	Names the domain ("mutual TLS (mTLS) for zero-trust service-to-service communication") and one concrete action ("Configure"), but lists no further specific actions such as certificate rotation, mesh policy enforcement, or handshake debugging, so it stops at 1-2 concrete actions rather than several.	3 / 5
Completeness	Explicitly answers both: what ("Configure mutual TLS (mTLS) for zero-trust service-to-service communication") and when ("Use when implementing zero-trust networking, certificate management, or securing internal service communication") with three concrete trigger phrases, mirroring the anchor-5 structure.	5 / 5
Trigger Term Quality	Natural trigger phrases like "zero-trust networking", "certificate management", and "securing internal service communication" give good coverage, but common variations users would say (e.g. "cert rotation", "TLS certificates", tool names like Istio or Linkerd) are missing.	4 / 5
Distinctiveness Conflict Risk	The mTLS/zero-trust niche is clearly distinguishable, but the "certificate management" trigger is broad enough to overlap with a general certificate-management skill, leaving minor conflict risk rather than minimal.	4 / 5
	Total	16 / 20 Passed

Validation

100%

Warnings & errors only

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation — 16 / 16 Passed

Validation for skill structure

No warnings or errors.

Repository: Dicklesworthstone/pi_agent_rust
Path: tests/ext_conformance/artifacts/agents-wshobson/cloud-infrastructure/skills/mtls-configuration/SKILL.md
Commit: 38d4f88

Reviewed: 3 days ago

Table of Contents

Discovery Implementation Validation

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.