What a Packaged SME Skill Is

Summary

A packaged SME skill is a self-contained bundle of review criteria, decision logic, and example fixes that encodes a subject-matter expert's judgment about container and Kubernetes work so an agent can apply it consistently.
Insight: The value is not the model doing the reviewing - it is the frozen, versioned checklist and rationale that make every review land the same way regardless of who triggers it.
Key Concepts: A skill packages review criteria (what "good" looks like), decision trees (how to branch on evidence), reference fixes (the corrected Dockerfile or manifest), and version pins (which Kubernetes minor and Pod Security Standard it targets).
When to Use: Reach for a packaged skill when the same review, lint, or triage runs across many teams and pull requests and you need the outcome to be repeatable rather than dependent on who is on call.
Limitations/Trade-offs: A skill only knows what you encoded; it drifts out of date as Kubernetes ships new minors and deprecates APIs, so it needs an owner and a review cadence.
Related Topics: Dockerfile review automation, manifest linting, incident triage decision trees, and best-practices version pinning.

Foundations

A packaged SME skill turns tacit expertise into an explicit, portable artifact.

Think of the senior engineer who reviews every Dockerfile and always catches the same mistakes: running as root, unpinned base tags, secrets baked into layers.

That reviewer's knowledge normally lives in their head and disappears when they are on vacation.

A skill captures the checklist, the reasoning behind each item, and the canonical fix, so the review runs the same way every time.

The mental model is a lint rule with a rationale attached.

A plain linter tells you USER is missing; an SME skill explains why running as root widens the blast radius, shows the two-line fix, and cites the Pod Security Standard that would reject the pod anyway.

This matters more in the container and Kubernetes world than almost anywhere else.

The surface area is enormous - Dockerfiles, Compose files, Deployments, probes, resource limits, NetworkPolicies, RBAC - and the failure modes are subtle and expensive.

A skill lets one expert's carefully reasoned criteria scale to hundreds of reviews without that expert being in the room.

Mechanics & Interactions

A skill is structured content, not magic.

At its core it holds three things: the criteria to check, the branching logic to apply, and the artifacts to produce.

The criteria are a checklist expressed as testable statements.

For a Dockerfile skill, one criterion is "the final stage sets a non-root USER"; for a manifest skill, one is "every container declares CPU and memory requests and limits."

Each criterion pairs a check with a rationale and a reference fix, so the output is actionable rather than a bare pass or fail.

The decision logic is where triage skills earn their keep.

An incident skill does not just list symptoms; it branches on evidence such as a pod's STATUS column and the reason in its container state, walking from CrashLoopBackOff to ImagePullBackOff to a NotReady node along a defined path.

The artifacts are the corrected examples the skill returns.

A good Dockerfile skill ships the fixed multi-stage build; a good manifest skill ships the Deployment with probes, limits, and securityContext filled in.

Skills interact with the rest of your platform through the tools that already run in CI.

A skill does not replace Trivy, kube-linter, kubeconform, or kubectl - it orchestrates and interprets them.

The skill decides which checks matter for this repository, runs them, and translates raw findings into prioritized, explained guidance a reviewer can act on.

Advanced Considerations & Applications

The hardest part of a packaged skill is versioning, not authoring.

Kubernetes ships three minors a year and deprecates APIs on a schedule; a skill that lints against PodSecurityPolicy (removed in 1.25) or an old Ingress API is worse than no skill because it is confidently wrong.

Pin each skill to a target Kubernetes minor and a Pod Security Standard level, and record those pins in the skill itself.

When your clusters move to a new minor, the pin is the trigger to re-review the criteria.

Scope discipline is the next trap.

A single skill that tries to review Dockerfiles, lint manifests, and triage incidents becomes unmaintainable; the criteria for each are different and evolve at different rates.

Split by concern - one skill per review surface - and let a best-practices page tie them together.

Skills also need an escape hatch for legitimate exceptions.

