container-orchestration
Docker and Kubernetes patterns. Triggers on: Dockerfile, docker-compose, kubernetes, k8s, helm, pod, deployment, service, ingress, container, image.
76
63%
Does it follow best practices?
Impact
100%
1.25xAverage score across 3 eval scenarios
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./data/skills-md/0xdarkmatter/claude-mods/container-orchestration/SKILL.mdQuality
Discovery
54%Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.
The description has strong trigger term coverage with many natural keywords users would use, but it critically lacks any specificity about what the skill actually does — 'patterns' is vague and tells Claude nothing about the concrete actions available. The 'Triggers on:' clause is a reasonable substitute for a 'Use when...' clause, but without describing capabilities, Claude cannot make an informed selection when multiple infrastructure-related skills are available.
Suggestions
Replace 'Docker and Kubernetes patterns' with specific actions like 'Creates Dockerfiles, configures docker-compose services, writes Kubernetes manifests, sets up Helm charts, and debugs container deployments'.
Add a 'Use when...' clause that describes scenarios, e.g., 'Use when the user needs to containerize applications, configure orchestration, or troubleshoot container infrastructure'.
Narrow generic trigger terms like 'service', 'image', and 'deployment' by qualifying them (e.g., 'Kubernetes service', 'container image') to reduce conflict risk with other skills.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | The description says 'Docker and Kubernetes patterns' which is extremely vague. It names the domain but lists zero concrete actions — no verbs like 'create', 'debug', 'configure', 'deploy', or 'optimize' are present. | 1 / 3 |
Completeness | The 'when' is addressed via the 'Triggers on:' clause with explicit keywords, but the 'what' is extremely weak — 'Docker and Kubernetes patterns' doesn't explain what the skill actually does. The trigger list partially compensates but the lack of capability description holds it back. | 2 / 3 |
Trigger Term Quality | Excellent coverage of natural trigger terms users would say: 'Dockerfile', 'docker-compose', 'kubernetes', 'k8s', 'helm', 'pod', 'deployment', 'service', 'ingress', 'container', 'image'. These are terms users naturally use when working in this domain. | 3 / 3 |
Distinctiveness Conflict Risk | The trigger terms like 'service', 'image', 'deployment', and 'container' are quite generic and could overlap with other skills (e.g., cloud deployment, CI/CD, or general service architecture skills). Terms like 'Dockerfile', 'k8s', and 'helm' are distinctive, but the broader terms create conflict risk. | 2 / 3 |
Total | 8 / 12 Passed |
Implementation
72%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 reference skill with excellent actionability — all code examples are complete and production-ready. The main weaknesses are the lack of a deployment workflow with validation steps (e.g., verify image builds, check rollout status after apply) and some redundancy between the Dockerfile example and the DO/DON'T rules list. Progressive disclosure is well-handled with clear references to supplementary files.
Suggestions
Add a sequenced deployment workflow section (e.g., 1. Build image → 2. Verify build → 3. Push → 4. Apply manifests → 5. `kubectl rollout status` to verify → 6. If failing, `kubectl describe pod` to debug)
Remove or significantly trim the 'Dockerfile Rules' DO/DON'T list since the example Dockerfile already demonstrates these practices — or consolidate into inline comments only
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The content is mostly efficient with good examples, but includes some unnecessary comments (e.g., '# Set working directory', '# Copy application code') and explanatory text that Claude already knows. The Dockerfile rules DO/DON'T list restates what the example already demonstrates. | 2 / 3 |
Actionability | All examples are fully executable and copy-paste ready — the Dockerfile, docker-compose.yml, Kubernetes manifests, and kubectl commands are concrete and complete. The kubectl quick reference table is immediately usable. | 3 / 3 |
Workflow Clarity | The skill presents individual resource definitions clearly but lacks a sequenced workflow for deploying (e.g., build image → push → apply manifests → verify rollout). There are no validation checkpoints or feedback loops for the deployment process, which involves potentially destructive operations. | 2 / 3 |
Progressive Disclosure | The main file provides a solid overview with executable examples for the most common patterns, then clearly signals one-level-deep references to advanced Dockerfile patterns, full K8s manifests, Helm patterns, scripts, and asset templates. | 3 / 3 |
Total | 10 / 12 Passed |
Validation
100%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 11 / 11 Passed
Validation for skill structure
No warnings or errors.
- Repository
- NeverSight/skills_feed
- Commit
e437c3c
- 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.