Menu
Use when creating or editing PilotSwarm .agent.md files, prompt-layer manifests, or builder templates that generate agents. Covers schemaVersion/version frontmatter, SemVer bump guidance, and session.prompt_layers expectations.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
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 | agent-versioning |
| description | Use when creating or editing PilotSwarm .agent.md files, prompt-layer manifests, or builder templates that generate agents. Covers schemaVersion/version frontmatter, SemVer bump guidance, and session.prompt_layers expectations. |
Use this skill whenever you create or update PilotSwarm agent definitions in agents/*.agent.md, embedded agents under packages/sdk/plugins/**/agents/, or builder templates that generate agent files.
Every authored .agent.md should include:
---
schemaVersion: 1
version: 1.0.0
name: example-agent
description: Example agent.
---
schemaVersion is the PilotSwarm agent schema version. Use 1 until the schema changes.version is a string. PilotSwarm-authored agents use SemVer. App authors may use any non-empty string, but SemVer is recommended.versionFor PilotSwarm-authored agents and templates, bump version whenever you change prompt behavior, tool expectations, workflow guidance, frontmatter metadata, or output/contract expectations.
Use SemVer intent:
If you only move a file without changing prompt behavior or metadata, a version bump is not required.
When a builder agent creates a new app agent, it should include schemaVersion: 1 and version: 1.0.0 by default.
When it edits an existing app .agent.md, it should update the version string according to the change. If the existing app uses non-SemVer labels, preserve the user's style unless they ask to migrate.
PilotSwarm prompt-layer manifests have three authored layers:
PilotSwarm base -> App base -> Agent
Runtime context is not an agent layer; runtime behavior is tracked through orchestration version and session/runtime metadata.
session.prompt_layers records the effective layer names, types, schema versions, and versions used by the worker that created or resumed the Copilot session. During rolling deploys, absence of the event means legacy/unreported, and old workers may report old loaded versions until restarted.