k8s-ops

You are operating against a Kubernetes cluster through the k8s-mcp server. The server already enforces these rules — do not restate them, just follow them:

• Confirm namespace before any operation if not explicitly provided
• Confirm name + namespace + cluster before any destructive op (delete, scale-to-0, restart)
• Use get_current_context to verify the active cluster before changes
• Use list/get tools for discovery rather than guessing

This skill adds workflow sequencing on top of those rules. Pick the mode that matches the user's request.

---

Mode dispatch

User intent	Mode
"deploy this app/repo to my cluster"	deploy
"my pod is crashing / failing / not ready"	debug
"restart / roll out / update this deployment"	rollout
"review RBAC / secrets / who can access what"	audit

If the request blends modes (e.g., "deploy and debug if it fails"), run them in sequence — deploy first, then debug if wait_for_ready reports failure.

---

Mode: deploy

For "deploy this repo / app to a cluster" requests.

Preconditions (confirm with user before touching the cluster)

1. Active cluster — call get_current_context, show the cluster name, ask if it's the right target.
2. Target namespace — if unsure, list_namespaces and ask. Do not default to default.
3. Container image — registry, repo, tag. If the repo has a Dockerfile but no built image, flag that the user must build/push first; do not attempt the build inside this skill.
4. ImagePullSecret — ask only if the registry is private.

Sequence

1. Analyze repo — read Dockerfile, pyproject.toml/package.json, any existing k8s/ or manifests/ directory. If manifests already exist, prefer apply_kustomize or apply_manifest on what's there over generating new ones.
2. Generate manifests if needed — generate_deploy_manifests with the confirmed values. Write to a k8s/ directory in the repo, not a temp dir.
3. Show the plan — list the resources to be created, the namespace, and the cluster. Wait for user approval.
4. Apply — apply_kustomize is required for manifests produced by generate_deploy_manifests: the registry/tag substitution lives in kustomization.yaml's images: field. Applying the individual deployment.yaml with apply_manifest will leave the placeholder image: k8s-mcp and the pod will fail to pull. Use apply_manifest only for hand-written single-document manifests with fully qualified image references.
5. Wait — wait_for_ready with resource_type=deployment, a sensible timeout (120s default; 300s for first-time pulls of large images).
6. Verify — on success, get_deployment + list_pods (label-selector scoped). Report endpoint(s) from get_service if a Service was created.
7. On failure of wait_for_ready — switch to debug mode automatically on the failing pod. Do not retry the apply blindly.