Execute use when managing Kubernetes network policies and firewall rules. Trigger with phrases like "create network policy", "configure firewall rules", "restrict pod communication", or "setup ingress/egress rules". Generates Kubernetes NetworkPolicy manifests following least privilege and zero-trust principles.
72
67%
Does it follow best practices?
Impact
Pending
No eval scenarios have been run
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./plugins/devops/network-policy-manager/skills/managing-network-policies/SKILL.mdQuality
Discovery
100%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 strong skill description that clearly defines its scope around Kubernetes network policies and firewall rules. It provides explicit trigger phrases, concrete actions, and a clear 'when to use' clause. The only minor issue is the slightly awkward opening 'Execute use when' which appears to be a grammatical error, but it doesn't significantly impact comprehension.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Lists multiple specific concrete actions: managing Kubernetes network policies, configuring firewall rules, restricting pod communication, setting up ingress/egress rules, and generating NetworkPolicy manifests following least privilege and zero-trust principles. | 3 / 3 |
Completeness | Clearly answers both 'what' (generates Kubernetes NetworkPolicy manifests following least privilege and zero-trust principles) and 'when' (explicit trigger phrases and use-case guidance with 'Use when managing Kubernetes network policies and firewall rules'). | 3 / 3 |
Trigger Term Quality | Includes highly natural trigger phrases users would actually say: 'create network policy', 'configure firewall rules', 'restrict pod communication', 'setup ingress/egress rules'. These cover common variations of how users would request this functionality. | 3 / 3 |
Distinctiveness Conflict Risk | Highly specific niche targeting Kubernetes NetworkPolicy manifests and firewall rules with distinct triggers like 'network policy', 'ingress/egress rules', and 'restrict pod communication'. Unlikely to conflict with general Kubernetes deployment or other infrastructure skills. | 3 / 3 |
Total | 12 / 12 Passed |
Implementation
35%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This skill provides a well-structured procedural guide for Kubernetes network policy management but critically lacks any actual YAML manifest examples, which is its primary stated purpose ('Generates Kubernetes NetworkPolicy manifests'). The workflow is logically sequenced but validation steps are implicit rather than explicit gates. The content would benefit enormously from concrete, executable NetworkPolicy YAML templates rather than prose descriptions of what to create.
Suggestions
Add concrete, executable YAML examples: at minimum a default-deny ingress/egress policy, a DNS egress allow policy, and a service-to-service allow policy template that Claude can adapt.
Add explicit validation checkpoints with specific commands, e.g., 'After applying default-deny, run: kubectl exec -n <ns> <pod> -- wget -qO- --timeout=2 <target> and confirm connection is refused BEFORE adding allow rules.'
Trim the Prerequisites section—Claude knows what CNI plugins are and what DNS does; reduce to just the actionable requirements (e.g., 'Requires CNI with NetworkPolicy support; ensure pod labels are consistent').
Convert the Examples section from natural language prompts into actual input/output pairs showing a request and the corresponding generated YAML manifest.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The content is reasonably structured but includes some unnecessary explanation Claude would already know (e.g., what CNI plugins are, what zero-trust means, the prerequisites section explaining DNS requirements). The error handling table and examples section add bulk without providing executable specifics. | 2 / 3 |
Actionability | Despite being about generating Kubernetes NetworkPolicy manifests, the skill contains zero actual YAML manifests or executable code examples. The instructions are procedural descriptions rather than concrete, copy-paste-ready templates. A skill about generating manifests should include at least a default-deny policy YAML and an allow-rule YAML example. | 1 / 3 |
Workflow Clarity | Steps are listed in a logical sequence with validation mentioned (step 6: kubectl exec tests, step 7: monitoring CNI logs), but the validation checkpoints are not explicit enough—there's no clear 'stop and verify before proceeding' gate, and the feedback loop in step 8 is vague rather than structured with specific recovery actions. | 2 / 3 |
Progressive Disclosure | The content is organized into clear sections (Overview, Prerequisites, Instructions, Output, Error Handling, Examples, Resources) which is good, but it's somewhat monolithic—the error handling table and examples could be more concise inline with detailed content split to referenced files. The Resources section with external links is helpful but the skill itself tries to cover everything in one file. | 2 / 3 |
Total | 7 / 12 Passed |
Validation
81%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 9 / 11 Passed
Validation for skill structure
| Criteria | Description | Result |
|---|---|---|
allowed_tools_field | 'allowed-tools' contains unusual tool name(s) | Warning |
frontmatter_unknown_keys | Unknown frontmatter key(s) found; consider removing or moving to metadata | Warning |
Total | 9 / 11 Passed | |
70e9fa4
Table of Contents
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.