managing-network-policies
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 design principles (least privilege, zero-trust). The only minor issue is the slightly awkward opening 'Execute use when' which reads oddly but doesn't materially impact functionality.
| 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 'Execute 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 distinctive with a clear niche: Kubernetes network policies and firewall rules specifically. The trigger terms are domain-specific (NetworkPolicy, pod communication, ingress/egress) and 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 reasonable procedural framework for Kubernetes network policy management but critically lacks concrete YAML manifest examples, which is its biggest weakness given the skill's purpose is to generate NetworkPolicy manifests. The error handling table is a useful addition, but the overall content reads more like a conceptual guide than an actionable skill. The prerequisites section contains information Claude already knows, wasting tokens.
Suggestions
Add complete, copy-paste-ready YAML examples for at least: a default-deny policy, a DNS egress allow policy, and a service-to-service allow policy with label selectors and port specifications.
Remove or drastically shorten the Prerequisites section—Claude knows what CNI plugins are, how kubectl works, and that DNS uses port 53.
Add an explicit validation checkpoint between steps 2 and 3: 'STOP: Verify default-deny is working with `kubectl exec <pod> -- curl <target>` and confirm traffic is blocked before adding allow rules.'
Include a concrete output template showing the expected structure of a generated NetworkPolicy manifest with annotations, rather than just listing what outputs should be produced.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The prerequisites section explains things Claude already knows (what CNI plugins are, that kubectl needs permissions, that DNS uses port 53). The overview restates the description. However, the instructions and error handling table are reasonably efficient. | 2 / 3 |
Actionability | Despite being a skill about generating NetworkPolicy manifests, there are zero YAML examples of actual NetworkPolicy resources. The instructions are procedural descriptions rather than concrete, executable guidance. A skill titled 'Managing Network Policies' should include at least a default-deny manifest and an allow-rule manifest as copy-paste-ready templates. | 1 / 3 |
Workflow Clarity | Steps are listed in a logical sequence and include validation via kubectl exec and CNI logs (steps 6-8), which is good. However, the validation checkpoints are not explicit enough—there's no clear 'stop and verify before proceeding' gate, and the feedback loop (step 8) is vague. For destructive operations like default-deny policies, stronger validation gates are needed. | 2 / 3 |
Progressive Disclosure | The content is organized into clear sections (Overview, Prerequisites, Instructions, Output, Error Handling, Examples, Resources), which is good structure. However, the Resources section links to external docs but there are no bundle files for detailed templates or examples that could be referenced. The Examples section lists prompts rather than linking to detailed example manifests that would benefit from separate files. | 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 | |
- Commit
3a2d27d
- 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.