Aks Deployment Skill
timothywarner/chatgptclass
Deploy and operate workloads on Azure Kubernetes Service (AKS) the safe way.
Generate, transfer, and consume environment-specific Azure, AKS, OSMO, ACR, and Azure ML deployment bundles.
$ npx skills add microsoft/physical-ai-toolchain --skill environment-deployment -a claude-codeProject install by default; add -g for ~/.claude/skills/.
$ gh skill install microsoft/physical-ai-toolchain environment-deployment --agent claude-codeProject scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).
$ git clone --depth 1 https://github.com/microsoft/physical-ai-toolchain.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.github/skills/environment-deployment .claude/skills/environment-deployment && rm -rf skills-srcUse ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.
Claude Code skills documentation · loads skills from .claude/skills/
Install the "environment-deployment" agent skill from https://github.com/microsoft/physical-ai-toolchain/tree/main/.github/skills/environment-deployment into .claude/skills/environment-deployment/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "environment-deployment", then confirm the skill loads.Claude Code copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$skill-installer install https://github.com/microsoft/physical-ai-toolchain/tree/main/.github/skills/environment-deploymentType this inside Codex. $skill-installer <name> installs a curated skill from openai/skills. The installer writes to $CODEX_HOME/skills (default ~/.codex/skills). Restart Codex if the skill does not show up.
$ npx skills add microsoft/physical-ai-toolchain --skill environment-deployment -a codexProject install goes to .agents/skills/; add -g for ~/.codex/skills/.
$ gh skill install microsoft/physical-ai-toolchain environment-deployment --agent codexProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/microsoft/physical-ai-toolchain.git skills-src && mkdir -p .agents/skills && cp -r skills-src/.github/skills/environment-deployment .agents/skills/environment-deployment && rm -rf skills-srcUse ~/.agents/skills/ instead of .agents/skills for a personal install.
Codex skills documentation · loads skills from .agents/skills/
Install the "environment-deployment" agent skill from https://github.com/microsoft/physical-ai-toolchain/tree/main/.github/skills/environment-deployment into .agents/skills/environment-deployment/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "environment-deployment", then confirm the skill loads.Codex copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ npx skills add microsoft/physical-ai-toolchain --skill environment-deployment -a cursorProject install goes to .agents/skills/; add -g for ~/.cursor/skills/.
$ gh skill install microsoft/physical-ai-toolchain environment-deployment --agent cursorProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/microsoft/physical-ai-toolchain.git skills-src && mkdir -p .cursor/skills && cp -r skills-src/.github/skills/environment-deployment .cursor/skills/environment-deployment && rm -rf skills-srcUse ~/.cursor/skills/ instead of .cursor/skills for a personal install.
Cursor skills documentation · loads skills from .cursor/skills/, .agents/skills/, .claude/skills/, .codex/skills/
Install the "environment-deployment" agent skill from https://github.com/microsoft/physical-ai-toolchain/tree/main/.github/skills/environment-deployment into .cursor/skills/environment-deployment/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "environment-deployment", then confirm the skill loads.Cursor copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ gemini skills install https://github.com/microsoft/physical-ai-toolchain.git --path .github/skills/environment-deployment--scope user (default) or --scope workspace; --path is the subfolder of the repo that holds the skill; --consent skips the security confirmation prompt.
$ npx skills add microsoft/physical-ai-toolchain --skill environment-deployment -a gemini-cliProject install goes to .agents/skills/; add -g for ~/.gemini/skills/.
$ gh skill install microsoft/physical-ai-toolchain environment-deployment --agent gemini-cliProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/microsoft/physical-ai-toolchain.git skills-src && mkdir -p .gemini/skills && cp -r skills-src/.github/skills/environment-deployment .gemini/skills/environment-deployment && rm -rf skills-srcUse ~/.gemini/skills/ instead of .gemini/skills for a personal install, then run /skills reload.
Gemini CLI skills documentation · loads skills from .gemini/skills/, .agents/skills/
Install the "environment-deployment" agent skill from https://github.com/microsoft/physical-ai-toolchain/tree/main/.github/skills/environment-deployment into .gemini/skills/environment-deployment/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "environment-deployment", then confirm the skill loads.Gemini CLI copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ gh skill install microsoft/physical-ai-toolchain environment-deploymentInstalls for Copilot at project scope by default; add --scope user for a personal install. Preview a skill first with gh skill preview. Needs GitHub CLI 2.90.0 or later (public preview).
$ npx skills add microsoft/physical-ai-toolchain --skill environment-deployment -a github-copilotProject install goes to .agents/skills/; add -g for ~/.copilot/skills/.
$ git clone --depth 1 https://github.com/microsoft/physical-ai-toolchain.git skills-src && mkdir -p .github/skills && cp -r skills-src/.github/skills/environment-deployment .github/skills/environment-deployment && rm -rf skills-srcUse ~/.copilot/skills/ instead of .github/skills for a personal install. Commit .github/skills so cloud agent and code review can use it.
GitHub Copilot skills documentation · loads skills from .github/skills/, .claude/skills/, .agents/skills/
Install the "environment-deployment" agent skill from https://github.com/microsoft/physical-ai-toolchain/tree/main/.github/skills/environment-deployment into .github/skills/environment-deployment/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "environment-deployment", then confirm the skill loads.GitHub Copilot copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ npx skills add microsoft/physical-ai-toolchain --skill environment-deployment -a opencodeOpenCode documents no install command of its own. Project install goes to .agents/skills/; add -g for ~/.config/opencode/skills/.
$ gh skill install microsoft/physical-ai-toolchain environment-deployment --agent opencodeProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/microsoft/physical-ai-toolchain.git skills-src && mkdir -p .opencode/skills && cp -r skills-src/.github/skills/environment-deployment .opencode/skills/environment-deployment && rm -rf skills-srcUse ~/.config/opencode/skills/ instead of .opencode/skills for a personal install.
OpenCode skills documentation · loads skills from .opencode/skills/, .claude/skills/, .agents/skills/
Install the "environment-deployment" agent skill from https://github.com/microsoft/physical-ai-toolchain/tree/main/.github/skills/environment-deployment into .opencode/skills/environment-deployment/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "environment-deployment", then confirm the skill loads.OpenCode copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
environment-deploymentGenerate, transfer, and consume environment-specific Azure, AKS, OSMO, ACR, and Azure ML deployment bundles.
Environment Deployment is an agent skill from microsoft/physical-ai-toolchain, published by the product's own GitHub organization. Generate, transfer, and consume environment-specific Azure, AKS, OSMO, ACR, and Azure ML deployment bundles. Use when: discovering deployed environment details; creating OSMO image manifests or platform values; preparing a HiL host; uploading or downloading deployment files through Azure Key Vault; or deploying with generated environment configuration.
Its SKILL.md is about 5.8k tokens, which your agent loads only when the skill is triggered. It is a single SKILL.md file with no bundled scripts.
It sits in DevOps & Cloud, covering Deployment and Container orchestration. It works with Microsoft Azure, Azure Machine Learning, Azure Key Vault and Azure Kubernetes Service. The licence is MIT.
10 steps, taken from the step headings in SKILL.md.
Read from SKILL.md and the folder at commit 5d38197. It shows what the files ask for, not the result of running them.
Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.
From allowed-tools in the SKILL.md frontmatter.
Shell commands in SKILL.md call:
azterraformkubectlgitFrom the folder's file list and the shell code blocks in SKILL.md.
No URLs in SKILL.md. Its commands use az, kubectl and git, which can reach the network depending on how they are called.
From URLs in SKILL.md, links to its own repository left out.
Names no API keys, tokens, secrets or passwords.
From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.
Environment Deployment loads about 5.8k tokens when it runs. Until then it costs about 94 tokens; SKILL.md has 2,497 words of instructions outside code blocks.
Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.
The automated check found no risky patterns in SKILL.md.
Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.
The full file from microsoft/physical-ai-toolchain at commit 5d38197, republished under its MIT licence (© microsoft). 2,497 words, ~5,785 tokens.
.claude/skills/environment-deployment/SKILL.md (or your agent's skills folder).Generate non-secret deployment details from Terraform desired state and read-only Azure, Kubernetes, and OSMO discovery. Store generated artifacts under the gitignored infrastructure/setup/generated/<environment>/ directory.
Produce a validated non-secret environment bundle or a host-bound HiL handoff whose target, ownership, transfer, and next operation are explicit. Keep discovery read-only and keep generated environment values outside tracked source.
Follow these rules for every environment bundle:
terraform apply, kubectl apply, Helm upgrade/install, OSMO update/set/delete commands, or Azure create/update/delete commands while generating a bundle.Create only the artifacts needed by the deployment:
infrastructure/setup/generated/<environment>/
├── deployment.json
├── osmo-platforms.yaml
├── osmo-images.json
└── azureml-instance-types.yamldeployment.json is required. The other files are optional when the corresponding component is not deployed.
Use lowercase letters, numbers, and hyphens for <environment>. Keep artifact filenames stable because the Key Vault transfer scripts use this allowlist.
Use every available discovery tool. Record unavailable tools and skipped checks in deployment.json.
| Tool | Purpose | Required |
|---|---|---|
| Terraform | Read desired resources and node-pool configuration | Yes |
| Azure CLI | Verify Azure identity and live resource metadata | Yes |
| jq | Select explicit non-secret fields and write JSON | Yes |
| kubectl | Verify AKS nodes, labels, taints, GPU capacity, and OSMO endpoint | When AKS is reachable |
| osmo | Verify the authenticated service and available pools | When an isolated profile is supplied |
| Helm | Read the deployed OSMO image version and values | When OSMO is deployed |
For private resources, connect to the VPN before live Azure, AKS, Key Vault, or OSMO checks.
This is an agent-led discovery workflow, not a static checked-in generator. The agent executes the available read-only commands below, renders files from the current Terraform and live resource data, validates the result, and reports every skipped probe. Do not reuse artifacts from another environment.
Collect or infer:
infrastructure/terraform$HOME/.kube/physical-ai-toolchain/<aks-cluster>.yamlCreate infrastructure/setup/generated/<environment>/. Do not create a tracked placeholder in this directory.
Run terraform output -json from the Terraform directory. Select only explicit output fields; never copy raw output or state into the bundle.
Read these values when present:
| Terraform output | Bundle use |
|---|---|
resource_group | Resource group name and location |
key_vault_name | Key Vault bundle transfer |
aks_cluster | AKS name and resource ID |
node_pools | GPU pool VM sizes, priority, labels, taints, and scaling settings |
container_registry | ACR name and login server |
storage_account | Storage account name |
azureml_workspace | Azure ML workspace name |
osmo_workload_identity | OSMO workload identity ID and Entra metadata |
Fail when the resource group, Key Vault, or requested AKS/ACR values are missing. Do not infer names from naming conventions when Terraform exposes them.
A pool is parked when node_pools reports should_enable_auto_scaling = false and node_count = 0. Nothing can schedule on a parked pool, so skip it in Kubernetes verification and generate no OSMO pod template, OSMO platform, or Azure ML InstanceType for it.
Use read-only Azure CLI calls:
az account show.az group show.az aks show and compare its normalized resource ID with Terraform.az acr show and compare its name and login server with Terraform.az keyvault show; do not enumerate or read unrelated secret values.osmo_workload_identity with az identity show --ids, and confirm its ID, client ID, and tenant ID match Terraform.Stop on any identity or resource mismatch. Do not switch subscriptions silently.
When kubectl is available and AKS is reachable:
verify_existing_aks_kubeconfig before refreshing credentials.connect_aks from scripts/lib/common.sh only when the user requested credential setup.verify_kube_target.agentpool labelnode.kubernetes.io/instance-type labelstatus.allocatable["nvidia.com/gpu"]azureml/azureml-ingress-nginx-internal-lb and form http://<RFC1918-address> from its assigned ingress IP.Scale-to-zero pools (autoscaling on with min_count = 0) may have no live nodes. Generate their configuration from Terraform and record live capacity as unavailable instead of omitting the pool. Parked pools are the exception and are omitted.
Do not run osmo login during discovery. If the caller supplies an isolated authenticated profile, set XDG_CONFIG_HOME to it and run read-only checks:
osmo versionosmo pool list --format-type jsonWhen Helm is available, read the deployed OSMO release with the same isolated kubeconfig and context. Prefer global.osmoImageTag from deployed values for the image version. Fall back to OSMO_IMAGE_VERSION from infrastructure/setup/defaults.conf only for a new deployment.
Record whether OSMO and Helm verification succeeded. Do not copy profile data into the bundle.
Generate osmo-platforms.yaml from node_pools.
For each GPU pool that isn't parked:
agentpool and node.kubernetes.io/instance-type selectors.Exists or Equal toleration.nvidia.com/gpu NoSchedule toleration when the pool uses it.{{USER_GPU}}.services.configs.pools.default.platforms.1 when the pool is scaled to zero and capacity cannot be verified.USER_CPU, USER_MEMORY, USER_STORAGE, and USER_SHM_SIZE as instructional defaults unless the user supplies workload requirements.Use unique lowercase identifiers derived from the pool key. Preserve both braces in every OSMO Jinja expression.
Generate azureml-instance-types.yaml from the same pool data:
defaultinstancetype for CPU workloads.agentpool: <pool key> plus its constraining Terraform labels, such as the Spot label. Don't select on accelerator: AKS sets it on running GPU nodes, and the autoscaler can't predict it for a current GPU size at zero.gpuspot for the first spot pool and gpu for the first regular pool when those names are unambiguous; otherwise use gpu-<pool>.1 for scale-to-zero pools without live capacity.The deployment consumes this file through 02-deploy-azureml-extension.sh --instance-types-manifest.
Generate osmo-images.json only when OSMO images are mirrored to ACR. Mirroring writes to the registry, so it isn't part of discovery. With the user's confirmation, infrastructure/setup/import-osmo-to-acr.sh imports and locks the pinned images and charts, writes this file, and records it with the registry and OSMO versions in an existing deployment.json. It stops before importing when a value already in deployment.json differs.
To describe images that are already mirrored, use this component allowlist:
agentbackend-listenerbackend-workerclientdelayed-job-monitorinit-containerloggerrouterserviceweb-uiworkerFor each component, read the digest for osmo/<component>:<image-version> with az acr manifest show-metadata. Confirm the repository tag has writes and deletes disabled with az acr repository show. Fail if a component, digest, or immutability setting is missing.
Write this shape:
{
"schema_version": 1,
"registry": "<acr-name>",
"login_server": "<acr-login-server>",
"image_version": "<version>",
"images": {
"<component>": {
"repository": "osmo/<component>",
"digest": "sha256:<64-lowercase-hex>"
}
}
}Write deployment.json last. Use relative artifact filenames and SHA-256 digests. Include:
{
"schema_version": 1,
"environment": "<environment>",
"generated_at": "<UTC-RFC3339>",
"subscription_id": "<subscription-id>",
"tenant_id": "<tenant-id>",
"resource_group": "<resource-group>",
"location": "<azure-region>",
"key_vault_name": "<key-vault>",
"aks_cluster": "<aks-cluster>",
"aks_resource_id": "<aks-resource-id>",
"acr_name": "<acr-name-or-empty>",
"acr_login_server": "<login-server-or-empty>",
"azureml_workspace": "<workspace-or-empty>",
"storage_account": "<storage-account-or-empty>",
"osmo_service_url": "<private-osmo-url>",
"osmo_chart_version": "<chart-version-or-empty>",
"osmo_image_version": "<image-version-or-empty>",
"osmo_workflow_data_uri": "azure://<storage-account>/<container>/workflows/data",
"osmo_workload_identity": {
"id": "<user-assigned-managed-identity-resource-id>",
"principal_id": "<managed-identity-principal-id>",
"client_id": "<managed-identity-client-id>",
"tenant_id": "<managed-identity-tenant-id>"
},
"artifacts": {
"osmo_platforms": {"file": "osmo-platforms.yaml", "sha256": "<digest>"},
"osmo_images": {"file": "osmo-images.json", "sha256": "<digest>"},
"azureml_instance_types": {"file": "azureml-instance-types.yaml", "sha256": "<digest>"}
},
"verification": {
"terraform": true,
"azure_cli": true,
"kubectl": true,
"helm": true,
"osmo": true
}
}Set osmo_workflow_data_uri from the configured OSMO workflow_data.credential.endpoint, not a naming convention. It must match azure://<account>/<container>/workflows/data. Omit optional artifact entries when their files do not exist. Set unavailable verification tools to false; do not claim checks that did not run.
Before using or uploading the bundle:
deployment.json matches the active subscription, Terraform resource group, Key Vault, and AKS resource ID.osmo_workflow_data_uri is the configured Azure workflow-data endpoint and osmo_workload_identity matches Terraform and Azure identity metadata....osmo-images.json against verify_acr_image_manifest when ACR is used.kubectl apply --dry-run=client -f for the Azure ML InstanceTypes when kubectl is available.git check-ignore infrastructure/setup/generated/<environment>/deployment.json succeeds.Pass generated artifacts explicitly; do not copy them back into tracked values/ or manifests/ directories.
| Deployment | Generated argument |
|---|---|
| Azure ML extension | 02-deploy-azureml-extension.sh --instance-types-manifest <bundle>/azureml-instance-types.yaml |
| OSMO control plane | 03-deploy-osmo.sh --platform-values <bundle>/osmo-platforms.yaml --use-acr --image-manifest <bundle>/osmo-images.json |
Read the image version, service URL, AKS resource ID, and resource names from deployment.json. Run each deployment script with --config-preview first. Deployment scripts may change Azure or Kubernetes resources; obtain user confirmation before continuing from discovery into deployment.
Upload the allowlisted bundle from the trusted deployment host:
infrastructure/setup/upload-environment-bundle.sh --environment <environment> --config-preview
infrastructure/setup/upload-environment-bundle.sh --environment <environment>The uploader requires Key Vault secret write permission. It never changes RBAC.
Each UTF-8 artifact must be no larger than 24,000 bytes. Omit an optional file and its deployment.json artifact entry together. Existing Key Vault versions may remain, but consumers follow the current deployment.json allowlist.
Do not run concurrent uploads for the same environment. The uploader publishes artifacts first and deployment.json last so consumers either receive a coherent bundle or fail its digest checks.
For a generic, non-HiL consumer, authenticate to Azure, connect to the private network or VPN, and download the bundle:
infrastructure/setup/download-environment-bundle.sh --environment <environment> --resource-group <resource-group> --config-preview
infrastructure/setup/download-environment-bundle.sh --environment <environment> --resource-group <resource-group>The downloader requires the Key Vault Secrets User role and private endpoint connectivity when the vault is private.
Configure local clients from the protected bundle:
infrastructure/setup/connect-environment.sh --environment <environment> --config-preview
infrastructure/setup/connect-environment.sh --environment <environment>Use --osmo-method dev --osmo-username <user> only for an explicitly approved development deployment. Use protected files with --password-file or --token-file for service authentication.
download-environment-bundle.sh and connect-environment.sh remain generic non-HiL utilities. They do not retrieve or configure host-bound HiL credentials.
Complete this journey when an existing OSMO backend and pool are ready: the environment owner publishes the generic non-secret bundle separately from the host-bound protected inputs, then the Ubuntu consumer connects only its owned local K3s target with the catalog-bound artifacts.
The environment owner runs infrastructure/setup/04-prepare-osmo-hil-node.sh after verifying the existing OSMO backend and pool. Supply the generated bundle, approved service URL, existing backend and pool, protected OSMO profile, pull-only registry configuration, and token expiry. The script publishes the generic bundle and the exact host-bound catalog separately, writing the catalog last.
Key Vault is the only scripted protected-artifact transfer. Before publication, the environment owner creates the exact secret resources, except the catalog that the publisher writes, and grants the Ubuntu identity data-plane access to each named inbound secret only.
infrastructure/setup/prepare-osmo-hil-exchange.sh creates the secrets and the pull-only registry configuration, and grants the roles when given --assignee-object-id; rerun it after the first publication to grant the catalog role.
Use Key Vault Secrets User for inbound secrets and Key Vault Secrets Officer only for the host-specific CSR secret. Verify that the Ubuntu identity has no direct or inherited vault-wide data-plane role.
Key Vault networking stays a manual environment-owner action. The publisher does not assign roles, modify Key Vault networking, or make a private vault reachable. Complete any bounded network-access window and restore private-only access before the consumer continues.
The publisher reuses the exact catalog-pinned OSMO token and token-metadata secret versions when they are valid and unexpired. --renew-token forces a new issuance. An absent catalog or valid expired token metadata issues a new token. Stop on a malformed or inaccessible catalog, or a token-metadata binding or digest mismatch. The publisher does not delete token versions.
Manual SCP is outside this repository HiL flow. An operator may use it only as an out-of-band procedure that does not invoke repository HiL publisher, VPN, or consumer scripts and does not use retired transfer arguments.
After the Ubuntu host and any required VPN are ready, run the consumer boundary:
data-pipeline/setup/hil/02-connect-osmo-backend.sh \
--environment <environment> \
--host-name <host> \
--tenant-id <tenant-id> \
--subscription <subscription-id> \
--vault-name <vault>The consumer retrieves the catalog and declared artifacts from Key Vault. It validates catalog structure, artifact digests, token metadata, token digest, backend binding, and expiry before any Kubernetes mutation. A Key Vault access, network, target, catalog, or integrity failure stops the run.
The consumer validates the exact catalog-bound inputs and changes only the owned local K3s target. It does not administer Azure resources, AKS, Key Vault networking or RBAC, or remote OSMO desired state. Do not use download-environment-bundle.sh or connect-environment.sh as the Ubuntu HiL path.
Return the generated bundle path, validation results, unavailable checks, parked pools left out of the bundle, and the exact next preview command. Name any live Azure ML InstanceType or OSMO pool that still targets a parked pool so the operator can remove it; applying the regenerated InstanceTypes doesn't delete it. For HiL preparation, identify the trusted Key Vault publisher command, the local consumer command, and any environment-owner RBAC or network checkpoint that remains.
© microsoft, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file
Just SKILL.md in .github/skills/environment-deployment of microsoft/physical-ai-toolchain.
Open the folder on GitHubat commit 5d38197
Environment Deployment next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.
| Skill | Stars | Used in | Tokens | Auto-check | Licence | Repo updated |
|---|---|---|---|---|---|---|
| Environment Deployment this skillmicrosoft/physical-ai-toolchain | 122 | — | ~5.8k | Automated safety check: Pass | MIT | |
| Aks Deployment Skilltimothywarner/chatgptclass | 143 | — | ~916 | Automated safety check: Pass | Custom licence | |
| Physical AI Infrastructure Setup And Resilient ScalingNVIDIA/skills | 3.5k | — | ~2.8k | Automated safety check: Notes | Apache-2.0 | |
| Aspire MonitoringCommunityToolkit/Aspire | 629 | — | ~3.5k | Automated safety check: Pass | MIT | |
| Kcli Cluster Deploymentkarmab/kcli | 653 | — | ~1.5k | Automated safety check: Pass | Apache-2.0 | |
| Akka.NET Management and DiscoveryAaronontheweb/dotnet-skills | 1.2k | 1 repos | ~2.5k | Automated safety check: Pass | MIT |
timothywarner/chatgptclass
Deploy and operate workloads on Azure Kubernetes Service (AKS) the safe way.
A skill your agent uses when the user wants to set up, scale, validate, or harden NVIDIA physical AI infrastructure for synthetic data generation workflows across local MicroK8s or Azure AKS…
CommunityToolkit/Aspire
ANALYSIS SKILL - Observe Aspire apps: logs, traces, metrics, resource state, telemetry export, browser telemetry, and the standalone dashboard.
karmab/kcli
Guides deployment and management of Kubernetes clusters with kcli.
Aaronontheweb/dotnet-skills
Sets up Akka.Management and Cluster.Bootstrap so Akka.NET clusters form through service discovery on Kubernetes, Azure or config instead of static seed nodes.
microsoft/GitHub-Copilot-for-Azure
Debug Azure production issues on Azure using AppLens, Azure Monitor, resource health, and safe triage.
microsoft/physical-ai-toolchain
Submit, monitor, analyze, and evaluate LeRobot imitation learning training jobs on OSMO with Azure ML MLflow integration and inference evaluation - Brought to you by microsoft/physical-ai-toolchain
microsoft/physical-ai-toolchain
Set up a K3s cluster on an NVIDIA GPU host, connect it to Azure Arc, and configure Azure ML to use it as a Kubernetes compute target.
microsoft/physical-ai-toolchain
Deploy trained robot policies to edge fleets via FluxCD GitOps, image automation, and deployment gating
microsoft/physical-ai-toolchain
Monitor robot fleet telemetry via Azure IoT Operations, drift detection, Grafana dashboards, and Fabric analytics
microsoft/physical-ai-toolchain
Deploy and manage Azure infrastructure for the Physical AI Toolchain including Terraform IaC, Kubernetes setup, GPU configuration, and network topology
microsoft/physical-ai-toolchain
Generate synthetic training data using NVIDIA Cosmos world foundation models for SDG pipelines
Works with
Categories
Generate, transfer, and consume environment-specific Azure, AKS, OSMO, ACR, and Azure ML deployment bundles. Environment Deployment is an agent skill from microsoft/physical-ai-toolchain, published by the product's own GitHub organization. Generate, transfer, and consume environment-specific Azure, AKS, OSMO, ACR, and Azure ML deployment bundles.
Environment Deployment fits situations like: : discovering deployed environment details; creating OSMO image manifests; platform values; preparing a HiL host.
Run `npx skills add microsoft/physical-ai-toolchain --skill environment-deployment -a claude-code`. Or copy the skill folder (.github/skills/environment-deployment in microsoft/physical-ai-toolchain) into .claude/skills/environment-deployment in your project. Claude Code loads it when a task matches its description.
Run `npx skills add microsoft/physical-ai-toolchain --skill environment-deployment -a codex`. Or copy the skill folder (.github/skills/environment-deployment in microsoft/physical-ai-toolchain) into .agents/skills/environment-deployment in your project. Codex loads it when a task matches its description.
Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add microsoft/physical-ai-toolchain --skill environment-deployment -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/environment-deployment, .gemini/skills/environment-deployment, .github/skills/environment-deployment and .opencode/skills/environment-deployment in your project.
Going by SKILL.md and its folder, Environment Deployment needs the command-line tools its instructions call (az, terraform, kubectl and git).
SKILL.md contains no URLs. Its commands use git, which can reach the network depending on how they are called. This is read from the text; nothing was executed.
Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.
Environment Deployment is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.
About 5.8k tokens (SKILL.md is roughly 23k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.
Skills that share tags, products or a category with Environment Deployment: Aks Deployment Skill (timothywarner/chatgptclass, 143 stars), Physical AI Infrastructure Setup And Resilient Scaling (NVIDIA/skills, 3.5k stars), Aspire Monitoring (CommunityToolkit/Aspire, 629 stars) and Kcli Cluster Deployment (karmab/kcli, 653 stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.
microsoft (a GitHub organization, an official publisher) maintains it in microsoft/physical-ai-toolchain, which has 122 GitHub stars. The repository holds 7 skills in this directory. The repository was last updated on October 6, 2026.
Source: microsoft/physical-ai-toolchain on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.