Official agent skill

Environment Deployment

by microsoft in microsoft/physical-ai-toolchain

Generate, transfer, and consume environment-specific Azure, AKS, OSMO, ACR, and Azure ML deployment bundles.

OfficialMITAuto-check passedDevOps & Cloud

Install Environment Deployment

skills CLI
$ npx skills add microsoft/physical-ai-toolchain --skill environment-deployment -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install microsoft/physical-ai-toolchain environment-deployment --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ 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-src

Use ~/.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/

Facts

Skill name
environment-deployment
GitHub stars
122
Token cost
~5.8k tokens
SKILL.md length
2,497 words
Files
1
Skills in repo
7
Repo updated
First seen
Licence
MIT

At a glance

Generate, transfer, and consume environment-specific Azure, AKS, OSMO, ACR, and Azure ML deployment bundles.

  • Works in 10 steps: Establish the target → Read Terraform desired state → Verify Azure → …
  • : discovering deployed environment details
  • SKILL.md covers Goal, Flow, Inputs and Safety Boundaries, plus 9 more sections
  • Calls az, terraform and kubectl

What it does

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.

When your agent uses it

  • : discovering deployed environment details
  • Creating OSMO image manifests
  • Platform values
  • Preparing a HiL host

Example prompts

  • “/environment-deployment”

Workflow steps

10 steps, taken from the step headings in SKILL.md.

  1. Establish the target
  2. Read Terraform desired state
  3. Verify Azure
  4. Verify Kubernetes
  5. Verify OSMO
  6. Generate OSMO platform values
  7. Generate Azure ML InstanceTypes
  8. Generate the immutable ACR image manifest
  9. Generate deployment metadata
  10. Validate

What it can do on your machine

Read from SKILL.md and the folder at commit 5d38197. It shows what the files ask for, not the result of running them.

  • Tool permissions

    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.

  • Runs code

    Shell commands in SKILL.md call:

    • az
    • terraform
    • kubectl
    • git

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    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.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

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.

Always · name and description, kept in context so the agent knows when to use it
~94
When it runs · the whole SKILL.md, loaded when a task matches
~5.8k

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.

Safety

Auto-check passed

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.

SKILL.md

The full file from microsoft/physical-ai-toolchain at commit 5d38197, republished under its MIT licence (© microsoft). 2,497 words, ~5,785 tokens.

