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.
57
67%
Does it follow best practices?
Impact
—
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 phrasing 'Execute use when' at the beginning, but this doesn't materially impact its effectiveness for skill selection.
| 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 specific niche targeting Kubernetes NetworkPolicy manifests, firewall rules, and pod communication restrictions. The domain-specific terminology (NetworkPolicy, ingress/egress, zero-trust) makes it very unlikely to conflict with other 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 purpose. The workflow is reasonable but the absence of executable, concrete templates significantly undermines its utility. The content is moderately verbose with explanations Claude doesn't need while missing the concrete artifacts that would make it actionable.
Suggestions
Add concrete, complete YAML manifest examples: a default-deny policy, a DNS egress allow policy, and a service-to-service allow policy template that Claude can adapt.
Include executable kubectl commands for applying and testing policies (e.g., `kubectl apply -f`, `kubectl exec -it <pod> -- wget -qO- http://service:port`).
Trim the prerequisites section to remove things Claude already knows (e.g., what CNI plugins are, that DNS uses port 53) and focus on project-specific requirements.
Add explicit validation gates in the workflow (e.g., 'STOP: Only proceed to production namespace after all connectivity tests pass in test namespace').
| 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 error handling table and examples section add useful but somewhat verbose content. The overview restates what the description already covers. | 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 template and an allow-rule template. | 1 / 3 |
Workflow Clarity | The 9-step workflow has a reasonable sequence and includes validation steps (step 6: test with kubectl exec, step 7: monitor CNI logs, step 8: iterate). However, the validation checkpoints are not explicitly marked as gates (e.g., 'only proceed when...'), and the feedback loop between steps 6-8 could be more explicit about when to stop iterating. | 2 / 3 |
Progressive Disclosure | The content is organized into clear sections (Overview, Prerequisites, Instructions, Output, Error Handling, Examples, Resources) which is good structure. However, with no bundle files, the detailed error handling table and extensive prerequisites are inline when they could be separated. The Resources section provides useful external links but there are no internal references to supplementary 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
69c73e9
- 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.