القائمة
Deploy phase playbook — build, push, apply with Azure CLI and kubectl.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف 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.