Download SKILL.mdSave it as .claude/skills/environment-deployment/SKILL.md (or your agent's skills folder).
name
environment-deployment
description
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.

Environment Deployment

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.

Goal

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.

Flow

  1. Resolve the environment, desired-state sources, available read-only tools, and requested bundle consumers.
  2. Verify target identities and generate only the required allowlisted artifacts under the gitignored environment directory.
  3. Validate hashes, immutable references, file safety, and the absence of credentials before use.
  4. Preview the selected deployment or, for HiL, publish the exact host-bound catalog to Key Vault and hand off to the local consumer.

Inputs

  • Environment name and Terraform directory
  • Existing isolated Kubernetes context when live cluster verification is available
  • Optional isolated authenticated OSMO profile for read-only service verification
  • Requested deployment consumers and explicit version overrides
  • For HiL publication, the host identity, existing backend and pool, approved service URL, protected registry configuration, Key Vault name, and optional public VPN inputs

Safety Boundaries

Follow these rules for every environment bundle:

  • Do not modify Azure resources, Kubernetes resources, OSMO configuration, or the active OSMO profile during discovery.
  • Do not run terraform apply, kubectl apply, Helm upgrade/install, OSMO update/set/delete commands, or Azure create/update/delete commands while generating a bundle.
  • Do not upload artifacts or publish credentials during read-only discovery.
  • Do not write discovered values into tracked files, documentation, examples, tests, or source defaults.
  • Do not replace instructional RFC1918 addresses or example resource shapes solely because they differ from the deployed environment.
  • Do not include Terraform state, secret values, kubeconfig contents, OSMO profiles, tokens, registry credentials, VPN keys, certificates, or absolute local paths in a bundle.
  • Use an isolated kubeconfig and explicit context. Verify the AKS resource ID before reading cluster state.
  • Ask before changing an Azure CLI subscription or OSMO profile when the requested task is discovery only.
  • Use existing protected password or token files for non-interactive login. Never request secrets through chat.

Bundle Layout

Create only the artifacts needed by the deployment:

text
infrastructure/setup/generated/<environment>/
├── deployment.json
├── osmo-platforms.yaml
├── osmo-images.json
└── azureml-instance-types.yaml

deployment.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.

Prerequisites

Use every available discovery tool. Record unavailable tools and skipped checks in deployment.json.

ToolPurposeRequired
TerraformRead desired resources and node-pool configurationYes
Azure CLIVerify Azure identity and live resource metadataYes
jqSelect explicit non-secret fields and write JSONYes
kubectlVerify AKS nodes, labels, taints, GPU capacity, and OSMO endpointWhen AKS is reachable
osmoVerify the authenticated service and available poolsWhen an isolated profile is supplied
HelmRead the deployed OSMO image version and valuesWhen OSMO is deployed

For private resources, connect to the VPN before live Azure, AKS, Key Vault, or OSMO checks.

Generate a Bundle

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.

1. Establish the target

Collect or infer:

  • Environment name
  • Terraform directory, normally infrastructure/terraform
  • Isolated kubeconfig path, normally $HOME/.kube/physical-ai-toolchain/<aks-cluster>.yaml
  • Explicit Kubernetes context
  • Optional isolated OSMO profile directory
  • Optional OSMO image version when OSMO is not deployed yet

Create infrastructure/setup/generated/<environment>/. Do not create a tracked placeholder in this directory.

2. Read Terraform desired state

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 outputBundle use
resource_groupResource group name and location
key_vault_nameKey Vault bundle transfer
aks_clusterAKS name and resource ID
node_poolsGPU pool VM sizes, priority, labels, taints, and scaling settings
container_registryACR name and login server
storage_accountStorage account name
azureml_workspaceAzure ML workspace name
osmo_workload_identityOSMO 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.

3. Verify Azure

Use read-only Azure CLI calls:

  1. Read the active account with az account show.
  2. Confirm its subscription matches the subscription segment of the AKS resource ID.
  3. Read the resource group with az group show.
  4. Read AKS with az aks show and compare its normalized resource ID with Terraform.
  5. Read ACR with az acr show and compare its name and login server with Terraform.
  6. Read Key Vault metadata with az keyvault show; do not enumerate or read unrelated secret values.
  7. Read 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.

4. Verify Kubernetes

When kubectl is available and AKS is reachable:

  1. Use verify_existing_aks_kubeconfig before refreshing credentials.
  2. Use connect_aks from scripts/lib/common.sh only when the user requested credential setup.
  3. Otherwise require an existing isolated kubeconfig and use verify_kube_target.
  4. Read nodes with an explicit kubeconfig and context.
  5. For each Terraform GPU pool, compare:
    • agentpool label
    • node.kubernetes.io/instance-type label
    • Terraform node labels
    • Terraform taints
    • status.allocatable["nvidia.com/gpu"]
  6. Read 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.

5. Verify OSMO

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 version
  • osmo pool list --format-type json

When 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.

6. Generate OSMO platform values

Generate osmo-platforms.yaml from node_pools.

For each GPU pool that isn't parked:

  • Create one pod template with agentpool and node.kubernetes.io/instance-type selectors.
  • Add Terraform node labels that constrain scheduling.
  • Convert each Terraform taint into a matching Exists or Equal toleration.
  • Add the nvidia.com/gpu NoSchedule toleration when the pool uses it.
  • Set requests and limits to the literal OSMO Jinja value {{USER_GPU}}.
  • Create a platform under services.configs.pools.default.platforms.
  • Use a default GPU count no greater than verified per-node allocatable capacity. Use 1 when the pool is scaled to zero and capacity cannot be verified.
  • Keep 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.

7. Generate Azure ML InstanceTypes

Generate azureml-instance-types.yaml from the same pool data:

  • Always include defaultinstancetype for CPU workloads.
  • Create one GPU InstanceType per pool that isn't parked. Select the pool with 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.
  • Use gpuspot for the first spot pool and gpu for the first regular pool when those names are unambiguous; otherwise use gpu-<pool>.
  • Set the GPU limit to a value no greater than verified per-node capacity. Use 1 for scale-to-zero pools without live capacity.
  • Do not generate multi-GPU InstanceTypes without verified capacity or an explicit user requirement.

The deployment consumes this file through 02-deploy-azureml-extension.sh --instance-types-manifest.

8. Generate the immutable ACR image 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:

  • agent
  • backend-listener
  • backend-worker
  • client
  • delayed-job-monitor
  • init-container
  • logger
  • router
  • service
  • web-ui
  • worker

For 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:

json
{
  "schema_version": 1,
  "registry": "<acr-name>",
  "login_server": "<acr-login-server>",
  "image_version": "<version>",
  "images": {
    "<component>": {
      "repository": "osmo/<component>",
      "digest": "sha256:<64-lowercase-hex>"
    }
  }
}
9. Generate deployment metadata

Write deployment.json last. Use relative artifact filenames and SHA-256 digests. Include:

json
{
  "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.

Show full SKILL.md (1,009 more words)Show less
10. Validate

Before using or uploading the bundle:

  • Confirm every artifact is a regular non-symlink file.
  • Confirm deployment.json matches the active subscription, Terraform resource group, Key Vault, and AKS resource ID.
  • Confirm osmo_workflow_data_uri is the configured Azure workflow-data endpoint and osmo_workload_identity matches Terraform and Azure identity metadata.
  • Confirm artifact paths are relative filenames without ...
  • Recalculate and compare every artifact SHA-256.
  • Validate osmo-images.json against verify_acr_image_manifest when ACR is used.
  • Run kubectl apply --dry-run=client -f for the Azure ML InstanceTypes when kubectl is available.
  • Search the bundle for private keys, bearer tokens, password fields, Docker auth, kubeconfig client data, and absolute home-directory paths. Stop if any are found.
  • Confirm git check-ignore infrastructure/setup/generated/<environment>/deployment.json succeeds.

Use the Bundle

Pass generated artifacts explicitly; do not copy them back into tracked values/ or manifests/ directories.

DeploymentGenerated argument
Azure ML extension02-deploy-azureml-extension.sh --instance-types-manifest <bundle>/azureml-instance-types.yaml
OSMO control plane03-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.

Transfer a Generic Non-Secret Bundle

Upload the allowlisted bundle from the trusted deployment host:

bash
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:

bash
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:

bash
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.

Prepare and Connect an Ubuntu HiL Host

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.

Publish Host-Bound Inputs

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.

Connect the Ubuntu Consumer

After the Ubuntu host and any required VPN are ready, run the consumer boundary:

bash
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.

Success Criteria

  • Generated bundle files contain only the approved non-secret fields and remain under the gitignored environment directory.
  • Every available read-only target check passes or is recorded as unavailable without a false verification claim.
  • Deployment consumers receive explicit validated artifact paths instead of copied tracked values.
  • A HiL publication uses Key Vault, preserves exact catalog-pinned artifact versions, and publishes the catalog last.
  • No discovery action mutates Azure, Kubernetes, OSMO, Key Vault, or a client profile.

Stop Rules

  • Stop when Terraform, Azure, AKS, ACR, Key Vault, or OSMO identity does not match the selected environment.
  • Stop when a generated artifact contains a credential, private key, kubeconfig, profile, absolute home path, or unverified mutable reference.
  • Stop before deployment, publication, role assignment, network change, or credential issuance unless the caller requested that separate action and its owner prerequisites are satisfied.
  • Stop the Key Vault path on access, network, target, catalog, token, or integrity failure.

Handoff

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

Files

Just SKILL.md in .github/skills/environment-deployment of microsoft/physical-ai-toolchain.

Open the folder on GitHubat commit 5d38197

Compare with similar skills

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.

Environment Deployment compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Environment Deployment this skillmicrosoft/physical-ai-toolchain122—~5.8kAutomated safety check: PassMIT
Aks Deployment Skilltimothywarner/chatgptclass143—~916Automated safety check: PassCustom licence
Physical AI Infrastructure Setup And Resilient ScalingNVIDIA/skills3.5k—~2.8kAutomated safety check: NotesApache-2.0
Aspire MonitoringCommunityToolkit/Aspire629—~3.5kAutomated safety check: PassMIT
Kcli Cluster Deploymentkarmab/kcli653—~1.5kAutomated safety check: PassApache-2.0
Akka.NET Management and DiscoveryAaronontheweb/dotnet-skills1.2k1 repos~2.5kAutomated safety check: PassMIT

Similar skills

  • Aks Deployment Skill

    timothywarner/chatgptclass

    Deploy and operate workloads on Azure Kubernetes Service (AKS) the safe way.

    143 GitHub stars~916 tokensUpdated 18 days ago
    DevOps & CloudAuto-check passed
  • 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…

    3.5k GitHub stars~2.8k tokensUpdated today
    DevOps & CloudAuto-check: notes
  • Aspire Monitoring

    CommunityToolkit/Aspire

    ANALYSIS SKILL - Observe Aspire apps: logs, traces, metrics, resource state, telemetry export, browser telemetry, and the standalone dashboard.

    629 GitHub stars~3.5k tokensUpdated today
    DevOps & CloudAuto-check passed
  • Guides deployment and management of Kubernetes clusters with kcli.

    653 GitHub stars~1.5k tokensUpdated yesterday
    DevOps & CloudAuto-check passed
  • Akka.NET Management and Discovery

    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.

    1.2k GitHub starsUsed in 1 repo~2.5k tokens
    DevOps & CloudAuto-check passed
  • Azure Diagnostics

    microsoft/GitHub-Copilot-for-Azure

    Official

    Debug Azure production issues on Azure using AppLens, Azure Monitor, resource health, and safe triage.

    255 GitHub starsUsed in 1 repo~1.6k tokens
    DevOps & CloudAuto-check passed

More from microsoft/physical-ai-toolchain

  • Osmo Lerobot Training

    microsoft/physical-ai-toolchain

    Official

    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

    122 GitHub stars~3.8k tokensUpdated today
    Auto-check: notes
  • Azureml K3s Compute Target Setup

    microsoft/physical-ai-toolchain

    Official

    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.

    122 GitHub stars~5.7k tokensUpdated today
    Auto-check: notes
  • Fleet Deployment

    microsoft/physical-ai-toolchain

    Official

    Deploy trained robot policies to edge fleets via FluxCD GitOps, image automation, and deployment gating

    122 GitHub stars~518 tokensUpdated today
    Auto-check passed
  • Fleet Intelligence

    microsoft/physical-ai-toolchain

    Official

    Monitor robot fleet telemetry via Azure IoT Operations, drift detection, Grafana dashboards, and Fabric analytics

    122 GitHub stars~598 tokensUpdated today
    Auto-check passed
  • Infrastructure

    microsoft/physical-ai-toolchain

    Official

    Deploy and manage Azure infrastructure for the Physical AI Toolchain including Terraform IaC, Kubernetes setup, GPU configuration, and network topology

    122 GitHub stars~1.6k tokensUpdated today
    Auto-check passed
  • Synthetic Data

    microsoft/physical-ai-toolchain

    Official

    Generate synthetic training data using NVIDIA Cosmos world foundation models for SDG pipelines

    122 GitHub stars~469 tokensUpdated today
    Auto-check passed

Categories

Questions about Environment Deployment

What does Environment Deployment do?

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.

When should I use Environment Deployment?

Environment Deployment fits situations like: : discovering deployed environment details; creating OSMO image manifests; platform values; preparing a HiL host.

How do I install Environment Deployment in Claude Code?

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.

How do I install Environment Deployment in Codex?

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.

Can I use Environment Deployment in Cursor, Gemini CLI or GitHub Copilot?

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.

What does Environment Deployment need to run?

Going by SKILL.md and its folder, Environment Deployment needs the command-line tools its instructions call (az, terraform, kubectl and git).

Does Environment Deployment access the network?

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.

Is Environment Deployment safe to install?

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.

What licence does Environment Deployment use?

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.

How many tokens does Environment Deployment use?

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.

What are the alternatives to Environment Deployment?

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.

Who maintains Environment Deployment?

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.