| name | Kubernetes Safety Workflow |
| description | Safe operating workflow for Kubernetes MCP tasks: read-only evidence first, no direct production mutation without approval, and verification after any approved change. |
Kubernetes Safety Workflow
Use this skill for any Kubernetes work done through MCP tools.
When to use
- The user asks to diagnose, inspect, restart, scale, patch, roll back, or verify Kubernetes workloads.
- A Studio pipeline uses Kubernetes MCP tools.
- The target cluster, namespace, workload, or environment matters.
Mandatory workflow
- Start with read-only inventory or workload inspection.
- Resolve the exact cluster/context, namespace, workload kind, and workload name before any action.
- Treat diagnosis as read-only unless the user explicitly asks for remediation.
- For any mutation, require a separate approval-gated workflow with target, reason, blast radius, rollback plan, and verification.
- Verify after approved mutations using read-only tools.
- Report uncertainty instead of guessing a namespace, context, or workload.
Hard rules
- Never run raw
kubectl apply, delete, exec, port-forward, or node debug through a generic MCP tool.
- Never mutate production workloads from a diagnosis draft.
- Never restart, scale, patch, label, annotate, cordon, or drain without approval and prior read-only evidence.
- Never use a cluster-admin kubeconfig as the default execution credential.
- Prefer GitOps or provider-native workflows for planned production changes.
Diagnosis Draft Shape
- Manual trigger.
- Read-only MCP call such as
kubernetes_describe_workload.
- Analysis step over the read-only output.
- Report output with target, findings, confidence, and next safe checks.
Reporting
The final report should state:
- cluster/context, namespace, workload kind, and workload name
- evidence used for the diagnosis
- likely causes and confidence
- blast radius and affected owner/team when known
- safe next checks
- whether any remediation requires a separate approved workflow
