container-orchestration
Docker and Kubernetes patterns. Triggers on: Dockerfile, docker-compose, kubernetes, k8s, helm, pod, deployment, service, ingress, container, image.
69
53%
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 for the Docker/Kubernetes domain but critically lacks any concrete description of what the skill actually does — 'patterns' is vague and uninformative. The trigger list is well-constructed but some terms like 'service', 'image', and 'deployment' risk false positives. Adding specific capabilities (e.g., 'write Dockerfiles, configure Kubernetes manifests, debug pod issues') would significantly improve this description.
Suggestions
Replace 'Docker and Kubernetes patterns' with specific actions like 'Writes Dockerfiles, configures docker-compose files, creates Kubernetes manifests, debugs pod issues, sets up Helm charts'
Add a 'Use when...' clause that clarifies the scope, e.g., 'Use when the user needs help containerizing applications, writing deployment configs, or troubleshooting container orchestration'
Qualify ambiguous trigger terms like 'service', 'image', and 'deployment' by noting they apply in a container/orchestration context to reduce conflict risk
| 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', and 'deployment' are generic enough to conflict with other skills (e.g., cloud deployment, web services, image processing). Terms like 'Dockerfile', 'k8s', and 'helm' are distinctive, but the overlap risk from generic terms is notable. | 2 / 3 |
Total | 8 / 12 Passed |
Implementation
52%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
The skill provides high-quality, executable reference examples for Docker and Kubernetes configurations, making it strong on actionability. However, it functions more as a reference card than an instructional skill — it lacks workflow sequencing for multi-step container operations (build, deploy, validate, debug) and some inline comments explain things Claude already knows. The referenced bundle files don't exist, weakening the progressive disclosure structure.
Suggestions
Add a sequenced workflow section (e.g., 'Build → Test locally → Push → Deploy → Verify rollout → Debug if needed') with explicit validation checkpoints like checking `kubectl rollout status` before proceeding.
Remove inline comments that explain obvious concepts (e.g., '# Set working directory', '# Copy application code') to improve conciseness.
Provide the referenced bundle files (dockerfile-patterns.md, k8s-manifests.md, helm-patterns.md, templates) or remove the references if they don't exist.
Add a troubleshooting/debugging workflow: e.g., 'Pod not starting? → kubectl describe pod → check events → kubectl logs → fix and redeploy'.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The content is mostly efficient with good examples, but includes some unnecessary comments in the Dockerfile (e.g., '# Set working directory', '# Copy application code') and the DO/DON'T list partially restates what the Dockerfile example already demonstrates. Claude already knows basic Docker and K8s concepts. | 2 / 3 |
Actionability | All examples are fully executable and copy-paste ready: complete Dockerfile with multi-stage build, working docker-compose.yml, full K8s manifests (Deployment, Service, Ingress), and a practical kubectl command reference table. These are concrete, real-world configurations. | 3 / 3 |
Workflow Clarity | There is no sequenced workflow for multi-step processes. Building, deploying, and debugging containers involves multiple steps with potential failure points, but the skill presents isolated reference snippets without any process flow, validation checkpoints, or error recovery guidance (e.g., no 'build → test → push → deploy → verify' workflow). | 1 / 3 |
Progressive Disclosure | The skill references external files (references/, scripts/, assets/) which suggests good structure, but no bundle files are actually provided, making these references dead links. The main content is fairly long with inline manifests that could be split out, though the section headers provide reasonable navigation. | 2 / 3 |
Total | 8 / 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
2d09b29
- 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.