creating-kubernetes-deployments
Deploy applications to Kubernetes with production-ready manifests. Supports Deployments, Services, Ingress, HPA, ConfigMaps, Secrets, StatefulSets, and NetworkPolicies. Includes health checks, resource limits, auto-scaling, and TLS termination. Use when working with creating kubernetes deployments. Trigger with 'creating', 'kubernetes', 'deployments'.
66
81%
Does it follow best practices?
Impact
—
No eval scenarios have been run
Risky
Do not use without reviewing
Quality
Discovery
85%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 description that clearly communicates what the skill does with specific Kubernetes resource types and features. The 'Use when' clause is present but the trigger terms are somewhat narrow, missing common variations like 'k8s', 'pods', 'containers', or 'YAML manifests' that users would naturally use. The description is well-structured and distinctive but could benefit from broader trigger term coverage.
Suggestions
Expand trigger terms to include common variations users would naturally say: 'k8s', 'pods', 'containers', 'cluster deployment', 'YAML manifests', 'kubectl', 'helm'.
Broaden the 'Use when' clause beyond just 'creating' to include scenarios like 'updating', 'scaling', 'configuring', or 'troubleshooting' Kubernetes resources.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Lists multiple specific concrete actions and resource types: Deployments, Services, Ingress, HPA, ConfigMaps, Secrets, StatefulSets, NetworkPolicies, health checks, resource limits, auto-scaling, and TLS termination. | 3 / 3 |
Completeness | Clearly answers both 'what' (deploy applications with production-ready manifests, supporting various Kubernetes resources) and 'when' (explicit 'Use when working with creating kubernetes deployments' clause with trigger terms). | 3 / 3 |
Trigger Term Quality | Includes 'kubernetes' and 'deployments' as trigger terms, and mentions specific resource types, but misses common user variations like 'k8s', 'deploy to cluster', 'helm', 'pods', 'containers', 'YAML manifests', or 'kubectl'. The explicit trigger list ('creating', 'kubernetes', 'deployments') is narrow. | 2 / 3 |
Distinctiveness Conflict Risk | Clearly occupies a distinct niche around Kubernetes deployment manifests with specific resource types listed. Unlikely to conflict with general coding, Docker, or other infrastructure skills due to the specificity of Kubernetes resource types mentioned. | 3 / 3 |
Total | 11 / 12 Passed |
Implementation
77%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This is a solid, highly actionable Kubernetes deployment skill with complete, production-ready YAML manifests and a clear workflow. Its main weaknesses are moderate verbosity (redundant sections at the bottom, repeated comments), a somewhat long inline body that could benefit from better content splitting, and references to bundle files that don't exist. The core content is well-structured and immediately useful.
Suggestions
Remove the redundant 'Overview', 'Prerequisites', and 'Output' sections at the bottom — they add no value and the Overview duplicates the opening line.
Move detailed examples (blue-green deployment, all three health check variants) into referenced files to reduce the main document length and improve progressive disclosure.
Reduce repeated inline comments like '# 8080: HTTP proxy port' — state it once and let Claude infer the pattern.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is mostly efficient with good use of tables and code blocks, but includes some unnecessary content: the 'Overview' and 'Prerequisites' sections at the bottom repeat or state obvious information (e.g., 'Familiarity with Kubernetes concepts'), the 'Output' section is vague filler, and comments like '# 8080: HTTP proxy port' are repeated excessively throughout. The resource limits table and service types table are useful reference material but the overall document could be tightened significantly. | 2 / 3 |
Actionability | The skill provides fully executable, copy-paste ready YAML manifests for every resource type (Deployment, Service, Ingress, HPA, ConfigMap, Secret), concrete kubectl commands for validation and deployment, and specific configuration values with clear explanations. The code examples are complete and production-ready. | 3 / 3 |
Workflow Clarity | The 'Instructions' section provides a clear 4-step workflow from gathering requirements through validation. Step 4 includes explicit validation via dry-run, application, and rollout status monitoring. The error handling table provides quick-fix guidance for common failure modes, creating an implicit feedback loop. | 3 / 3 |
Progressive Disclosure | The skill references external files (errors.md, examples.md, implementation.md, assets/, scripts/) which is good progressive disclosure structure, but no bundle files are provided to back these references. The main file itself is quite long (~300 lines) with substantial inline content that could be split out (e.g., the full blue-green deployment example, the detailed health check variants). The 'Overview', 'Prerequisites', and 'Output' sections at the bottom feel tacked on and disrupt the document's flow. | 2 / 3 |
Total | 10 / 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.