--- name: aspire description: >- **WORKFLOW SKILL** - Top-level router for Aspire 13.4 distributed apps. Detects the AppHost, enforces safety guardrails, and routes to the right sub-skill. USE FOR: Aspire AppHost detected, aspire CLI, distributed app, cloud-native .NET, aspire start, aspire stop, aspire resource, aspire deploy, aspire destroy, aspire publish, aspire init, aspire new, aspire add, aspire integration list/search, aspire wait, aspire describe, aspire ps, aspire dashboard run, aspire doctor, aspire update, aspire logs, aspire otel, --include-hidden, aspireify, WithBrowserLogs, custom dashboard/resource commands, .aspire/modules recovery, Playwright URL discovery. DO NOT USE FOR: non-Aspire .NET projects (use dotnet directly), Azure provisioning without Aspire (use azure-prepare), container-only repos with no AppHost, ordinary build/test tasks. INVOKES: aspire-init, aspireify, aspire-orchestration, aspire-deployment, aspire-monitoring. FOR SINGLE OPERATIONS: Route directly to the matching sub-skill. license: MIT metadata: author: Microsoft version: "0.0.1" --- # Aspire Use this skill when the task involves an Aspire distributed application — operating the AppHost or its resources through the Aspire CLI rather than falling back to ad-hoc `dotnet`, `docker`, or shell workflows. ## Detection Activate when ANY signal is present. Use the **Scope** column to decide whether to route to the bootstrap skills (`aspire-init` / `aspireify`) or to a runtime sub-skill: | Signal | How to Detect | Confidence | Scope | |--------|---------------|------------|-------| | C# AppHost | `.csproj` containing `Aspire.AppHost.Sdk` | ✅ Definitive | AppHost present → orchestration / deployment / monitoring | | File-based C# AppHost | `apphost.cs` with `#:sdk Aspire.AppHost.Sdk` | ✅ Definitive | AppHost present → orchestration / deployment / monitoring | | TypeScript AppHost | `apphost.ts` file in project | ✅ Definitive | AppHost present → orchestration / deployment / monitoring | | Aspire config without AppHost | `aspire.config.json` present **and no AppHost** above | High | Bootstrap → `aspireify` (skeleton dropped, needs wiring) | | Aspire config with AppHost | `aspire.config.json` present **and** AppHost above | High | AppHost present → orchestration / deployment / monitoring | | Aspire settings | `.aspire/` directory present | High | AppHost present (usually) | | Generated TS modules | `.aspire/modules/` directory present | High | AppHost present (TS) | | Service defaults | `Aspire.ServiceDefaults` in project references | Medium | AppHost present | | **No AppHost, no `aspire.config.json`** | None of the above and user asks to add Aspire | n/a | Bootstrap → `aspire-init` (skeleton drop) | ## Default Workflow 0. **Bootstrap branch** — if **no AppHost exists** in the repo, route to [`aspire-init`](../aspire-init/SKILL.md) for the skeleton drop. If an AppHost stub exists but is **unwired** (no resources declared), route to [`aspireify`](../aspireify/SKILL.md). Only continue with the steps below once a wired AppHost is present. 1. Confirm workspace is Aspire — identify the AppHost 2. `aspire start` (or `aspire start --isolated` in worktrees or whenever shared local state is risky) 3. `aspire wait ` before interacting with any resource 4. Inspect state with `aspire describe`, `aspire otel logs`, `aspire logs`, `aspire otel traces`, and `aspire export` before making code changes 5. Before adding integrations, use `aspire integration search ` when the package is unknown, then `aspire add ` when ready to mutate the AppHost 6. When code changes, decide whether the AppHost model changed or only one resource changed. Re-run `aspire start` after AppHost changes; otherwise prefer resource commands, runtime watch/HMR, dashboard actions, or IDE-managed debugging as appropriate. ## Key Rules - **Always** `aspire start`, **never** `dotnet run` on AppHosts - **Always** `aspire wait `, **never** manual HTTP polling - Use `aspire resource ` for resource operations such as `stop`, `start`, or `rebuild` when available - Do not stop or restart the whole AppHost just because one resource changed - Use `features.defaultWatchEnabled` only for Aspire default watch; do not treat it as per-resource rebuild, restart, or hot reload - Prefer a resource's own framework/runtime hot reload, HMR, or watch workflow when it already handles the change - **Always** `aspire docs search ` before editing unfamiliar AppHost APIs - **Always** `aspire docs api search --language csharp|typescript` for API reference before editing AppHost code - **Always** `--non-interactive` for agent execution - Use `aspire integration list --format Json` and `aspire integration search --format Json` for read-only integration discovery - **Never** install the obsolete Aspire workload - **Never** edit `.aspire/modules/` directly in TypeScript AppHosts ## Routing | Task | Route To | |------|----------| | Start, stop, wait, restart, rebuild | → [aspire-orchestration](../aspire-orchestration/SKILL.md) | | Create a new Aspire project from a template (`aspire new`) | → [aspire-init](../aspire-init/SKILL.md) (in-plugin) | | Add Aspire to an existing repo (`aspire init`, drop skeleton) | → [aspire-init](../aspire-init/SKILL.md) (in-plugin) | | Wire AppHost / scaffold resource graph / add integrations after `aspire init` | → [aspireify](../aspireify/SKILL.md) (in-plugin) | | Deploy, publish, destroy, pipeline steps | → [aspire-deployment](../aspire-deployment/SKILL.md) | | Logs, traces, metrics, dashboard, browser logs | → [aspire-monitoring](../aspire-monitoring/SKILL.md) | | Deployed app monitoring (Azure) | → `azure-diagnostics` skill (azure-skills plugin) | ## Sub-Skills ### aspire-init First-run flow only. Owns the skeleton drop for repos that do **not** yet have an AppHost — picks `aspire new