agentsclimarketplace

Kubernetes specialist

Skill PIXARTSeu/Synapse/.agents/skills/kubernetes-specialist

Use when deploying or managing Kubernetes workloads. Invoke to create deployment manifests, configure pod security policies, set up service accounts, define network isolation rules, debug pod crashes, analyze resource limits, inspect container logs, or right-size workloads. Use for Helm charts, RBAC policies, NetworkPolicies, storage configuration, performance optimization, GitOps pipelines, and multi-cluster management.From its SKILL.md

Install
npx -y skills add PIXARTSeu/Synapse --skill kubernetes-specialist

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

  • no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
  • 8 stars8 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its file declares

Copied from the file, not written here

The file declares its own license as MIT. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.

SKILL.md

7.9 KB, ~1.6k tokens by cl100k_base, as published. Nobody here has run it

Kubernetes Specialist

When to Use This Skill

  • Deploying workloads (Deployments, StatefulSets, DaemonSets, Jobs)
  • Configuring networking (Services, Ingress, NetworkPolicies)
  • Managing configuration (ConfigMaps, Secrets, environment variables)
  • Setting up persistent storage (PV, PVC, StorageClasses)
  • Creating Helm charts for application packaging
  • Troubleshooting cluster and workload issues
  • Implementing security best practices

Core Workflow

  1. Analyze requirements — Understand workload characteristics, scaling needs, security requirements
  2. Design architecture — Choose workload types, networking patterns, storage solutions
  3. Implement manifests — Create declarative YAML with proper resource limits, health checks
  4. Secure — Apply RBAC, NetworkPolicies, Pod Security Standards, least privilege
  5. Validate — Run kubectl rollout status, kubectl get pods -w, and kubectl describe pod <name> to confirm health; roll back with kubectl rollout undo if needed

Reference Guide

Load detailed guidance based on context:

TopicReferenceLoad When
Workloadsreferences/workloads.mdDeployments, StatefulSets, DaemonSets, Jobs, CronJobs
Networkingreferences/networking.mdServices, Ingress, NetworkPolicies, DNS
Configurationreferences/configuration.mdConfigMaps, Secrets, environment variables
Storagereferences/storage.mdPV, PVC, StorageClasses, CSI drivers
Helm Chartsreferences/helm-charts.mdChart structure, values, templates, hooks, testing, repositories
Troubleshootingreferences/troubleshooting.mdkubectl debug, logs, events, common issues
Custom Operatorsreferences/custom-operators.mdCRD, Operator SDK, controller-runtime, reconciliation
Service Meshreferences/service-mesh.mdIstio, Linkerd, traffic management, mTLS, canary
GitOpsreferences/gitops.mdArgoCD, Flux, progressive delivery, sealed secrets
Cost Optimizationreferences/cost-optimization.mdVPA, HPA tuning, spot instances, quotas, right-sizing
Multi-Clusterreferences/multi-cluster.mdCluster API, federation, cross-cluster networking, DR

Constraints

MUST DO

  • Use declarative YAML manifests (avoid imperative kubectl commands)
  • Set resource requests and limits on all containers
  • Include liveness and readiness probes
  • Use secrets for sensitive data (never hardcode credentials)
  • Apply least privilege RBAC permissions
  • Implement NetworkPolicies for network segmentation
  • Use namespaces for logical isolation
  • Label resources consistently for organization
  • Document configuration decisions in annotations

MUST NOT DO

  • Deploy to production without resource limits
  • Store secrets in ConfigMaps or as plain environment variables
  • Use default ServiceAccount for application pods
  • Allow unrestricted network access (default allow-all)
  • Run containers as root without justification
  • Skip health checks (liveness/readiness probes)
  • Use latest tag for production images
  • Expose unnecessary ports or services

Common YAML Patterns

