Claude Skills for Kubernetes: Manifest Review Templates

Claude skills for Kubernetes are saved prompt instructions that review manifests against a consistent checklist and prepare changes for human sign-off. They do not apply changes to a cluster. They help an engineer produce a reviewed, documented change request before a person decides whether to proceed.

Tools like fenbs store the operational decisions alongside the skills: which resource limits apply, which namespaces are production-only, which security policies are mandatory. A connected assistant reads those before reviewing a manifest, so the output reflects your cluster's actual rules rather than generic Kubernetes guidance.

What Kubernetes manifest review skills cover

A manifest review has two main concerns: security configuration and resource management. Security checks look for privilege escalation paths, missing security contexts, and over-broad RBAC permissions. A container running as root with no security context is a risk in any environment. A container with privileged: true has effectively root access to the host node.

Resource checks look for missing limits, unrealistic requests, and configurations that will cause scheduling problems. A container without resource limits can consume all available memory on a node, causing other workloads to be evicted. A container without readiness probes can receive traffic before it is ready to handle requests.

A third area is configuration hygiene: hardcoded secrets in environment variables, missing namespace declarations, and using the latest image tag. The latest tag makes deployments non-deterministic: two pods started from the same manifest can run different versions of the same image if a new build was pushed between them.

A skill for reviewing a Kubernetes manifest

This skill reads a manifest and checks it against security and resource criteria. Adjust the checklist items to reflect your cluster's actual policies. A development cluster may allow patterns that production explicitly forbids. The environment field in the skill input lets the review apply the right standard.

Review the following Kubernetes manifest.

Manifest purpose: {{what this manifest deploys or configures}}
Target environment: {{development | staging | production}}
Cluster context: {{any cluster-specific constraints or policies}}

Manifest:
{{paste the YAML}}

Check each item and mark Pass, Fail, or Not applicable:

Security:
- [ ] No containers running as root (runAsNonRoot: true or specific UID)
- [ ] securityContext is set at container level
- [ ] No privileged: true unless explicitly required
- [ ] readOnlyRootFilesystem: true where applicable
- [ ] No hostNetwork, hostPID, or hostIPC unless required
- [ ] Image tags are not "latest"
- [ ] RBAC permissions are scoped to the minimum required

Resources:
- [ ] CPU and memory requests are set on all containers
- [ ] CPU and memory limits are set on all containers
- [ ] Liveness and readiness probes are configured
- [ ] No single replica for a production deployment

Configuration:
- [ ] Secrets are not hardcoded in environment variables or args
- [ ] ConfigMaps and Secrets are referenced, not inlined
- [ ] Namespace is explicitly set

For each Fail: Field | Problem (one sentence) | Suggested fix (one sentence).
End with: Safe to apply to {{environment}}: Yes | No | With changes.

The "Not applicable" option matters here. A CronJob manifest does not need a readiness probe. A ConfigMap manifest does not need a security context. Marking these as not applicable prevents the checklist from producing false positives that reduce its usefulness over time.

For clusters using PodSecurityAdmission, some of these checks are enforced at the API server level. The review skill still catches them before the apply, which is faster feedback. A failed PodSecurityAdmission check at apply time costs a round trip to the cluster. A review skill catches it before you open a terminal.

A skill for preparing a change for human approval

Before applying a manifest change to a cluster, a pre-apply checklist confirms that the operational steps are complete. This skill produces a structured change request summary for the person who will approve the apply. It is also a record that the review happened, which is useful for audits and post-incident reviews.

Prepare a change request summary for the following Kubernetes change.

Change description: {{what is changing and why}}
Manifest reviewed: Yes | No (if No, run the manifest review skill first)
Target cluster: {{cluster name or context}}
Target namespace: {{namespace}}
Planned apply window: {{time and date}}

Pre-apply checklist:
- [ ] Manifest review complete and issues resolved
- [ ] Change tested in a lower environment
- [ ] Rollback procedure identified (kubectl rollout undo or manual steps)
- [ ] On-call engineer notified if applying outside business hours
- [ ] Monitoring alert thresholds checked

Output:

Change summary (two sentences): what changes and the expected outcome
Risk level: Low | Medium | High with one-sentence reason
Rollback procedure: [specific commands or steps]
Approval required from: [role or person]
Status: Ready for approval | Blocked on [item]

The rollback procedure field is the one most often skipped in informal change processes. Documenting it before the apply means that if something goes wrong, the person responding does not have to think through the rollback steps under pressure. For most Deployments and StatefulSets, kubectl rollout undo is the rollback command, but database schema changes or persistent volume claims require more specific procedures.

Risk level is assessed based on the scope of the change, not just its size. A one-line change to a resource limit is low risk. A change to a security context on a production workload is medium risk even if the diff is small. An update to a shared ConfigMap that multiple deployments read is high risk regardless of the change size.

Recording operational decisions

Cluster policies evolve over time. A new compliance requirement adds a security context rule. An incident adds a resource limit policy. When those decisions live only in a runbook or a chat thread, the next review misses them. The engineer running the review may not know the policy exists.

Recording each policy decision in fenbs with the date and reason means the review skill applies the current policy without anyone having to remind the reviewer. It also gives the team a clear record when a policy is questioned: who decided it, when, and what problem it was solving. That record prevents a future review from quietly removing a mandatory check without understanding why it was added. Cluster policies without a documented reason tend to disappear the next time someone is in a hurry.

How to do this with fenbs

1. Create a free account and add a project for each cluster or team.
2. Add each skill to Skills and prompts: "Kubernetes manifest review", "Change preparation".
3. Add the cluster's security policies, resource limit requirements, and approval procedures as Decisions and rules.
4. Connect Claude over MCP from Integrations. Ask Claude to read the operational rules before running a manifest review.
5. After each incident caused by a configuration issue, add a lesson and update the checklist to catch it next time.

For broader skill patterns, see Claude skills examples. For setting up skills in a project, see how to create a Claude skill. The official Kubernetes documentation↗ (opens in a new tab) covers security context and RBAC references for building out your checklist.