A batch job has no readiness probe by design, and a debug image may run as root on purpose.

Encode severities and an explicit waiver mechanism so the skill flags rather than blocks, and so teams can annotate a deliberate deviation instead of fighting the tool.

In production, the biggest payoff is consistency across teams.

When every squad's pull requests get the same Dockerfile and manifest review, platform standards stop depending on which reviewer showed up, and onboarding a new service becomes a matter of passing a known bar.

Common Misconceptions

"A skill is just a prompt."

A prompt is ephemeral phrasing; a skill is a versioned artifact with pinned targets, criteria, decision logic, and reference fixes that you maintain like code.

"The agent's model is doing the expertise."

The model applies the skill, but the expertise lives in the encoded criteria and rationale you wrote; swap the model and a well-built skill still produces the same review.

"Skills replace linters and scanners."

They orchestrate and interpret tools like Trivy, kube-linter, and kubeconform - they do not reimplement them.

"Write it once and you are done."

Skills rot as Kubernetes deprecates APIs and Pod Security Standards evolve; without an owner and a version pin they drift into giving wrong advice.

"One big skill covers everything."

Distinct review surfaces have distinct criteria that change at different rates, so separate skills per concern age far better than a monolith.

FAQs

How is a packaged skill different from a CI job?

A CI job runs fixed commands; a skill adds the reasoning, prioritization, and reference fixes that turn raw tool output into an explained, actionable review.

Does a skill need to run in the cluster?

No - review and lint skills run against source files in CI, and triage skills run against a cluster read-only through kubectl; none of them need in-cluster deployment.

What keeps a skill from going stale?

An explicit version pin to a Kubernetes minor and Pod Security Standard, plus a named owner who re-reviews criteria on each cluster upgrade.

Can one skill target multiple Kubernetes versions?

It can, but keep the supported range narrow and documented; branching criteria across many minors quickly becomes brittle.

Who should own a skill?

The platform or SRE team that owns the standard the skill enforces, so the criteria and the policy stay in sync.

Stack versions: This page was written for Kubernetes 1.36.2, Docker Engine 29.6.1 (BuildKit default), containerd (CRI runtime on nodes), Helm 3, Compose v2, Argo CD (latest - verify at build), and Gateway API (GA - verify controller support at build).

What a Packaged SME Skill Is

Summary

A packaged SME skill is a self-contained bundle of review criteria, decision logic, and example fixes that encodes a subject-matter expert's judgment about container and Kubernetes work so an agent can apply it consistently.
Insight: The value is not the model doing the reviewing - it is the frozen, versioned checklist and rationale that make every review land the same way regardless of who triggers it.
Key Concepts: A skill packages review criteria (what "good" looks like), decision trees (how to branch on evidence), reference fixes (the corrected Dockerfile or manifest), and version pins (which Kubernetes minor and Pod Security Standard it targets).
When to Use: Reach for a packaged skill when the same review, lint, or triage runs across many teams and pull requests and you need the outcome to be repeatable rather than dependent on who is on call.
Limitations/Trade-offs: A skill only knows what you encoded; it drifts out of date as Kubernetes ships new minors and deprecates APIs, so it needs an owner and a review cadence.
Related Topics: Dockerfile review automation, manifest linting, incident triage decision trees, and best-practices version pinning.

Foundations

A packaged SME skill turns tacit expertise into an explicit, portable artifact.

Think of the senior engineer who reviews every Dockerfile and always catches the same mistakes: running as root, unpinned base tags, secrets baked into layers.

That reviewer's knowledge normally lives in their head and disappears when they are on vacation.

A skill captures the checklist, the reasoning behind each item, and the canonical fix, so the review runs the same way every time.

The mental model is a lint rule with a rationale attached.

This matters more in the container and Kubernetes world than almost anywhere else.

The surface area is enormous - Dockerfiles, Compose files, Deployments, probes, resource limits, NetworkPolicies, RBAC - and the failure modes are subtle and expensive.

