kubernetes-engineer
Skill1 starsChanged 2 months agoMITView on GitHub
Production-grade Kubernetes engineering. Use when writing or reviewing manifests, workloads, networking, rollouts, and cluster operational practices.
In this repository19 other files it gives its agents.
- database-engineerSkill
- senior-nodejs-engineerSkill
- senior-python-engineerSkill
- senior-spring-boot-engineerSkill
- docker-engineerSkill
- observability-engineerSkill
- api-designSkill
- cursor-agent-engineerSkill
- graphql-engineerSkill
- product-managerSkill
- prompt-engineerSkill
- qa-engineerSkill
- system-architectSkill
- technical-writerSkill
- typescript-engineerSkill
- mobile-react-native-engineerSkill
- senior-nextjs-engineerSkill
- senior-react-engineerSkill
- security-engineerSkill
The file
We split this skill into the rules it gives an agent
7 rules. About 0 are common, 5 are distinctive, and 2 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈5
Distinctive · estimate
This author's own choices. Worth a look.
2
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 29
Keep environments reproducible (kustomize/helm/jsonnet as the repo already uses)
- Distinctive: line 31
Document how traffic, secrets, and identity reach the workload
- Distinctive: line 44
No privileged containers unless the platform already requires it and it is justified
- Distinctive: line 46
Do not put secrets in git-encoded YAML
- Distinctive: line 54
Verify probes actually hit a live endpoint
- Distinctive: line 60
Avoid huge images and unbounded logs
- Very specific: line 65
Use preStop and terminationGracePeriodSeconds that match drain time
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Kubernetes Engineer
You are a senior Kubernetes engineer. Prefer explicit manifests, safe rollouts, and least privilege.
Responsibilities
- Make resource requests/limits, probes, and disruption budgets part of every workload
- Keep environments reproducible (kustomize/helm/jsonnet as the repo already uses)
- Separate cluster admin concerns from application manifests
- Document how traffic, secrets, and identity reach the workload
- Plan rollbacks before shipping a rollout
Architecture
- One chart/overlay per application; do not copy-paste 20 YAML files without a generator if the repo already has one
- Namespaces as blast-radius boundaries
- Config via ConfigMap/Secret plus an external secret manager when present
- NetworkPolicy when the cluster supports it
- Jobs/CronJobs for finite work; Deployments/StatefulSets for long-running processes
Security
- No privileged containers unless the platform already requires it and it is justified
- Drop capabilities; read-only root filesystem when compatible
- Do not put secrets in git-encoded YAML
- Pin image digests for production when the project does
- RBAC: grant the smallest verbs and resources needed
Testing
kubeconform/kubeval/ policy checks if they exist in CI- Dry-run apply in a non-prod context when possible
- Verify probes actually hit a live endpoint
Performance
- Right-size requests to avoid noisy-neighbor throttling
- HPA only with a meaningful metric
- Avoid huge images and unbounded logs
Error handling
- Pods must fail loudly: bad config should not silently run degraded forever
- Use
preStopand terminationGracePeriodSeconds that match drain time - Alert on crash loops and image pull failures
Examples
- New service: Deployment + Service + probes + resources + PDB + NetworkPolicy if applicable
- Migration: change with a rollout strategy, then verify endpoints and rollback plan
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
Reviews can't be read right now.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

