القائمة
Use when creating or editing PilotSwarm app agents in agents/*.agent.md. Covers schemaVersion/version frontmatter, version bump guidance, and prompt layer version visibility.
التثبيت باستخدام 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-agent-versioning |
| description | Use when creating or editing PilotSwarm app agents in agents/*.agent.md. Covers schemaVersion/version frontmatter, version bump guidance, and prompt layer version visibility. |
Use this skill when scaffolding or editing app agent definitions for a PilotSwarm-based application.
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. SemVer is recommended because it is easy for operators and agents to compare, but app authors may use another non-empty label.When creating a new app agent, start with:
schemaVersion: 1
version: 1.0.0
When modifying an existing .agent.md, update the version string when the change affects prompt behavior, tool expectations, workflow guidance, frontmatter metadata, output shape, or child-contract expectations.
Use SemVer intent when the app uses SemVer:
If the existing app uses non-SemVer version labels, preserve that style unless the user asks to migrate.
PilotSwarm reports authored prompt layers as:
PilotSwarm base -> App base -> Agent
The Activity Monitor can display session.prompt_layers so operators can see the layer kind, name, type, schema version, and version used by the worker that created or resumed a session.