Menú
Deploy phase playbook — build, push, apply with Azure CLI and kubectl.
Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.
Basado en la clasificación ocupacional SOC
ACR integration for AKS Automatic. Teaches attaching an ACR, image reference conventions (digest pinning, no :latest), and pull-secret-free authentication via the managed identity.
Writing idiomatic, safe, and reviewable Bicep templates for Azure resources.
Non-blocking cluster status peek — run at the end of Phases 3, 4, 5 to check AKS provisioning progress without hanging.
Voice, tone, and interaction patterns for Kickstart agents.
Configure Infrastructure phase playbook — launch the dedicated Kickstart cluster-setup view, which collects and creates the Azure resources (subscription, resource group, AKS Automatic cluster, ACR) and hands the results back to the chat.
Design phase playbook — propose target architecture on AKS Automatic.
| name | kickstart-deploy |
| description | Deploy phase playbook — build, push, apply with Azure CLI and kubectl. |
| disable-model-invocation | true |
Deploy using Azure CLI and kubectl. Execute each step via run_in_terminal, confirm between steps with vscode_askQuestions. Never auto-deploy.
Build and push: az acr build --registry <acr> --image <image>:<tag> -f <dockerfilePath> <buildContext>
Use the build context and Dockerfile path from the structure map — never assume repo root (.). For monorepos, build each service from its own context. Tag with a version (e.g. v1.0.0), never :latest.
Get credentials: az aks get-credentials --resource-group <rg> --name <cluster> --overwrite-existing
kubelogin handles AAD auth automatically (verified in Pre-Deploy Check). Never use --admin.
Apply manifests: kubectl apply -f k8s/
Verify: kubectl get pods -n <namespace> and kubectl get services -n <namespace>
If pods not Ready, run kubectl describe pod <name> and kubectl logs <name> to diagnose.
Health-check the running app: don't declare success on pod readiness alone — actually hit the app and compare against the expected response:
kubectl get httproute / kubectl get services: curl -sS -o /dev/null -w "%{http_code}" http://<url>/ (expect 2xx/3xx).kubectl exec <pod> -n <namespace> -- curl -sS localhost:<port>/<health-path>.
If the response isn't what the app should return (wrong status, error body, or logs show a missing entry point), classify as a cluster failure and diagnose before reporting success.Classify failures:
Provide specific az or kubectl fix commands. Offer retry via vscode_askQuestions.
Only mention GitHub Actions if the user asks about CI/CD.