Deployment with resource limits, probes, and security context

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
  namespace: my-namespace
  labels:
    app: my-app
    version: "1.2.3"
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
        version: "1.2.3"
    spec:
      serviceAccountName: my-app-sa   # never use default SA
      securityContext:
        runAsNonRoot: true
        runAsUser: 1000
        fsGroup: 2000
      containers:
        - name: my-app
          image: my-registry/my-app:1.2.3   # never use latest
          ports:
            - containerPort: 8080
          resources:
            requests:
              cpu: "100m"
              memory: "128Mi"
            limits:
              cpu: "500m"
              memory: "512Mi"
          livenessProbe:
            httpGet:
              path: /healthz
              port: 8080
            initialDelaySeconds: 15
            periodSeconds: 20
          readinessProbe:
            httpGet:
              path: /ready
              port: 8080
            initialDelaySeconds: 5
            periodSeconds: 10
          securityContext:
            allowPrivilegeEscalation: false
            readOnlyRootFilesystem: true
            capabilities:
              drop: ["ALL"]
          envFrom:
            - secretRef:
                name: my-app-secret   # pull credentials from Secret, not ConfigMap

Minimal RBAC (least privilege)

apiVersion: v1
kind: ServiceAccount
metadata:
  name: my-app-sa
  namespace: my-namespace
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: my-app-role
  namespace: my-namespace
rules:
  - apiGroups: [""]
    resources: ["configmaps"]
    verbs: ["get", "list"]   # grant only what is needed
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: my-app-rolebinding
  namespace: my-namespace
subjects:
  - kind: ServiceAccount
    name: my-app-sa
    namespace: my-namespace
roleRef:
  kind: Role
  name: my-app-role
  apiGroup: rbac.authorization.k8s.io

NetworkPolicy (default-deny + explicit allow)

# Deny all ingress and egress by default
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: my-namespace
spec:
  podSelector: {}
  policyTypes: ["Ingress", "Egress"]
---
# Allow only specific traffic
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-my-app
  namespace: my-namespace
spec:
  podSelector:
    matchLabels:
      app: my-app
  policyTypes: ["Ingress"]
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: frontend
      ports:
        - protocol: TCP
          port: 8080

Validation Commands

After deploying, verify health and security posture:

# Watch rollout complete
kubectl rollout status deployment/my-app -n my-namespace

# Stream pod events to catch crash loops or image pull errors
kubectl get pods -n my-namespace -w

# Inspect a specific pod for failures
kubectl describe pod <pod-name> -n my-namespace

# Check container logs
kubectl logs <pod-name> -n my-namespace --previous   # use --previous for crashed containers

# Verify resource usage vs. limits
kubectl top pods -n my-namespace

# Audit RBAC permissions for a service account
kubectl auth can-i --list --as=system:serviceaccount:my-namespace:my-app-sa

# Roll back a failed deployment
kubectl rollout undo deployment/my-app -n my-namespace

Output Templates

When implementing Kubernetes resources, provide:

  1. Complete YAML manifests with proper structure
  2. RBAC configuration if needed (ServiceAccount, Role, RoleBinding)
  3. NetworkPolicy for network isolation
  4. Brief explanation of design decisions and security considerations

What ships with it: 11 files

121.6 KB alongside SKILL.md

Gives 0 of the 12 instructions most performance cost skills give in ~1.6k tokens

Counted across 797 of the 1,117 authors here whose files we hold, read 2026-09-06

  • Check for product marketing context firstin 46 of 797, across 20 files
  • Measure before optimizingin 31 of 797, across 25 files
  • Profile first to identify the actual bottleneckin 23 of 797, across 22 files
  • Verify your robots.txt allows AI crawlersin 21 of 797, across 12 files
  • Import directly and avoid barrel filesin 19 of 797, across 15 files
  • Spawn all runs in the same turnin 18 of 797, across 11 files
  • Write a draft of the skillin 17 of 797, across 10 files
  • Understand the user's intentin 17 of 797, across 10 files
  • Use React.cache for per-request deduplicationin 16 of 797, across 11 files
  • Profile before optimizingin 16 of 797, across 14 files
  • Include specific numbers with sourcesin 15 of 797, across 8 files
  • Add lazy loading to below-fold imagesin 15 of 797, across 10 files

Said here and by no other author read

  • Use declarative YAML manifests
  • Set resource requests and limits
  • Include liveness and readiness probes
  • Use secrets for sensitive data
  • Implement NetworkPolicies for segmentation
  • Use namespaces for logical isolation

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.

Keep looking

Skills are one crate of 325,949. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.