aspire
installsforks
How to install aspire?
microsoft/aspire-skills/aspire
$npx -y skills add microsoft/aspire-skills --skill aspireWORKFLOW 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
SKILL.md
| 1 | # Aspire |
| 2 | |
| 3 | Use this skill when the task involves an Aspire distributed application — operating the |
| 4 | AppHost or its resources through the Aspire CLI rather than falling back to ad-hoc `dotnet`, |
| 5 | `docker`, or shell workflows. |
| 6 | |
| 7 | ## Detection |
| 8 | |
| 9 | Activate when ANY signal is present. Use the **Scope** column to decide whether to route to |
| 10 | the bootstrap skills (`aspire-init` / `aspireify`) or to a runtime sub-skill: |
| 11 | |
| 12 | | Signal | How to Detect | Confidence | Scope | |
| 13 | |--------|---------------|------------|-------| |
| 14 | | C# AppHost | `.csproj` containing `Aspire.AppHost.Sdk` | ✅ Definitive | AppHost present → orchestration / deployment / monitoring | |
| 15 | | File-based C# AppHost | `apphost.cs` with `#:sdk Aspire.AppHost.Sdk` | ✅ Definitive | AppHost present → orchestration / deployment / monitoring | |
| 16 | | TypeScript AppHost | `apphost.ts` file in project | ✅ Definitive | AppHost present → orchestration / deployment / monitoring | |
| 17 | | Aspire config without AppHost | `aspire.config.json` present **and no AppHost** above | High | Bootstrap → `aspireify` (skeleton dropped, needs wiring) | |
| 18 | | Aspire config with AppHost | `aspire.config.json` present **and** AppHost above | High | AppHost present → orchestration / deployment / monitoring | |
| 19 | | Aspire settings | `.aspire/` directory present | High | AppHost present (usually) | |
| 20 | | Generated TS modules | `.aspire/modules/` directory present | High | AppHost present (TS) | |
| 21 | | Service defaults | `Aspire.ServiceDefaults` in project references | Medium | AppHost present | |
| 22 | | **No AppHost, no `aspire.config.json`** | None of the above and user asks to add Aspire | n/a | Bootstrap → `aspire-init` (skeleton drop) | |
| 23 | |
| 24 | ## Default Workflow |
| 25 | |
| 26 | 0. **Bootstrap branch** — if **no AppHost exists** in the repo, route to |
| 27 | [`aspire-init`](https://github.com/microsoft/aspire-skills/blob/main/skills/aspire-init/SKILL.md) for the skeleton drop. If an AppHost stub exists |
| 28 | but is **unwired** (no resources declared), route to [`aspireify`](https://github.com/microsoft/aspire-skills/blob/main/skills/aspireify/SKILL.md). |
| 29 | Only continue with the steps below once a wired AppHost is present. |
| 30 | 1. Confirm workspace is Aspire — identify the AppHost |
| 31 | 2. `aspire start` (or `aspire start --isolated` in worktrees or whenever shared local state is risky) |
| 32 | 3. `aspire wait <resource>` before interacting with any resource |
| 33 | 4. Inspect state with `aspire describe`, `aspire otel logs`, `aspire logs`, `aspire otel traces`, and `aspire export` before making code changes |
| 34 | 5. Before adding integrations, use `aspire integration search <query>` when the package is unknown, then `aspire add <package>` when ready to mutate the AppHost |
| 35 | 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. |
| 36 | |
| 37 | ## Key Rules |
| 38 | |
| 39 | - **Always** `aspire start`, **never** `dotnet run` on AppHosts |
| 40 | - **Always** `aspire wait <resource>`, **never** manual HTTP polling |
| 41 | - Use `aspire resource <resource-name> <command>` for resource operations such as `stop`, `start`, or `rebuild` when available |
| 42 | - Do not stop or restart the whole AppHost just because one resource changed |
| 43 | - Use `features.defaultWatchEnabled` only for Aspire default watch; do not treat it as per-resource rebuild, restart, or hot reload |
| 44 | - Prefer a resource's own framework/runtime hot reload, HMR, or watch workflow when it already handles the change |
| 45 | - **Always** `aspire docs search <topic>` before editing unfamiliar AppHost APIs |
| 46 | - **Always** `aspire docs api search <query> --language csharp|typescript` for API reference before editing AppHost code |
| 47 | - **Always** `--non-interactive` for agent execution |
| 48 | - Use `aspire integration list --format Json` and `aspire integration search <query> --format Json` for read-only integration discovery |
| 49 | - **N |
People who liked this also viewed
6 picksType
- microsoft-foundryDeploy, evaluate, fine-tune, and manage Foundry agents end-to-end with azd: hosted agent scaffold/run/deploy, prompt agent create, batch eval, continuous eval, prompt optimizer, Agent Optimizer scaffoSkillsJul 2026
- azure-deployExecute 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 SkillsJul 2026
- azure-preparePrepare 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 wSkillsJul 2026
- azure-validate--- name: azure-validate description: "Pre-deployment validation for Azure readiness. Run deep checks on configuration, infrastructure (Bicep or Terraform), RBAC role assignments, managed identity pSkillsJul 2026
- azure-aigatewayConfigure Azure API Management as an AI Gateway for AI models, MCP tools, and agents. WHEN: semantic caching, token limit, content safety, load balancing, AI model governance, MCP rate limiting, jailbSkillsJul 2026
- azure-hosted-copilot-sdkOfficial agent plugin providing skills and MCP server configurations for Azure scenarios.SkillsJul 2026