aspire-orchestration
WORKFLOW SKILL — Manage Aspire lifecycle in VS Code or the CLI. WHEN: "start or stop my Aspire app", "aspireapphoststart", "aspireapphoststop", "notEditorOwned", "ambiguousSession", "aspire start", "aspire stop", "aspire wait", resource restart, file-lock errors (MSB3491 or CS2012), port conflicts, git worktrees, "--isolated", "aspire update --self", "aspire update --migrate", "aspire describe --include-hidden", "aspire stop --force", "aspire terminal", integration discovery, default watch, or hot reload. INVOKES: VS Code lifecycle tools first when exposed; Aspire CLI for readiness, inspection, resource operations, isolated worktree starts, and allowed fallbacks. DO NOT USE FOR: deploy/publish/destroy (aspire-deployment), logs/traces/metrics (aspire-monitoring), or AppHost code and resource wiring (aspireify). FOR SINGLE OPERATIONS: Load the matching editor tool first, then obey the exact-target, worktree-isolation, and stop-result rules below.
- Installs
- 1.1K
- Last 24h
- +28
- Trending rank
- #4586
- Security
- Not audited
Install
Works with every agent the skills CLI supports.
npx skills add https://github.com/microsoft/aspire-skills --skill aspire-orchestration- 01
Install
Run the command in your project. The CLI asks which agents to install for.
- 02
Describe the task
Ask your agent for something this skill covers. It loads aspire-orchestration automatically when relevant.
- 03
Review the result
The agent follows the SKILL.md steps, scripts and references bundled with the skill.
SKILL.md
The instructions your agent reads when the skill is triggered.
Aspire Orchestration
MANDATORY COMPLIANCE — This skill prevents agent self-harm in Aspire projects. Violating these rules causes file locks, orphaned processes, and user frustration (#15801).
Prerequisites
| Requirement | Install |
|---|---|
| .NET 10.0 SDK | https://dotnet.microsoft.com/download |
| Aspire CLI (curl/PowerShell) | curl -sSL https://aspire.dev/install.sh | bash |
| Aspire CLI (npm) | npm install -g @microsoft/aspire-cli |
| Aspire CLI (NativeAOT global tool, .NET 10) | dotnet tool install -g Aspire.Cli |
Use the installation method owned by the user's environment. npm, Nix, Homebrew, WinGet, mise, and the install scripts are supported alongside the NativeAOT .NET global tool.
Detection
Activate when ANY signal is present:
| Signal | How to Detect | Confidence |
|---|---|---|
| C# AppHost | .csproj containing Aspire.AppHost.Sdk | ✅ Definitive |
| File-based C# AppHost | apphost.cs or .cs file with #:sdk Aspire.AppHost.Sdk | ✅ Definitive |
| TypeScript AppHost | Current apphost.mts or legacy apphost.ts file in project | ✅ Definitive |
| Aspire config | aspire.config.json in project root | High |
| Aspire settings | .aspire/ directory present | High |
| Generated TS modules | .aspire/modules/ directory present | High |
| Service defaults | Aspire.ServiceDefaults in project references | Medium |
See detection.md for detailed fingerprinting.
VS Code AppHost Lifecycle
When the agent host exposes aspire_apphost_start or aspire_apphost_stop, use the
matching tool before running aspire start or aspire stop in a terminal, except when
starting from a git worktree requires --isolated and the tool cannot request it. If the
tool is listed as deferred, load its contract with the host's tool-discovery mechanism
first; do not treat an unloaded deferred tool as unavailable.
Pass the exact selected appHostPath discovered by Aspire to editor lifecycle tools. In a
multi-root workspace, that tool contract may require a selector such as
repo-a~1/MyApp.AppHost/MyApp.AppHost.csproj.
The CLI --apphost flag does not understand that selector namespace. Before any CLI
start/stop fallback, resolve the selected AppHost to its actual filesystem project path
and pass that path to --apphost; never copy a multi-root selector verbatim. That CLI
project path may be workspace-relative (MyApp.AppHost/MyApp.AppHost.csproj) or
absolute (/workspaces/repo-a/MyApp.AppHost/MyApp.AppHost.csproj or
C:\workspaces\repo-a\MyApp.AppHost\MyApp.AppHost.csproj); use the current platform's
native path syntax. If several AppHosts are discovered and the user's target is unclear,
ask which one to use instead of guessing, invoking the tool for every AppHost, or
issuing an unscoped CLI command.
If the selected appHostPath is already a normal workspace-relative project path such
as MyApp.AppHost/MyApp.AppHost.csproj, reuse it unchanged for CLI fallbacks; do not
convert it to an absolute path just for the CLI.
An unclear target is a hard stop. Ask one clarifying question and wait for the user to name an AppHost. Do not call a lifecycle tool or terminal command until the target is resolved, and do not offer commands that bypass this gate. Stop multiple AppHosts only when the user explicitly requests all of them.
For starts, call aspire_apphost_start with mode run and the exact selected
appHostPath unless the user explicitly asks to attach a debugger. In a git worktree, the
editor tool does not currently request Aspire's isolated state. Resolve the selected
AppHost to its filesystem path and use
aspire start --non-interactive --isolated --apphost <filesystem-path> instead.
run mode has no debugger attached, but it still has an editor-owned Aspire session that
aspire_apphost_stop can stop. After a stop call, follow this result matrix exactly:
| Tool result | Next action | CLI stop allowed? |
|---|---|---|
stopped or notRunning | Report the result; take no further stop action | No |
alreadyStopping, controller editor | Report that the editor stop is already in progress; take no further stop action | No |
alreadyStarting, controller editor | Retry aspire_apphost_stop once; if it repeats, report that startup is still in progress and take no further stop action | No |
notEditorOwned, controller external | If the user requested that exact AppHost be stopped, resolve it to its filesystem path and run aspire stop --non-interactive --apphost <filesystem-path> | Yes |
failed, controller unknown | Retry aspire_apphost_stop once; if the same result repeats, use the same exact-target CLI command above | Only after the retry |
ambiguousSession | Stop nothing and have the user disambiguate in the editor | Never |
| Any other refusal or failure | Resolve or report that result; do not change mechanisms | No |
The rows are mutually exclusive. Act only on the current result; do not offer a command from another row as a speculative future workaround. Re-evaluate only after a new tool result is returned.
ambiguousSession is a terminal safety refusal. Do not run or offer a CLI fallback,
and do not ask whether the user wants one. User confirmation cannot make an ambiguous
editor session safe to terminate from the CLI.
Use direct Aspire CLI lifecycle commands only when the matching editor tool is unavailable, for isolated worktree starts, or for a stop result explicitly marked as allowed above. When a CLI fallback is allowed, keep the target exact by resolving the selected AppHost to its filesystem path first.
Safety Guardrails
| Situation | ✅ ALWAYS Do | ❌ NEVER Do |
|---|---|---|
| Start an Aspire app | aspire_apphost_start with mode run and the exact selected appHostPath when available; in a git worktree, use aspire start --non-interactive --isolated --apphost <filesystem-path> even when aspire_apphost_start is available | dotnet run on AppHost |
| Wait for resource ready | aspire wait <resource> | curl / HTTP polling loops |
| Code changed in a resource | Prefer resource commands, runtime watch/HMR, dashboard actions, or IDE-managed debugging | dotnet build against locked files |
| Task complete | aspire_apphost_stop with the exact selected appHostPath when available; follow its result matrix | Use an unapproved CLI fallback |
| Check running AppHosts | aspire ps | Manual process inspection |
| Check resource status | aspire describe | aspire ps --resources (removed in 13.5) |
| Remove persistent resources | Confirm data loss and exact AppHost before aspire stop --force --apphost <filesystem-path> | Combining --force with --all, or using it for an ordinary stop |
| Working in git worktree | aspire start --non-interactive --isolated --apphost <filesystem-path> | aspire_apphost_start when it cannot request isolation |
| Running from AI agent | Load available lifecycle tools first; resolve CLI --apphost fallbacks to <filesystem-path>; add --non-interactive | Assuming interactive terminal |
| Editing unfamiliar API | aspire docs search <topic> then aspire docs api search <query> for API reference | Guessing API shape |
| C# AppHost API inspection | Use dotnet-inspect skill (if available) for local symbols | Guessing overloads or builder chains |
| Adding custom dashboard/resource commands | aspire docs search "custom resource commands" first | Inventing WithCommand patterns without docs |
| Installing Aspire support | Use aspire add or aspire init | dotnet workload install aspire |
See safety-guardrails.md for detailed rules and recovery patterns.
Default Workflow
- Confirm workspace is Aspire — identify the AppHost
- If the workspace is a git worktree, resolve the selected AppHost to a filesystem project path and use
aspire start --non-interactive --isolated --apphost <filesystem-path>even whenaspire_apphost_startis available, because the editor tool cannot request isolation. Otherwise, start withaspire_apphost_startin moderunusing the exact selectedappHostPathwhen available; if that tool is unavailable, resolve the selected AppHost to a filesystem project path and useaspire start --non-interactive --apphost <filesystem-path> aspire wait <resource>before interacting with any resourceaspire describeto inspect state, then work- If AppHost code changed, restart through the same lifecycle routing; if only one resource changed, prefer the resource's commands/watch/HMR/debug workflow
- Stop with
aspire_apphost_stopusing the exact selectedappHostPathwhen available; useaspire stop --non-interactive --apphost <filesystem-path>only for the documented fallback outcomes
Quick Reference
| Task | Command |
|---|---|
| Start app (agents) | Git worktree: aspire start --non-interactive --isolated --apphost <filesystem-path> even if aspire_apphost_start is available, because the tool cannot request isolation. Otherwise: aspire_apphost_start (mode run, exact selected appHostPath); CLI fallback when the tool is unavailable: aspire start --non-interactive --apphost <filesystem-path> |
| Start app (human) | aspire run (foreground, dashboard) |
| Stop app | aspire_apphost_stop (exact selected appHostPath); result-matrix fallback: aspire stop --non-interactive --apphost <filesystem-path> |
| Wait for resource | aspire wait <resource> |
| List running AppHosts | aspire ps |
| Check resource status | aspire describe |
| Show hidden resources (proxies, helpers, migrations) | aspire describe --include-hidden |
| Resource operation | aspire resource <resource-name> <command> such as stop, start, or rebuild when exposed |
| Discover resource commands | aspire resource <resource-name> --help |
| Attach to an experimental resource terminal | Enable features.terminalCommandsEnabled, then use aspire terminal ps / aspire terminal attach |
| Create new project | aspire new aspire-starter |
| Add Aspire to existing | aspire init (then hand off to aspireify skill for wiring) |
| Add integration | aspire add <package> |
| Discover integrations | aspire integration list --format Json / aspire integration search <query> --format Json |
| Upgrade the CLI itself | aspire update --self (managed installs may print the npm/.NET/Nix update command) |
| Update project package refs | aspire update --yes --non-interactive after approval |
| Migrate legacy TypeScript entry point | Explain that package references, config, tsconfig, imports, and the entry point all change; after approval for the package update and migration, run aspire update --migrate --yes --non-interactive |
| Restore generated files | aspire restore |
| Environment maintenance | aspire cache clear, aspire certs trust, aspire certs clean |
| Diagnose environment | aspire doctor |
| Machine-readable output | --format Json (supported: ps, describe, start) |
| Look up API reference | aspire docs api search <query> --language csharp|typescript |
| Browse API entries | aspire docs api list <scope> |
| Get API detail | aspire docs api get <id> |
Error Handling
| Symptom | Cause | Action |
|---|---|---|
File lock errors during build (MSB3491, CS2012) | Aspire is running and holds locks on bin/, obj/, and assemblies. | Stop the AppHost through the lifecycle routing above, then rebuild or restart it. Do NOT conclude the project has a permanent build failure. |
| "Port already in use" | Previous instance running | Stop, then restart through the lifecycle routing above |
| Resource not found | App not started or name wrong | Use aspire ps to find the AppHost, then aspire describe to check resources |
| Build errors in resource | Code error, not Aspire issue | Fix code, then use resource commands/watch/HMR/debug workflow or restart through the lifecycle routing if AppHost code changed |
| Environment issues | Missing SDK or tools | aspire doctor to diagnose |
JSON parse failure from aspire start | Mixed human/JSON output (#15843) | Strip non-JSON lines before parsing |
aspire ps hangs | AppHost on breakpoint (#15576) | Use timeout, check AppHost process |
aspire agent init fails | Non-interactive terminal (#16264) | Run from standard terminal |
| Docker daemon unavailable | Container-backed resources fail to start | Start Docker Desktop, then restart through the lifecycle routing above |
| Multiple AppHosts detected | Wrong AppHost targeted | Use --apphost <filesystem-path> to specify explicitly |
🔒 File-Lock Recovery (MSB3491 / CS2012) — Always Stop the AppHost First
When a build fails with error MSB3491: Could not write to output file ... or
error CS2012: Cannot open ... for writing, the project itself is healthy —
Aspire is running and holding file locks on the resource's output assemblies.
The recovery is always the same:
Resolve the exact AppHost and call aspire_apphost_stop first when available. If a CLI
fallback is permitted, resolve the selected AppHost to its filesystem path before using
the commands below; ambiguousSession and all other no-fallback results end the recovery
attempt.
# ✅ CLI stop only after the result matrix permits fallback
aspire stop --non-interactive --apphost <filesystem-path> # release the locks
# ... then either rebuild / restart one resource if the resource exposes commands ...
aspire resource <name> rebuild # example: C# project resource with rebuild command
# ... or restart the whole AppHost through aspire_apphost_start. If unavailable:
aspire start --non-interactive --apphost <filesystem-path>
# In a git worktree:
aspire start --non-interactive --isolated --apphost <filesystem-path>
| ❌ NEVER do | ✅ ALWAYS do |
|---|---|
| Tell the user the project has a permanent build failure | Recognize the lock as Aspire holding outputs and stop the AppHost through lifecycle routing |
dotnet build again with locks held | Stop the AppHost first, then dotnet build (or prefer resource commands/watch/HMR/debug workflow) |
Delete bin/ / obj/ to "fix" the lock | Stop the AppHost; deletion may succeed but the next build relocks |
pkill dotnet or kill <PID> to free locks | Use the editor stop tool or exact-target CLI fallback for clean shutdown |
| Tell the user to "reboot" or "restart your machine" | Stop the AppHost through lifecycle routing |
The same rule applies to any "file in use", "cannot access the file", or "another process is using" error during a build of an Aspire-managed resource.
Handoff Rules
| Scenario | Route To |
|---|---|
AppHost wiring after aspire init (scan repo, add resources, ServiceDefaults/OTel) | → aspireify skill (aspireify/SKILL.md) or project-local .agents/skills/aspireify/SKILL.md |
Browser logs (Aspire.Hosting.Browsers / WithBrowserLogs()) and dashboard authoring | → aspireify skill (code edits) and aspire-monitoring (discovery) |
Custom resource commands, arguments, interactions, or terminals (WithCommand, CommandOptions.Arguments, IInteractionService, WithTerminal) | → aspireify skill |
Lifecycle hooks (SubscribeBeforeStart, SubscribeAfterResourcesCreated, BeforeStart pipeline phase) | → aspireify skill |
Endpoint authoring (WithEndpoint updates, ExcludeReferenceEndpoint flag) | → aspireify skill |
Deploy, publish, pipeline steps, aspire destroy | → aspire-deployment skill |
Logs, traces, metrics, dashboard, aspire dashboard run | → aspire-monitoring skill |
| Deployed app diagnostics | → azure-diagnostics skill (azure-skills) |
Runtime Settings And Environment
| Variable | Default | Purpose |
|---|---|---|
ASPIRE_ENABLE_CONTAINER_TUNNEL | true | Container tunnel provides uniform host connectivity across Docker Desktop, Docker Engine, and Podman. Set to false to opt out. |
ASPIRE_ENVIRONMENT | unset | Selects the environment-specific config profile — controls which appsettings.{environment}.json is loaded and which environment is reported in dashboard telemetry. |
ASPIRE_DCP_USE_DEVELOPER_CERTIFICATE | true | The Aspire trusted developer certificate is used by DCP on Windows. Set to false to opt out. |
features.defaultWatchEnabled | false unless configured | Enables Aspire default watch for supported C# and TypeScript AppHosts. Do not treat this as per-resource rebuild, restart, or hot reload for resource source changes. |
TypeScript AppHost Note
Detection covers current apphost.mts and legacy apphost.ts, but all TS AppHost
authoring is delegated to aspireify. The CLI-driven legacy migration is project
maintenance owned by this orchestration skill, not authoring. Explain that it also updates
Aspire packages, config, tsconfig, and imports; offer
aspire update --migrate --yes --non-interactive only after approval for the full change,
then hand back to aspireify only if source authoring remains.
Current rules to apply when handing off:
| Rule | Why |
|---|---|
Prefer unified withEnvironment(name, value) over deprecated per-kind helpers (withEnvironmentEndpoint, withEnvironmentParameter, withEnvironmentConnectionString, withEnvironmentExpression, withEnvironmentFromOutput, withEnvironmentFromKeyVaultSecret) | Per-kind helpers are deprecated — single API now handles all value types |
Never edit .aspire/modules/ directly | Generated; use aspire add <package> to regenerate and aspire restore to recover missing files |
Use aspire docs api search <query> --language typescript for API lookup | TS surface differs from C# |
Skill Routing — In-Plugin Sibling Skills
After aspire init drops a skeleton AppHost + aspire.config.json, route AppHost wiring
(scan repo → propose resource graph → edit AppHost → wire Aspire.ServiceDefaults / OTel →
validate via aspire start) to the in-plugin aspireify skill: aspireify/SKILL.md.
For first-run flows that only need the skeleton drop, see the in-plugin aspire-init skill:
aspire-init/SKILL.md. This orchestration skill stays focused
on lifecycle (start/stop/wait/restart) and never edits AppHost code itself.
Project-Local Skill Precedence
If .agents/skills/aspire/SKILL.md exists (from aspire agent init), defer to it for:
C# AppHost editing, TS AppHost editing, Playwright handoff, investigation workflows.
Safety guardrails from this plugin ALWAYS apply.
If .agents/skills/aspireify/SKILL.md exists project-locally (installed by aspire init in
current Aspire), warn the user that a project-local aspireify skill is present and defer to it
for AppHost wiring instead of the in-plugin sibling. Same precedence rule as the project-local
aspire skill above: project-local wins, plugin guardrails still apply.
References
- safety-guardrails.md — Detailed rules and recovery patterns
- detection.md — Project fingerprinting
- app-commands.md — App lifecycle and bootstrap commands
- resource-management.md — Resource wait, restart, and operations
- agent-workflows.md — Common agent investigation, integration, TypeScript, and handoff workflows
FAQ
What does the aspire-orchestration skill do?
WORKFLOW SKILL — Manage Aspire lifecycle in VS Code or the CLI. WHEN: "start or stop my Aspire app", "aspireapphoststart", "aspireapphoststop", "notEditorOwned", "ambiguousSession", "aspire start", "aspire stop", "aspire wait", resource restart, file-lock errors (MSB3491 or CS2012), port conflicts, git worktrees, "--isolated", "aspire update --self", "aspire update --migrate", "aspire describe --include-hidden", "aspire stop --force", "aspire terminal", integration discovery, default watch, or hot reload. INVOKES: VS Code lifecycle tools first when exposed; Aspire CLI for readiness, inspection, resource operations, isolated worktree starts, and allowed fallbacks. DO NOT USE FOR: deploy/publish/destroy (aspire-deployment), logs/traces/metrics (aspire-monitoring), or AppHost code and resource wiring (aspireify). FOR SINGLE OPERATIONS: Load the matching editor tool first, then obey the exact-target, worktree-isolation, and stop-result rules below.
How do I install aspire-orchestration?
Run npx skills add https://github.com/microsoft/aspire-skills --skill aspire-orchestration in your project. The skills CLI detects the agents you use and copies the skill into the right folder. For Claude Code you can also place the skill folder at ~/.claude/skills/aspire-orchestration/ (personal) or .claude/skills/aspire-orchestration/ (project).
Which AI agents can use aspire-orchestration?
Any agent that supports the open Agent Skills format (a folder with a SKILL.md file), including Claude Code, Codex, Cursor, GitHub Copilot, Gemini CLI, Windsurf, Cline, OpenCode and more.
Is aspire-orchestration safe to install?
No partner security audit is available yet. Skills can run commands and scripts, so read the SKILL.md and any bundled files before installing.
Who maintains aspire-orchestration?
It is published by microsoft in microsoft/aspire-skills, and it is an official skill from the maker of the technology it covers. It has 1,120 recorded installs.
More from microsoft/aspire-skills
aspire
microsoft/aspire-skills
WORKFLOW SKILL - Aspire router. Detects AppHosts, enforces guardrails, and selects the right sub-skill. USE FOR: Aspire AppHost, Aspire CLI, distributed app, cloud-native .NET, aspire start/stop/resource/deploy/destroy/publish/init/new/add/wait/describe/ps/logs/otel, aspire agent init, WithBrowserLogs, WithTerminal, Interaction Service, apphost.mts, TS package managers, Yarn Classic, custom resource commands, .aspire/modules recovery, ProjectResource to DotnetProjectResource migration, or Playwright URL discovery. DO NOT USE FOR: non-Aspire projects or ordinary build/test tasks. INVOKES: aspire-init, aspireify, aspire-project-v2-migration, aspire-orchestration, aspire-deployment, aspire-monitoring. FOR SINGLE OPERATIONS: Route directly to the matching sub-skill.
aspire-monitoring
microsoft/aspire-skills
ANALYSIS SKILL - Observe Aspire apps: logs, traces, metrics, resource state, telemetry export, browser telemetry, and the standalone dashboard. Routes between local Aspire CLI, AKS workload diagnostics, and deployed Azure resource health. USE FOR: aspire logs, aspire otel logs, aspire otel traces, aspire otel spans, aspire describe, aspire ps, aspire export, aspire dashboard run, describe --include-hidden, browser logs in dashboard, terminal view, DevTunnel URLs, WithBrowserLogs, App Insights query, AKS pod logs, container app logs. DO NOT USE FOR: start/stop/wait (use aspire-orchestration), deploy/publish/destroy (use aspire-deployment), AppHost code edits like WithBrowserLogs() (use aspireify), Azure provisioning (use azure-prepare). INVOKES: aspire CLI, azure-diagnostics (deployed Azure), kubectl + Container Insights. FOR SINGLE OPERATIONS: Run the aspire CLI command directly for quick log or describe lookups.
aspireify
microsoft/aspire-skills
WORKFLOW SKILL - Wire Aspire AppHosts or repair TypeScript AppHost toolchains. Scans the repo, proposes a resource graph, edits C, file-based C, or TypeScript AppHosts, wires ServiceDefaults + OTel, validates with aspire start, then stops. USE FOR: wire/scaffold AppHost, add Postgres/Redis/Rabbit/Mongo, connect frontend to API, after aspire init, AddNextJsApp, AddViteApp, WithBrowserLogs, WithTerminal, Interaction Service, command arguments, apphost.cs, apphost.mts, unified withEnvironment, .aspire/modules refusal, config/secrets, TS dependency restore, pnpm/yarn/bun, or Yarn Classic. DO NOT USE FOR: skeleton drop (aspire-init), lifecycle-only start/stop/wait/restart or aspire update --migrate (aspire-orchestration), publish/deploy/destroy (aspire-deployment), logs/traces (aspire-monitoring). INVOKES: aspire CLI, AppHost source edits, ServiceDefaults wiring. FOR SINGLE OPERATIONS: Run aspire add PACKAGE directly for a one-off integration.
aspire-init
microsoft/aspire-skills
WORKFLOW SKILL - First-run flow for adding Aspire to a repo. Picks aspire new (greenfield) or aspire init (existing repo), drops the AppHost skeleton, then hands off to aspireify for resource wiring. USE FOR: aspire init, aspire new, aspire-starter, aspire-ts-starter, aspire-py-starter, add Aspire to existing repo, scaffold Aspire app, bootstrap Aspire, no AppHost detected, install aspireify, apphost.mts, generated .aspire/modules. DO NOT USE FOR: AppHost wiring on an existing AppHost (use aspireify), start/stop/wait (use aspire-orchestration), deploy/publish (use aspire-deployment), logs/traces (use aspire-monitoring), repo that already has an AppHost. INVOKES: aspire CLI (init, new, doctor), aspireify (handoff after skeleton drop). FOR SINGLE OPERATIONS: Run aspire init or aspire new TEMPLATE directly.
aspire-deployment
microsoft/aspire-skills
WORKFLOW SKILL — Deploy Aspire apps from AppHost models to Docker Compose, Kubernetes, Azure, AWS, or preview Radius. WHEN: "deploy Aspire app", "publish Aspire artifacts", "deploy to Azure Container Apps", "generate Kubernetes artifacts", "deploy to Radius", "tear down Aspire deployment". INVOKES: aspire CLI, Aspire docs, target cloud/container CLIs. FOR SINGLE OPERATIONS: use generic Azure, Kubernetes, Docker, AWS, or Radius tools only when no Aspire AppHost exists.
aspire-project-v2-migration
microsoft/aspire-skills
Open the skill to read its SKILL.md instructions.
Popular devops & cloud skills
microsoft-foundry
microsoft/azure-skills
Build, deploy, evaluate, optimize, fine-tune, and manage Microsoft Foundry agents, models, and resources end to end. USE FOR: foundry, azd ai agent, azd provision/deploy, hosted agent scaffold/develop/run/deploy/troubleshoot, prompt agent create, managed harness agent create, GitHub Copilot harness agent, create agent, update agent, add tool to agent, invoke agent, agent insights, evaluate agent, batch eval, continuous eval, continuous monitoring, agent CI/CD, optimize prompt, improve prompt, optimize agent instructions, Agent Optimizer scaffold, dataset curation from traces, deploy model, model fine-tuning (SFT/DPO/RFT), Foundry project, RBAC, role assignment, permissions, quota, capacity, region, deployment failure, AI Services, create Foundry resource, knowledge index, customize deployment, onboard, availability, training-data, grader, distillation, large file upload. DO NOT USE FOR: Azure Functions, App Service, general Azure deploy (use azure-deploy), general Azure prep (use azure
azure-diagnostics
microsoft/azure-skills
Debug Azure production issues on Azure using AppLens, Azure Monitor, resource health, and safe triage. WHEN: debug production issues, troubleshoot app service, app service high CPU, app service deployment failure, troubleshoot container apps, container app 503 or target port mismatch, troubleshoot functions, function telemetry missing or stopped after a config/connection-string change, troubleshoot AKS, VM RDP, Linux SSH, VM black screen, can't connect to VM, reset VM password, NSG or firewall blocking, kubectl cannot connect, kube-system/CoreDNS failures, pod pending, crashloop, node not ready, upgrade failures, analyze logs, KQL, insights, image pull failures, cold start issues, health probe failures, resource health, root cause of errors, troubleshoot event hubs, troubleshoot service bus, messaging SDK error, AMQP connection failure, message lock lost, lock renewal during long-running processing, service bus dead letter.
azure-prepare
microsoft/azure-skills
Prepare azd-based Azure projects for deployment: generates azure.yaml, infrastructure (Bicep/Terraform), and Dockerfiles for the Azure Developer CLI (azd) workflow. USE ONLY when the user explicitly wants to use azd as the deployment tool, or the project already has an azure.yaml file. DO NOT USE FOR: non-azd deployments, Python App Service code-only deploys (use python-appservice-deploy), or cross-cloud migration (use azure-cloud-migrate). WHEN: prepare app for azd, create azure.yaml, set up azd infrastructure, modernize app for Azure with azd, deploy with azd, function app, timer trigger, service bus trigger, event-driven function, managed identity, generate Bicep, generate Terraform, create and deploy to Azure.
azure-ai
microsoft/azure-skills
Use for Azure AI: Search, Speech, OpenAI, Document Intelligence. Helps with search, vector/hybrid search, speech-to-text, text-to-speech, transcription, OCR. WHEN: AI Search, query search, vector search, hybrid search, semantic search, speech-to-text, text-to-speech, transcribe, OCR, convert text to speech.
azure-deploy
microsoft/azure-skills
Execute Azure deployments for ALREADY-PREPARED applications that have existing .azure/deployment-plan.md and infrastructure files. DO NOT use this skill when the user asks to CREATE a new application — use azure-prepare instead. This skill runs azd up, azd deploy, terraform apply, and az deployment commands with built-in error recovery. Requires .azure/deployment-plan.md from azure-prepare and validated status from azure-validate. WHEN: "run azd up", "run azd deploy", "execute deployment", "push to production", "push to cloud", "go live", "ship it", "bicep deploy", "terraform apply", "publish to Azure", "launch on Azure". DO NOT USE WHEN: "create and deploy", "build and deploy", "create a new app", "set up infrastructure", "create and deploy to Azure using Terraform" — use azure-prepare for these.
azure-validate
microsoft/azure-skills
Pre-deployment validation for Azure readiness. Run deep checks on configuration, infrastructure (Bicep or Terraform), RBAC role assignments, managed identity permissions, and prerequisites before deploying. WHEN: validate my app, check deployment readiness, run preflight checks, verify configuration, check if ready to deploy, validate azure.yaml, validate Bicep, test before deploying, troubleshoot deployment errors, validate Azure Functions, validate function app, validate serverless deployment, verify RBAC roles, check role assignments, review managed identity permissions, what-if analysis, validate Container Apps deployment.