ai-superpower/.ai/skills/kubernetes-access/SKILL.md

name	description
kubernetes-access	Defines workflows for interacting with Kubernetes clusters, depending on whether a valid kubeconfig is present. Emphasizes read-only access and strict IaC adherence.

Kubernetes & Helm Access

🎯 Purpose

Establishes the branching logic for cluster interaction depending on kubeconfig availability, and enforces strict Infrastructure as Code (IaC) principles to prevent configuration drift.

🚨 CRITICAL: The AI NEVER gets direct credentials. Access is strictly governed by the local kubeconfig.

🚨 Prohibitions (Thou Shalt Not)

• NEVER mutate cluster state directly without explicit permission. Do not use kubectl apply, edit, patch, delete, or helm install/upgrade. Live cluster changes cause IaC drift.
• NEVER ask for credentials.
• NEVER guess the cluster state. Read it if you have access, or ask the user to read it if you don't.

Workflows (Access Check required!)

Before interacting with a cluster, determine if you have access by running a harmless check (e.g., kubectl config current-context or kubectl get nodes).

Scenario A: AI HAS Access (via local kubeconfig)

If the workspace has a valid kubeconfig, the AI CAN run read-only commands directly:

• kubectl get <resource>, kubectl describe, kubectl logs, kubectl top
• Port-forwarding: Establish port-forwards locally and use curl to analyze internal HTTP services.
• Rule: You are an observer. Find the issue via CLI, but fix the issue in the IaC source files (Helm charts, manifests), not via kubectl patch.

Scenario B: AI Does NOT Have Access

If no kubeconfig is provided or access is denied, delegate to the user:

1. Print the exact kubectl or helm command for the user.
2. Explain briefly what the command will do.
3. Wait for the user to run it and paste the output.

For detailed debugging workflows and port-forward mechanics, read_file -> .ai/skills/kubernetes-access/REFERENCE.md.