A skill lets one expert's carefully reasoned criteria scale to hundreds of reviews without that expert being in the room.

Mechanics & Interactions

A skill is structured content, not magic.

At its core it holds three things: the criteria to check, the branching logic to apply, and the artifacts to produce.

The criteria are a checklist expressed as testable statements.

For a Dockerfile skill, one criterion is "the final stage sets a non-root USER"; for a manifest skill, one is "every container declares CPU and memory requests and limits."

Each criterion pairs a check with a rationale and a reference fix, so the output is actionable rather than a bare pass or fail.

The decision logic is where triage skills earn their keep.

The artifacts are the corrected examples the skill returns.

A good Dockerfile skill ships the fixed multi-stage build; a good manifest skill ships the Deployment with probes, limits, and securityContext filled in.

Skills interact with the rest of your platform through the tools that already run in CI.

A skill does not replace Trivy, kube-linter, kubeconform, or kubectl - it orchestrates and interprets them.

The skill decides which checks matter for this repository, runs them, and translates raw findings into prioritized, explained guidance a reviewer can act on.

Advanced Considerations & Applications

The hardest part of a packaged skill is versioning, not authoring.

Pin each skill to a target Kubernetes minor and a Pod Security Standard level, and record those pins in the skill itself.

When your clusters move to a new minor, the pin is the trigger to re-review the criteria.

Scope discipline is the next trap.

A single skill that tries to review Dockerfiles, lint manifests, and triage incidents becomes unmaintainable; the criteria for each are different and evolve at different rates.

Split by concern - one skill per review surface - and let a best-practices page tie them together.

Skills also need an escape hatch for legitimate exceptions.

A batch job has no readiness probe by design, and a debug image may run as root on purpose.

Encode severities and an explicit waiver mechanism so the skill flags rather than blocks, and so teams can annotate a deliberate deviation instead of fighting the tool.

In production, the biggest payoff is consistency across teams.

Common Misconceptions

"A skill is just a prompt."

A prompt is ephemeral phrasing; a skill is a versioned artifact with pinned targets, criteria, decision logic, and reference fixes that you maintain like code.

"The agent's model is doing the expertise."

The model applies the skill, but the expertise lives in the encoded criteria and rationale you wrote; swap the model and a well-built skill still produces the same review.

"Skills replace linters and scanners."

They orchestrate and interpret tools like Trivy, kube-linter, and kubeconform - they do not reimplement them.

"Write it once and you are done."

Skills rot as Kubernetes deprecates APIs and Pod Security Standards evolve; without an owner and a version pin they drift into giving wrong advice.

"One big skill covers everything."

Distinct review surfaces have distinct criteria that change at different rates, so separate skills per concern age far better than a monolith.

FAQs

How is a packaged skill different from a CI job?

A CI job runs fixed commands; a skill adds the reasoning, prioritization, and reference fixes that turn raw tool output into an explained, actionable review.

Does a skill need to run in the cluster?

No - review and lint skills run against source files in CI, and triage skills run against a cluster read-only through kubectl; none of them need in-cluster deployment.

What keeps a skill from going stale?

An explicit version pin to a Kubernetes minor and Pod Security Standard, plus a named owner who re-reviews criteria on each cluster upgrade.

Can one skill target multiple Kubernetes versions?

It can, but keep the supported range narrow and documented; branching criteria across many minors quickly becomes brittle.

Who should own a skill?

The platform or SRE team that owns the standard the skill enforces, so the criteria and the policy stay in sync.

Stack versions: This page was written for Kubernetes 1.36.2, Docker Engine 29.6.1 (BuildKit default), containerd (CRI runtime on nodes), Helm 3, Compose v2, Argo CD (latest - verify at build), and Gateway API (GA - verify controller support at build).

What a Packaged SME Skill Is

Search Documentation

What a Packaged SME Skill Is