メニュー
Use when setting up cross-cluster AKS access with Workload Identity, RBAC, and kubectl configuration for PilotSwarm workers.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
The order of operations for changing a live agent safely — diagnose, patch, publish, converge, verify, roll back. Use whenever you are about to modify an agent package that something is already running on.
Deploy PilotSwarm to AKS using the repo's canonical scripts and checks. Use when refreshing secrets, building/pushing the worker image, rolling out to AKS, or verifying provider/model changes in the live cluster.
Reset remote PilotSwarm state for AKS safely. Use when wiping the PilotSwarm database/blob state, clearing stale orchestration history, or recovering from namespace drift and replay/nondeterminism issues.
Use when bringing up a fresh, isolated PilotSwarm environment (`mysandbox`, `myenv2`, etc.) via the npm Bicep/GitOps orchestrator at `deploy/scripts/deploy.mjs`. Covers `new-env` scaffolding, EDGE_MODE × TLS_SOURCE selection, the `all` aggregate, per-service redeploys with `--steps`, force-redeploy semantics, verification, and teardown. Strictly separate from the legacy bash path operated by `scripts/deploy-aks.sh`.
Use after deploying a PilotSwarm stamp with VPN_GATEWAY_ENABLED=true when an operator needs the Azure VPN client profile (azurevpnconfig.xml). Wraps deploy/scripts/auth/Get-VpnClientProfile.ps1 — downloads the gateway-issued profile zip via 'az network vnet-gateway vpn-client generate' and extracts it under the gitignored deploy/envs/local/<env>/vpn-client/ folder. The XML is the same for every user (no per-user credentials), and end users still authenticate with their own Entra ID at connect time.
How to compute model latency and estimated $ cost from PilotSwarm observability data. Read this before reporting that a model is "slow" or "expensive" — most apparent slowness is orchestration overhead, not model inference, and most cost numbers are guesses unless they reference a real published price card.
| name | pilotswarm-aks-identity |
| description | Use when setting up cross-cluster AKS access with Workload Identity, RBAC, and kubectl configuration for PilotSwarm workers. |
How to wire Workload Identity, RBAC, and kubectl when PilotSwarm workers in a control AKS cluster need to manage a second AKS cluster.
Prefer Azure Workload Identity on the control cluster instead of relying on node identity.
Required pieces:
azure.workload.identity/client-id: <client-id>azure.workload.identity/use: "true"system:serviceaccount:<namespace>:<service-account>api://AzureADTokenExchangeMinimum Azure RBAC usually needed:
Azure Kubernetes Service Cluster User Role on the workload AKS clusterStorage Blob Data Contributor on the storage accountWhen documenting or implementing this flow, include validation from inside a control-plane pod:
AZURE_CLIENT_ID, AZURE_TENANT_ID, AZURE_FEDERATED_TOKEN_FILE, and AZURE_AUTHORITY_HOSTaz login \
--service-principal \
-u "$AZURE_CLIENT_ID" \
-t "$AZURE_TENANT_ID" \
--federated-token "$(cat "$AZURE_FEDERATED_TOKEN_FILE")" \
--allow-no-subscriptions
az aks get-credentials \
--subscription "$AZURE_SUBSCRIPTION_ID" \
--resource-group "$AZURE_RESOURCE_GROUP" \
--name "$WORKLOAD_CLUSTER_NAME" \
--file /tmp/workload-kubeconfig \
--overwrite-existing
kubectl auth can-i create podskubectl Guidancekubectl --context <cluster-context>kubectl create secret generic ... --from-env-file=... for worker env injection