container-orchestration

Docker and Kubernetes patterns. Triggers on: Dockerfile, docker-compose, kubernetes, k8s, helm, pod, deployment, service, ingress, container, image.

1.25x

Quality

—

Does it follow best practices?

Impact

100%

1.25x

Average score across 3 eval scenarios

Securityby

Passed

No known issues

Quality

Content

65%

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

The body is highly actionable with complete, executable templates and minimal concept padding, but it lacks an explicit sequenced workflow with validation checkpoints, and its progressive-disclosure references point to bundle files that are not actually present.

Suggestions

Add a short sequenced workflow (build → tag → push → kubectl apply → verify with 'kubectl rollout status') with explicit validation checkpoints, rather than only static templates and a command table.

Create the referenced bundle files (./references/dockerfile-patterns.md, ./references/k8s-manifests.md, ./references/helm-patterns.md, ./scripts/build-push.sh, ./assets/Dockerfile.template, ./assets/docker-compose.template.yml) — currently these paths are cited but do not exist, so progressive-disclosure navigation is broken.

Tighten redundancy: drop the opening line that duplicates the description, and move the more verbose/advanced manifests into the references to reduce inline volume while keeping the quick-start patterns inline.

Dimension	Reasoning	Score
Conciseness	The body is code-forward with no concept padding (no 'what is a container' prose) and useful inline comments, but it carries a large volume of full inline manifests and some redundancy (the opening line duplicates the description; healthcheck patterns appear in both Dockerfile and compose), so it is mostly efficient but could be tightened per anchor 2.	2 / 3
Actionability	It provides fully executable, copy-paste-ready artifacts — a complete multi-stage Dockerfile, docker-compose.yml, k8s Deployment/Service/Ingress manifests, and a kubectl command table — matching anchor 3's 'fully executable code/commands; copy-paste ready'.	3 / 3
Workflow Clarity	The content is a patterns/reference collection, not a sequenced workflow; there are implicit validation patterns (HEALTHCHECK, probes, depends_on condition: service_healthy, kubectl rollout status) but no explicit build→push→apply→verify sequence with checkpoints, so it matches anchor 2's 'sequence present but checkpoints missing or implicit'.	2 / 3
Progressive Disclosure	Sections are well-organized and references are clearly signaled and one-level-deep, but the cited bundle files (./references/.md, ./scripts/build-push.sh, ./assets/.template) do not exist on disk, so the navigation is broken — per the guideline to score against the actual bundle structure, this caps the score below 3.	2 / 3
	Total	9 / 12 Passed

Description

82%

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, natural trigger coverage and an explicit trigger clause, but its 'what' is abstract ('patterns' with no concrete actions) and a few generic trigger terms create mild conflict risk.

Suggestions

Replace the abstract phrase 'Docker and Kubernetes patterns' with concrete actions, e.g. 'Write Dockerfiles, docker-compose files, and Kubernetes manifests to build and deploy containerized applications'.

Narrow generic trigger terms like 'image', 'service', and 'deployment' to container-specific phrasing (e.g. 'container image', 'k8s service', 'k8s deployment') to reduce conflict with image-processing or generic deployment skills.

Dimension	Reasoning	Score
Specificity	It names the domain concretely ('Docker and Kubernetes patterns') but lists no concrete actions — 'patterns' is an abstract noun with no verbs like 'build', 'deploy', or 'configure', so it sits above anchor 1 (vague) yet below anchor 3 (multiple specific actions).	2 / 3
Completeness	It explicitly answers both 'what' (Docker and Kubernetes patterns) and 'when' via the explicit 'Triggers on:' clause, which is equivalent trigger guidance to a 'Use when...' clause, satisfying anchor 3 and avoiding the cap-at-2 guideline.	3 / 3
Trigger Term Quality	The 'Triggers on' list (Dockerfile, docker-compose, kubernetes, k8s, helm, pod, deployment, service, ingress, container, image) gives broad, natural coverage including the common 'k8s' abbreviation, matching anchor 3's good coverage of terms users would actually say.	3 / 3
Distinctiveness Conflict Risk	Most triggers (Dockerfile, docker-compose, k8s, helm, pod, ingress) are distinct, but 'image', 'service', and 'deployment' are generic and could fire for image-processing or generic deployment skills, so it is 'somewhat specific but could overlap' per anchor 2 rather than cleanly distinct.	2 / 3
	Total	10 / 12 Passed

Validation

100%

Warnings & errors only

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation — 16 / 16 Passed

Validation for skill structure

No warnings or errors.

Repository: NeverSight/skills_feed
Commit: 26d37ce

Reviewed: about 15 hours ago

Table of Contents

Discovery Implementation Validation

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.