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 (NativeAOT global tool, .NET 10) |
dotnet tool install -g Aspire.Cli |
Either install method works. The dotnet tool install path produces a NativeAOT binary
(instant startup, no JIT warmup) and is the recommended option when .NET 10 is already present.
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 |
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.
Safety Guardrails
| Situation |
✅ ALWAYS Do |
❌ NEVER Do |
| Start an Aspire app |
aspire start |
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 stop |
Leave processes running |
| Check resource status |
aspire describe (resources) / aspire ps (running AppHosts) |
Manual process inspection |
| Working in git worktree |
aspire start --isolated |
aspire start without isolation |
| Running from AI agent |
Add --non-interactive to all commands |
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
aspire start (or aspire start --isolated in worktrees)aspire wait <resource> before interacting with any resourceaspire describe to inspect state, then work- If AppHost code changed, rerun
aspire start; if only one resource changed, prefer the resource's commands/watch/HMR/debug workflow
aspire stop when cleanup is explicitly requested or needed to release locks/ports
Quick Reference
| Task |
Command |
| Start app (agents) |
aspire start (background, preferred) |
| Start app (human) |
aspire run (foreground, dashboard) |
| Stop app |
aspire stop |
| Wait for resource |
aspire wait <resource> |
| Check status |
aspire ps (running AppHosts) or aspire describe (resources) |
| Show hidden resources (proxies, helpers, migrations) |
aspire describe --include-hidden / aspire resource <name> --include-hidden (13.5 removed aspire ps --include-hidden; ps now lists AppHosts only) |
| Resource operation |
aspire resource <resource-name> <command> such as stop, start, or rebuild when exposed |
| 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 |
| Update project package refs |
aspire update (modifies project files — get user approval) |
| 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. |
Run aspire stop first, then rebuild or aspire start. Do NOT conclude the project has a permanent build failure. |
| "Port already in use" |
Previous instance running |
aspire stop, then aspire start |
| Resource not found |
App not started or name wrong |
aspire ps (is the AppHost running?) then aspire describe (is the resource name right?) |
| Build errors in resource |
Code error, not Aspire issue |
Fix code, then use resource commands/watch/HMR/debug workflow or rerun aspire start 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 wait rejects name |
Use displayName not name (#15842) |
Use displayName from aspire describe --format Json |
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 aspire start |
| Multiple AppHosts detected |
Wrong AppHost targeted |
Use --apphost <path> to specify explicitly |
🔒 File-Lock Recovery (MSB3491 / CS2012) — Always aspire stop 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:
# ✅ Correct recovery sequence
aspire stop # 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 ...
aspire start # if AppHost code changed or Aspire was already stopped
| ❌ NEVER do |
✅ ALWAYS do |
| Tell the user the project has a permanent build failure |
Recognize the lock as Aspire holding outputs and run aspire stop |
dotnet build again with locks held |
aspire stop first, then dotnet build (or prefer resource commands/watch/HMR/debug workflow) |
Delete bin/ / obj/ to "fix" the lock |
aspire stop — deletion may succeed but the next build relocks |
pkill dotnet or kill <PID> to free locks |
aspire stop — clean shutdown via the CLI, no orphans |
| Tell the user to "reboot" or "restart your machine" |
aspire stop — single command, instant fix |
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 (WithCommand, ExecuteCommandResult, HttpCommandResultMode) |
→ 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 TS AppHosts (apphost.ts), but all TS AppHost authoring is delegated to aspireify.
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
1---2name: aspire-orchestration3description: **WORKFLOW SKILL** — Manage Aspire AppHost lifecycle and recover from file locks, port conflicts, and orphaned processes. WHEN: "start my Aspire app", "aspire start", "aspire stop", "aspire wait", "restart the API service", "file lock error", "MSB3491", "CS2012", "port already in use", "upgrade Aspire CLI", "aspire update --self", "proxies missing in aspire ps", "--include-hidden", "aspire integration list", "aspire integration search", "default watch", "hot reload". INVOKES: aspire CLI (start, stop, wait, ps, resource, integration, add, init, doctor, update, restore). FOR SINGLE OPERATIONS: Run the aspire CLI command directly.4license: MIT5---67# Aspire Orchestration89> **MANDATORY COMPLIANCE** — This skill prevents agent self-harm in Aspire projects.10> Violating these rules causes file locks, orphaned processes, and user frustration ([#15801](https://github.com/microsoft/aspire/issues/15801)).1112## Prerequisites1314| Requirement | Install |15|-------------|---------|16| .NET 10.0 SDK | https://dotnet.microsoft.com/download |17| Aspire CLI (curl/PowerShell) | `curl -sSL https://aspire.dev/install.sh \| bash` |18| Aspire CLI (NativeAOT global tool, .NET 10) | `dotnet tool install -g Aspire.Cli` |1920Either install method works. The `dotnet tool install` path produces a NativeAOT binary21(instant startup, no JIT warmup) and is the recommended option when .NET 10 is already present.2223## Detection2425Activate when ANY signal is present:2627| Signal | How to Detect | Confidence |28|--------|---------------|------------|29| C# AppHost | `.csproj` containing `Aspire.AppHost.Sdk` | ✅ Definitive |30| File-based C# AppHost | `apphost.cs` or `.cs` file with `#:sdk Aspire.AppHost.Sdk` | ✅ Definitive |31| TypeScript AppHost | `apphost.ts` file in project | ✅ Definitive |32| Aspire config | `aspire.config.json` in project root | High |33| Aspire settings | `.aspire/` directory present | High |34| Generated TS modules | `.aspire/modules/` directory present | High |35| Service defaults | `Aspire.ServiceDefaults` in project references | Medium |3637See [detection.md](references/detection.md) for detailed fingerprinting.3839## Safety Guardrails4041| Situation | ✅ ALWAYS Do | ❌ NEVER Do |42|-----------|-------------|------------|43| Start an Aspire app | `aspire start` | `dotnet run` on AppHost |44| Wait for resource ready | `aspire wait <resource>` | `curl` / HTTP polling loops |45| Code changed in a resource | Prefer resource commands, runtime watch/HMR, dashboard actions, or IDE-managed debugging | `dotnet build` against locked files |46| Task complete | `aspire stop` | Leave processes running |47| Check resource status | `aspire describe` (resources) / `aspire ps` (running AppHosts) | Manual process inspection |48| Working in git worktree | `aspire start --isolated` | `aspire start` without isolation |49| Running from AI agent | Add `--non-interactive` to all commands | Assuming interactive terminal |50| Editing unfamiliar API | `aspire docs search <topic>` then `aspire docs api search <query>` for API reference | Guessing API shape |51| C# AppHost API inspection | Use `dotnet-inspect` skill (if available) for local symbols | Guessing overloads or builder chains |52| Adding custom dashboard/resource commands | `aspire docs search "custom resource commands"` first | Inventing `WithCommand` patterns without docs |53| Installing Aspire support | Use `aspire add` or `aspire init` | ~~`dotnet workload install aspire`~~ (obsolete) |5455See [safety-guardrails.md](references/safety-guardrails.md) for detailed rules and recovery patterns.5657## Default Workflow58591. Confirm workspace is Aspire — identify the AppHost602. `aspire start` (or `aspire start --isolated` in worktrees)613. `aspire wait <resource>` before interacting with any resource624. `aspire describe` to inspect state, then work635. If AppHost code changed, rerun `aspire start`; if only one resource changed, prefer the resource's commands/watch/HMR/debug workflow646. `aspire stop` when cleanup is explicitly requested or needed to release locks/ports6566## Quick Reference6768| Task | Command |69|------|---------|70| Start app (agents) | `aspire start` (background, preferred) |71| Start app (human) | `aspire run` (foreground, dashboard) |72| Stop app | `aspire stop` |73| Wait for resource | `aspire wait <resource>` |74| Check status | `aspire ps` (running AppHosts) or `aspire describe` (resources) |75| Show hidden resources (proxies, helpers, migrations) | `aspire describe --include-hidden` / `aspire resource <name> --include-hidden` (13.5 removed `aspire ps --include-hidden`; `ps` now lists AppHosts only) |76| Resource operation | `aspire resource <resource-name> <command>` such as `stop`, `start`, or `rebuild` when exposed |77| Create new project | `aspire new aspire-starter` |78| Add Aspire to existing | `aspire init` (then hand off to `aspireify` skill for wiring) |79| Add integration | `aspire add <package>` |80| Discover integrations | `aspire integration list --format Json` / `aspire integration search <query> --format Json` |81| Upgrade the CLI itself | `aspire update --self` |82| Update project package refs | `aspire update` (modifies project files — get user approval) |83| Restore generated files | `aspire restore` |84| Environment maintenance | `aspire cache clear`, `aspire certs trust`, `aspire certs clean` |85| Diagnose environment | `aspire doctor` |86| Machine-readable output | `--format Json` (supported: `ps`, `describe`, `start`) |87| Look up API reference | `aspire docs api search <query> --language csharp\|typescript` |88| Browse API entries | `aspire docs api list <scope>` |89| Get API detail | `aspire docs api get <id>` |9091## Error Handling9293| Symptom | Cause | Action |94|---------|-------|--------|95| **File lock errors during build (`MSB3491`, `CS2012`)** | **Aspire is running and holds locks on `bin/`, `obj/`, and assemblies.** | **Run `aspire stop` first**, then rebuild or `aspire start`. Do NOT conclude the project has a permanent build failure. |96| "Port already in use" | Previous instance running | `aspire stop`, then `aspire start` |97| Resource not found | App not started or name wrong | `aspire ps` (is the AppHost running?) then `aspire describe` (is the resource name right?) |98| Build errors in resource | Code error, not Aspire issue | Fix code, then use resource commands/watch/HMR/debug workflow or rerun `aspire start` if AppHost code changed |99| Environment issues | Missing SDK or tools | `aspire doctor` to diagnose |100| JSON parse failure from `aspire start` | Mixed human/JSON output ([#15843](https://github.com/microsoft/aspire/issues/15843)) | Strip non-JSON lines before parsing |101| `aspire wait` rejects name | Use `displayName` not `name` ([#15842](https://github.com/microsoft/aspire/issues/15842)) | Use `displayName` from `aspire describe --format Json` |102| `aspire ps` hangs | AppHost on breakpoint ([#15576](https://github.com/microsoft/aspire/issues/15576)) | Use timeout, check AppHost process |103| `aspire agent init` fails | Non-interactive terminal ([#16264](https://github.com/microsoft/aspire/issues/16264)) | Run from standard terminal |104| Docker daemon unavailable | Container-backed resources fail to start | Start Docker Desktop, then `aspire start` |105| Multiple AppHosts detected | Wrong AppHost targeted | Use `--apphost <path>` to specify explicitly |106107### 🔒 File-Lock Recovery (MSB3491 / CS2012) — Always `aspire stop` First108109When a build fails with `error MSB3491: Could not write to output file ...` or110`error CS2012: Cannot open ... for writing`, the project itself is healthy —111**Aspire is running and holding file locks** on the resource's output assemblies.112The recovery is always the same:113114```bash115# ✅ Correct recovery sequence116aspire stop # release the locks117# ... then either rebuild / restart one resource if the resource exposes commands ...118aspire resource <name> rebuild # example: C# project resource with rebuild command119# ... or restart the whole AppHost ...120aspire start # if AppHost code changed or Aspire was already stopped121```122123| ❌ NEVER do | ✅ ALWAYS do |124|------------|-------------|125| Tell the user the project has a permanent build failure | Recognize the lock as Aspire holding outputs and run `aspire stop` |126| `dotnet build` again with locks held | `aspire stop` first, then `dotnet build` (or prefer resource commands/watch/HMR/debug workflow) |127| Delete `bin/` / `obj/` to "fix" the lock | `aspire stop` — deletion may succeed but the next build relocks |128| `pkill dotnet` or `kill <PID>` to free locks | `aspire stop` — clean shutdown via the CLI, no orphans |129| Tell the user to "reboot" or "restart your machine" | `aspire stop` — single command, instant fix |130131The same rule applies to any "file in use", "cannot access the file", or132"another process is using" error during a build of an Aspire-managed resource.133134## Handoff Rules135136| Scenario | Route To |137|----------|----------|138| AppHost wiring after `aspire init` (scan repo, add resources, ServiceDefaults/OTel) | → `aspireify` skill ([`../aspireify/SKILL.md`](../aspireify/SKILL.md)) or project-local `.agents/skills/aspireify/SKILL.md` |139| Browser logs (`Aspire.Hosting.Browsers` / `WithBrowserLogs()`) and dashboard authoring | → `aspireify` skill (code edits) and `aspire-monitoring` (discovery) |140| Custom resource commands (`WithCommand`, `ExecuteCommandResult`, `HttpCommandResultMode`) | → `aspireify` skill |141| Lifecycle hooks (`SubscribeBeforeStart`, `SubscribeAfterResourcesCreated`, BeforeStart pipeline phase) | → `aspireify` skill |142| Endpoint authoring (`WithEndpoint` updates, `ExcludeReferenceEndpoint` flag) | → `aspireify` skill |143| Deploy, publish, pipeline steps, `aspire destroy` | → `aspire-deployment` skill |144| Logs, traces, metrics, dashboard, `aspire dashboard run` | → `aspire-monitoring` skill |145| Deployed app diagnostics | → `azure-diagnostics` skill (azure-skills) |146147## Runtime Settings And Environment148149| Variable | Default | Purpose |150|----------|---------|---------|151| `ASPIRE_ENABLE_CONTAINER_TUNNEL` | `true` | Container tunnel provides uniform host connectivity across Docker Desktop, Docker Engine, and Podman. Set to `false` to opt out. |152| `ASPIRE_ENVIRONMENT` | unset | Selects the environment-specific config profile — controls which `appsettings.{environment}.json` is loaded and which environment is reported in dashboard telemetry. |153| `ASPIRE_DCP_USE_DEVELOPER_CERTIFICATE` | `true` | The Aspire trusted developer certificate is used by DCP on Windows. Set to `false` to opt out. |154| `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. |155156## TypeScript AppHost Note157158Detection covers TS AppHosts (`apphost.ts`), but **all TS AppHost authoring is delegated to `aspireify`**.159Current rules to apply when handing off:160161| Rule | Why |162|------|-----|163| 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 |164| Never edit `.aspire/modules/` directly | Generated; use `aspire add <package>` to regenerate and `aspire restore` to recover missing files |165| Use `aspire docs api search <query> --language typescript` for API lookup | TS surface differs from C# |166167## Skill Routing — In-Plugin Sibling Skills168169After `aspire init` drops a skeleton AppHost + `aspire.config.json`, route AppHost wiring170(scan repo → propose resource graph → edit AppHost → wire `Aspire.ServiceDefaults` / OTel →171validate via `aspire start`) to the in-plugin **aspireify** skill: [`../aspireify/SKILL.md`](../aspireify/SKILL.md).172For first-run flows that only need the skeleton drop, see the in-plugin **aspire-init** skill:173[`../aspire-init/SKILL.md`](../aspire-init/SKILL.md). This orchestration skill stays focused174on lifecycle (start/stop/wait/restart) and never edits AppHost code itself.175176## Project-Local Skill Precedence177178If `.agents/skills/aspire/SKILL.md` exists (from `aspire agent init`), defer to it for:179C# AppHost editing, TS AppHost editing, Playwright handoff, investigation workflows.180Safety guardrails from this plugin ALWAYS apply.181182If `.agents/skills/aspireify/SKILL.md` exists project-locally (installed by `aspire init` in183current Aspire), **warn the user** that a project-local aspireify skill is present and **defer to it**184for AppHost wiring instead of the in-plugin sibling. Same precedence rule as the project-local185`aspire` skill above: project-local wins, plugin guardrails still apply.186187## References188189- [safety-guardrails.md](references/safety-guardrails.md) — Detailed rules and recovery patterns190- [detection.md](references/detection.md) — Project fingerprinting191- [app-commands.md](references/app-commands.md) — App lifecycle and bootstrap commands192- [resource-management.md](references/resource-management.md) — Resource wait, restart, and operations193- [agent-workflows.md](references/agent-workflows.md) — Common agent investigation, integration, TypeScript, and handoff workflows
tuyv