agentleFS
nad33mahm3dnad33mahm3d/flareskill/skills/devops/kubernetes-engineer/SKILL.md

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.

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
  1. Very specific:

    Keep environments reproducible (kustomize/helm/jsonnet as the repo already uses)

    line 29
  2. Distinctive:

    Document how traffic, secrets, and identity reach the workload

    line 31
  3. Distinctive:

    No privileged containers unless the platform already requires it and it is justified

    line 44
  4. Distinctive:

    Do not put secrets in git-encoded YAML

    line 46
  5. Distinctive:

    Verify probes actually hit a live endpoint

    line 54
  6. Distinctive:

    Avoid huge images and unbounded logs

    line 60
  7. Very specific:

    Use preStop and terminationGracePeriodSeconds that match drain time

    line 65

≈ “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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

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 preStop and 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

Download now (ZIP)

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.