Menü
Run and analyze PilotSwarm performance workflows, starting with SDK sub-agent spawn perf. Use when collecting fresh perf baselines, comparing runs, generating stable perf reports, or updating perf memory and next steps.
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Basierend auf der SOC-Berufsklassifikation
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-perf |
| description | Run and analyze PilotSwarm performance workflows, starting with SDK sub-agent spawn perf. Use when collecting fresh perf baselines, comparing runs, generating stable perf reports, or updating perf memory and next steps. |
Use this skill when the user wants performance numbers or follow-up analysis for this repository.
Keep the workflow deterministic. Fresh numbers should come from repo-owned runners, and conclusions should be written back into repo memory.
perf/memory/perf-agent-memory.mdscripts/perf/run-sdk-spawn-perf.mjsnpm run perf:spawnpackages/sdk/test/perf/spawn.perf.test.jspackages/sdk/vitest.perf.config.jsperf/reports/spawn/latest.mdperf/reports/spawn/latest.jsonperf/reports/spawn/history/index.jsonperf/memory/perf-agent-memory.md.npm run perf:spawn from repo root.npm run perf:spawn as the source of truth: it must generate latest.*, append history, and update perf/memory/perf-agent-memory.md automatically.perf/reports/spawn/latest.json and perf/reports/spawn/latest.md, not on terminal snippets alone.perf/memory/perf-agent-memory.md so the next run starts from the updated hypotheses and next steps.latest.* files as generated outputs.If you add another perf surface later, give it all of the following:
packages/*/test/perf/scripts/perf/perf/reports/<surface>/perf/memory/perf-agent-memory.md