[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M699ZMCSGC89R65VTEEA5KMT":3,"skill-same:01M699ZMCSGC89R65VTEEA5KMT":126},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":26,"publishedAt":47,"linkOnly":48,"markdownContent":49,"markdownBody":50,"frontMatter":51,"refName":54,"commitSha":55,"skillDirectory":56,"forksCount":57,"repositoryHtmlUrl":58,"repositoryHomepageUrl":59,"ownerHtmlUrl":60,"ownerBlogUrl":61,"ownerDescription":62,"updatedAt":63,"install":64,"resources":77},"01M699ZMCSGC89R65VTEEA5KMT","aspire-deployment",null,"**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\u002Fcontainer CLIs. FOR SINGLE OPERATIONS: use generic Azure, Kubernetes, Docker, AWS, or Radius tools only when no Aspire AppHost exists.","microsoft\u002Faspire-skills","microsoft","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F6154722?v=4","01M698VYDXZ6JW5WH3CRV650R8","Microsoft","01M699Z09A17E8C731AGNTAEVR",94,"MIT","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Faspire-skills\u002Fblob\u002Fmain\u002Fskills\u002Faspire-deployment\u002FSKILL.md",[18,23],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000011","运维与部署","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",[27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46],"aspire deployment","aspire","deployment","for","compose","Tools","radius","generate","publish","preview","apps","only","azure container apps","docker compose","workflow skill","app","workflow","kubernetes","docker","cli","2026-11-10 10:12:30",false,"---\nname: aspire-deployment\ndescription: \"**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\u002Fcontainer CLIs. FOR SINGLE OPERATIONS: use generic Azure, Kubernetes, Docker, AWS, or Radius tools only when no Aspire AppHost exists.\"\nlicense: MIT\nmetadata:\n  author: Microsoft\n  version: \"0.0.5\"\n---\n\n# Aspire Deployment\n\nUse this skill when the task is to publish, preview, validate, deploy, or tear down an Aspire application deployment. This skill owns Aspire deployment routing. Do not start with a generic Azure, Docker, Kubernetes, Helm, or Bicep workflow until you have checked whether the workspace is an Aspire app.\n\nAspire deployment starts from the AppHost model. Treat `aspire deploy`, `aspire publish`, `aspire destroy`, `aspire do`, and the deployment environment resources in the AppHost as the primary path. Use stable SDK\u002Fhosting packages from the project's release family and matching preview builds for preview-only integrations such as Kubernetes and Radius.\n\nKeep this as one skill with target-specific references. Load only the reference files that match the target you discover or the user requests.\n\n## Routing precedence\n\nThis skill wins over generic cloud deployment skills when both conditions are true:\n\n1. The user asks to deploy, publish, generate deployment artifacts, create Bicep\u002FHelm\u002FCompose\u002FCDK output, host on Azure or AWS, deploy to Azure, AWS, Kubernetes, Docker Compose, or Radius, tear down deployed resources, or validate a deployment.\n2. The workspace has Aspire markers:\n   - Aspire workspace configuration\n   - C# or TypeScript AppHost files\n   - an AppHost project\n   - AppHost code using Aspire distributed application builder APIs\n\nIf Aspire markers are present but this skill was not automatically invoked, switch to this skill before continuing. Prefer Aspire CLI commands such as `aspire ls`, `aspire config list`, `aspire ps`, and `aspire describe` for workspace orientation.\n\n## Guiding principles\n\n### Use Aspire docs before changing deployment code\n\nBefore adding target packages, editing the AppHost, or using an unfamiliar deployment API, use Aspire docs:\n\n```bash\naspire docs search \"deploy with Aspire\"\naspire docs search \"Docker Compose deployment\"\naspire docs search \"Kubernetes deployment\"\naspire docs search \"Azure Container Apps deployment\"\naspire docs search \"Azure App Service deployment\"\naspire docs search \"Azure Kubernetes Service deployment\"\naspire docs search \"Radius deployment\"\naspire docs get \"deploy-to-azure-kubernetes-service-aks\"\naspire docs get \"\u003Cslug-from-search-results>\"\n```\n\nWhen you need exact C# or TypeScript API shape, use API docs too. Search both languages when you are not sure which AppHost language the repo uses:\n\n```bash\naspire docs api search \"\u003Cdeployment API or concept>\" --language csharp\naspire docs api search \"\u003Cdeployment API or concept>\" --language typescript\naspire docs api get \"\u003Cid-from-api-search>\"\n```\n\nDo not invent package names, builder methods, overloads, or deployment commands. API shapes differ between C# and TypeScript AppHosts.\n\n### Prefer Aspire-native deployment\n\nDeploy the resources declared in the AppHost, not the AppHost process itself.\nFor Docker Compose, configure the Compose environment and let Aspire generate services\nfor those resources; do not replace this with an AppHost Dockerfile or Compose service.\n\nUse Aspire deployment targets and CLI commands first:\n\n```bash\naspire publish --list-steps\naspire deploy --list-steps\naspire publish\naspire deploy\naspire destroy\naspire do \u003Cstep>\n```\n\nUse target-specific tooling only after Aspire has generated artifacts or when the target docs call for it:\n\n- Docker Compose: inspect generated `aspire-output\u002Fdocker-compose.yaml` and `.env*`; Aspire can also run `docker compose up` through `aspire deploy`.\n- Kubernetes: inspect generated Helm chart output; use Helm\u002Fkubectl when applying published artifacts yourself.\n- Azure: use `aspire add \u003Cazure-target>`, `aspire publish`, and `aspire deploy` through the AppHost deployment environment.\n- AWS: use `aspire add aws` to add the integration, inspect generated CDK\u002FCloudFormation output, and follow the AWS integrations repository guidance.\n- Radius: treat `Aspire.Hosting.Radius` as preview. Use integration\u002Fdocs search to verify\n  the package and API, then model `AddRadiusEnvironment(...).WithNamespace(...)`.\n\n### Ask where to deploy only when ambiguous\n\nDo not ask for target selection when the user already chose a target such as Docker Compose, Kubernetes, Azure Container Apps, Azure App Service, Azure Kubernetes Service (AKS), or AWS. Use the chosen target and continue with its reference.\n\nIf the user did not explicitly choose a deployment target and the AppHost does not already contain exactly one deployment environment, ask where they want to deploy before adding integrations, editing the AppHost, publishing artifacts, or deploying. Use a single multiple-choice question:\n\n> Where do you want to deploy this Aspire app?\n\nShow these choices:\n\n| Choice | Aspire add command | Use when |\n|--------|--------------------|----------|\n| Docker Compose | `aspire add docker` | The user wants local\u002Fserver container deployment artifacts for Docker or Podman. |\n| Kubernetes | `aspire add kubernetes` | The user has an existing Kubernetes cluster and wants Helm\u002FKubernetes artifacts or direct cluster deployment. |\n| Azure Container Apps | `aspire add azure-appcontainers` | The user wants an Azure-managed container platform for distributed apps and services. |\n| Azure App Service | `aspire add azure-appservice` | The user wants Azure website hosting for web apps\u002FAPIs that fit the App Service model. |\n| Azure Kubernetes Service (AKS) | `aspire add azure-kubernetes` | The user wants Aspire to provision and deploy to Azure-managed Kubernetes. |\n| AWS | `aspire add aws` | The user wants Aspire to publish\u002Fdeploy through the AWS Aspire integrations and AWS CDK. |\n\nDo not offer preview Radius as a default choice. Use it when the user explicitly requests\nRadius or the AppHost already contains a Radius environment.\n\nIf the user says only \"Azure\", ask again with just the Azure choices: Azure Container Apps, Azure App Service, or Azure Kubernetes Service (AKS). If the AppHost already contains exactly one deployment environment and the user did not ask to change targets, use that target and tell the user what was detected.\n\n### Ask before creating cloud resources when intent is not explicit\n\nCloud deploys can create billable resources. If the user asked for a plan, preview, validation, or \"make this deployable\", stop after the deployment plan\u002Fartifacts and ask before running the command that provisions resources.\n\nIf the user explicitly asked to deploy now, continue through preflight and deployment, but still surface any target choice, subscription\u002Fresource group ambiguity, or missing parameter decisions before provisioning.\n\n### Keep Azure deployment Aspire-native\n\nThe Azure deployment path in this skill is `aspire add \u003Cazure-target>`, AppHost environment configuration, `aspire publish`, and `aspire deploy`. Do not route Azure deployment work through a separate Azure deployment tool or generated infrastructure workflow.\n\n### Keep Aspire packages on one release family\n\nBefore publish or deploy, verify that `Aspire.AppHost.Sdk` and the hosting packages use\ncompatible versions in the project's selected release family. Preview-only integrations\nneed compatible preview builds selected by `aspire add` or integration docs.\nThe CLI version does not make incompatible hosting packages safe; mixed graphs can\nfail at startup with `MissingMethodException` or `TypeLoadException`.\n\nMigrate obsolete 13.5 surfaces while editing deployment code:\n\n- use `.Services` instead of hosting context `.ServiceProvider`;\n- use `AddConnectionString` instead of `PublishAsConnectionString`; and\n- migrate deprecated `Aspire.Hosting.GitHub.Models` resources to Azure AI Foundry.\n\n## Default workflow\n\n1. **Orient to the Aspire workspace.**\n   - Start with `aspire ls` to list AppHosts in the current scope, then use `aspire.config.json`, AppHost project files, or `aspire ps` if more context is needed.\n   - If no AppHost exists, stop deployment work and invoke the `aspireify` skill to initialize\u002Fwire the AppHost before continuing.\n   - Identify C# vs TypeScript AppHost.\n   - Prefer Aspire CLI commands for discovery and state inspection.\n2. **Clarify or infer the deployment target.**\n   - If the user named Docker Compose, Kubernetes, Azure Container Apps, Azure App Service, Azure Kubernetes Service (AKS), or AWS, load that target reference without asking again.\n   - If they only said \"deploy\", inspect existing AppHost target environment resources.\n   - If exactly one target environment already exists, use it and state what was detected.\n   - If multiple targets exist, none exists, or the user says only \"Azure\", ask where to deploy using the choices above.\n3. **Load target and app-type references.**\n    - Docker Compose: [references\u002Fdocker-compose.md](references\u002Fdocker-compose.md)\n    - Kubernetes and Azure Kubernetes Service (AKS): [references\u002Fkubernetes.md](references\u002Fkubernetes.md)\n    - Azure Container Apps\u002FApp Service\u002FAzure Kubernetes Service (AKS): [references\u002Fazure.md](references\u002Fazure.md)\n    - AWS: [references\u002Faws.md](references\u002Faws.md)\n    - Radius preview: use current Aspire docs and API search for `Aspire.Hosting.Radius`;\n      do not guess experimental API shapes.\n    - JavaScript app resources: [references\u002Fjavascript.md](references\u002Fjavascript.md)\n    - CI\u002FCD or GitHub Actions automation: [references\u002Fcicd.md](references\u002Fcicd.md)\n4. **Use Aspire docs search for current guidance.**\n    - Search and get the target deployment docs.\n    - Search API docs before editing AppHost code.\n5. **Apply the target code changes.**\n   - Run the target's `aspire add ...` command if the integration is missing.\n   - Add the deployment environment resource to the AppHost.\n   - Do not add explicit compute-environment assignment for the common single-environment case. Only disambiguate when the AppHost has multiple deployment environments. In C# this is usually `WithComputeEnvironment(...)`; for TypeScript AppHosts, verify the current language-specific docs before assuming an equivalent.\n   - Add only the target-specific customization APIs the deployment needs, such as endpoint exposure, Helm settings, Compose file customization, Azure site\u002Fcontainer app customization, or AWS publish target overrides.\n6. **Preflight the deployment model.**\n   - Confirm the target integration package exists in the AppHost.\n   - Confirm the AppHost has the target environment resource.\n   - Confirm compute resources are assigned to the target environment only when multiple compute environments exist. A single compute environment is the common case and can be inferred.\n   - Inventory parameters, secrets, connection strings, external endpoints, container registries, and target-specific prerequisites.\n   - For Azure or AWS, confirm auth, target account\u002Fsubscription, region\u002Flocation, and resource group\u002Fstack context.\n7. **Preview before applying.**\n   - Run `aspire publish --list-steps` or `aspire deploy --list-steps`.\n   - Use `aspire publish -o \u003Cscratch-or-output-path>` when artifact review is requested.\n   - Treat published artifacts as a preview\u002Fhandoff. `aspire deploy` resolves values and applies the deployment from the AppHost model; it does not consume a previously published output directory.\n   - Summarize resources, endpoints, parameters, secrets, identities, and generated artifacts.\n8. **Deploy or hand off.**\n   - Run `aspire deploy` when the user asked to deploy and preflight is complete.\n   - Run a named step with `aspire do \u003Cstep>` only when the user asked for a specific pipeline step.\n   - For published artifacts, explain the target-native apply step.\n9. **Destroy only when explicitly requested.**\n   - Run `aspire destroy` to execute the selected AppHost\u002Fenvironment's target destroy pipeline.\n   - Confirm the AppHost, environment, target account\u002Fsubscription\u002Fcluster, and destructive intent before running it.\n   - Use `--yes` only when the user or CI workflow already made teardown intent explicit.\n   - Prefer `aspire destroy` over target-native delete commands unless you are troubleshooting failed teardown or cleaning up unmanaged leftovers.\n10. **Verify the outcome.**\n   - Use target output, `aspire describe`, cloud CLI, Docker Compose, kubectl, or endpoint checks appropriate to the target.\n   - After destroy, verify target resources are removed or record any leftovers that require manual cleanup.\n\n## AppHost target detection\n\nSearch the AppHost for deployment environment resources:\n\n| Target | Aspire add command | Integration | AppHost environment concept |\n|--------|--------------------|-------------|-----------------------------|\n| Docker Compose | `aspire add docker` | Docker hosting | Docker Compose environment |\n| Kubernetes | `aspire add kubernetes` | Kubernetes hosting | Kubernetes environment |\n| Azure Container Apps | `aspire add azure-appcontainers` | Azure Container Apps hosting | Azure Container Apps environment |\n| Azure App Service | `aspire add azure-appservice` | Azure App Service hosting | Azure App Service environment |\n| Azure Kubernetes Service (AKS) | `aspire add azure-kubernetes` | Azure Kubernetes hosting | Azure Kubernetes Service (AKS) environment |\n| AWS | `aspire add aws` | AWS hosting | AWS CDK environment |\n| Radius (preview) | Discover with `aspire integration search radius` | `Aspire.Hosting.Radius` | Radius environment |\n\nUse this table only for orientation. Before editing code, verify the current API in Aspire docs for the AppHost language.\n\n## Parameter and secret preflight\n\nParameters are deployment inputs. They may be supplied by configuration files, user secrets, environment variables, command-line args, interactive prompts, or CI\u002FCD secret stores depending on the target and command.\n\nBefore deployment, report:\n\n- Parameter name from AppHost parameter APIs, including config-backed parameters\n- Whether it is secret\n- Expected provider syntax such as `Parameters__name`; for parameter names with dashes, use underscores in environment variables, for example `registry-endpoint` becomes `Parameters__registry_endpoint`\n- Where it flows, such as a project environment variable, connection string, Key Vault secret, Helm Secret, Compose `.env`, or Azure app setting\n- Whether a value appears configured or missing\n\nUse `aspire secret list` for AppHost user secrets when appropriate, but do not print secret values. For deployment artifacts, inspect generated placeholders and mappings, not raw secret content.\n\n## Target references\n\n- [references\u002Fdocker-compose.md](references\u002Fdocker-compose.md) - Docker Compose target, generated files, environment variables, cleanup.\n- [references\u002Fkubernetes.md](references\u002Fkubernetes.md) - Kubernetes and Azure Kubernetes Service (AKS) target selection, Helm output, registry requirements, kubectl\u002FHelm checks.\n- [references\u002Fazure.md](references\u002Fazure.md) - Azure target selection, Azure settings, Container Apps, App Service, and Azure Kubernetes Service (AKS).\n- [references\u002Faws.md](references\u002Faws.md) - AWS target selection, AWS CDK prerequisites, publish\u002Fdeploy workflow, and AWS integration docs.\n- [references\u002Fjavascript.md](references\u002Fjavascript.md) - JavaScript app deployment models, including Vite\u002Fstatic assets, Node\u002FSSR servers, Next.js, and gateway\u002Fbackend serving patterns.\n- [references\u002Fcicd.md](references\u002Fcicd.md) - CI\u002FCD and GitHub Actions workflow guidance for Aspire publish\u002Fdeploy, parameters, secrets, registry auth, and cloud auth.\n- [references\u002Fpreflight.md](references\u002Fpreflight.md) - Common preflight, preview, parameter, destroy, and validation checklist.\n- [aspire-13-5-breaking-changes.md](https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Faspire-skills\u002Fblob\u002Fmain\u002Fskills\u002Faspire\u002Freferences\u002Faspire-13-5-breaking-changes.md) - 13.5 package, API, and CLI migration rules.\n\n## Agent execution\n\nWhen running unattended (CI, scripted, agent-driven), append `--non-interactive` to every Aspire CLI invocation that may prompt — most importantly `aspire publish`, `aspire deploy`, and `aspire destroy`. For `aspire destroy`, also pass `--yes` only after the user has explicitly confirmed teardown intent (or a CI workflow already encodes that intent).\n\nPrefer surfacing prompt-driving values up front (target subscription\u002Fregion\u002Fresource group, parameters, secrets, registry credentials) so the unattended run does not stall. See [references\u002Fpreflight.md](references\u002Fpreflight.md) for the full preflight checklist.\n\n## Handoff Rules\n\n| Scenario | Route To |\n|----------|----------|\n| Start, stop, wait, or restart the AppHost \u002F its resources | `aspire-orchestration` skill |\n| Logs, traces, metrics, dashboard for a running or deployed app | `aspire-monitoring` skill |\n| AppHost authoring — adding integrations, wiring resources, environment setup | `aspireify` skill |\n| Deployed-app diagnostics — App Insights, ACA logs, AKS Container Insights | `azure-diagnostics` skill (azure-skills) |\n\n> Never hand deployment off to azure-skills. Aspire handles publish, deploy, and destroy\n> end-to-end across Docker Compose \u002F Kubernetes \u002F Azure \u002F AWS via the AppHost model.\n\n## Project-Local Skill Override\n\nIf `.agents\u002Fskills\u002Faspire-deployment\u002FSKILL.md` exists (dropped by `aspire agent init`),\nprefer it over this plugin skill — it is the authoritative project-local version with\ncontent version-aligned to the consumer's Aspire CLI. This plugin skill is the always-on\nsafety net for repos that have not yet run `aspire agent init`.\n","# Aspire Deployment\n\nUse this skill when the task is to publish, preview, validate, deploy, or tear down an Aspire application deployment. This skill owns Aspire deployment routing. Do not start with a generic Azure, Docker, Kubernetes, Helm, or Bicep workflow until you have checked whether the workspace is an Aspire app.\n\nAspire deployment starts from the AppHost model. Treat `aspire deploy`, `aspire publish`, `aspire destroy`, `aspire do`, and the deployment environment resources in the AppHost as the primary path. Use stable SDK\u002Fhosting packages from the project's release family and matching preview builds for preview-only integrations such as Kubernetes and Radius.\n\nKeep this as one skill with target-specific references. Load only the reference files that match the target you discover or the user requests.\n\n## Routing precedence\n\nThis skill wins over generic cloud deployment skills when both conditions are true:\n\n1. The user asks to deploy, publish, generate deployment artifacts, create Bicep\u002FHelm\u002FCompose\u002FCDK output, host on Azure or AWS, deploy to Azure, AWS, Kubernetes, Docker Compose, or Radius, tear down deployed resources, or validate a deployment.\n2. The workspace has Aspire markers:\n   - Aspire workspace configuration\n   - C# or TypeScript AppHost files\n   - an AppHost project\n   - AppHost code using Aspire distributed application builder APIs\n\nIf Aspire markers are present but this skill was not automatically invoked, switch to this skill before continuing. Prefer Aspire CLI commands such as `aspire ls`, `aspire config list`, `aspire ps`, and `aspire describe` for workspace orientation.\n\n## Guiding principles\n\n### Use Aspire docs before changing deployment code\n\nBefore adding target packages, editing the AppHost, or using an unfamiliar deployment API, use Aspire docs:\n\n```bash\naspire docs search \"deploy with Aspire\"\naspire docs search \"Docker Compose deployment\"\naspire docs search \"Kubernetes deployment\"\naspire docs search \"Azure Container Apps deployment\"\naspire docs search \"Azure App Service deployment\"\naspire docs search \"Azure Kubernetes Service deployment\"\naspire docs search \"Radius deployment\"\naspire docs get \"deploy-to-azure-kubernetes-service-aks\"\naspire docs get \"\u003Cslug-from-search-results>\"\n```\n\nWhen you need exact C# or TypeScript API shape, use API docs too. Search both languages when you are not sure which AppHost language the repo uses:\n\n```bash\naspire docs api search \"\u003Cdeployment API or concept>\" --language csharp\naspire docs api search \"\u003Cdeployment API or concept>\" --language typescript\naspire docs api get \"\u003Cid-from-api-search>\"\n```\n\nDo not invent package names, builder methods, overloads, or deployment commands. API shapes differ between C# and TypeScript AppHosts.\n\n### Prefer Aspire-native deployment\n\nDeploy the resources declared in the AppHost, not the AppHost process itself.\nFor Docker Compose, configure the Compose environment and let Aspire generate services\nfor those resources; do not replace this with an AppHost Dockerfile or Compose service.\n\nUse Aspire deployment targets and CLI commands first:\n\n```bash\naspire publish --list-steps\naspire deploy --list-steps\naspire publish\naspire deploy\naspire destroy\naspire do \u003Cstep>\n```\n\nUse target-specific tooling only after Aspire has generated artifacts or when the target docs call for it:\n\n- Docker Compose: inspect generated `aspire-output\u002Fdocker-compose.yaml` and `.env*`; Aspire can also run `docker compose up` through `aspire deploy`.\n- Kubernetes: inspect generated Helm chart output; use Helm\u002Fkubectl when applying published artifacts yourself.\n- Azure: use `aspire add \u003Cazure-target>`, `aspire publish`, and `aspire deploy` through the AppHost deployment environment.\n- AWS: use `aspire add aws` to add the integration, inspect generated CDK\u002FCloudFormation output, and follow the AWS integrations repository guidance.\n- Radius: treat `Aspire.Hosting.Radius` as preview. Use integration\u002Fdocs search to verify\n  the package and API, then model `AddRadiusEnvironment(...).WithNamespace(...)`.\n\n### Ask where to deploy only when ambiguous\n\nDo not ask for target selection when the user already chose a target such as Docker Compose, Kubernetes, Azure Container Apps, Azure App Service, Azure Kubernetes Service (AKS), or AWS. Use the chosen target and continue with its reference.\n\nIf the user did not explicitly choose a deployment target and the AppHost does not already contain exactly one deployment environment, ask where they want to deploy before adding integrations, editing the AppHost, publishing artifacts, or deploying. Use a single multiple-choice question:\n\n> Where do you want to deploy this Aspire app?\n\nShow these choices:\n\n| Choice | Aspire add command | Use when |\n|--------|--------------------|----------|\n| Docker Compose | `aspire add docker` | The user wants local\u002Fserver container deployment artifacts for Docker or Podman. |\n| Kubernetes | `aspire add kubernetes` | The user has an existing Kubernetes cluster and wants Helm\u002FKubernetes artifacts or direct cluster deployment. |\n| Azure Container Apps | `aspire add azure-appcontainers` | The user wants an Azure-managed container platform for distributed apps and services. |\n| Azure App Service | `aspire add azure-appservice` | The user wants Azure website hosting for web apps\u002FAPIs that fit the App Service model. |\n| Azure Kubernetes Service (AKS) | `aspire add azure-kubernetes` | The user wants Aspire to provision and deploy to Azure-managed Kubernetes. |\n| AWS | `aspire add aws` | The user wants Aspire to publish\u002Fdeploy through the AWS Aspire integrations and AWS CDK. |\n\nDo not offer preview Radius as a default choice. Use it when the user explicitly requests\nRadius or the AppHost already contains a Radius environment.\n\nIf the user says only \"Azure\", ask again with just the Azure choices: Azure Container Apps, Azure App Service, or Azure Kubernetes Service (AKS). If the AppHost already contains exactly one deployment environment and the user did not ask to change targets, use that target and tell the user what was detected.\n\n### Ask before creating cloud resources when intent is not explicit\n\nCloud deploys can create billable resources. If the user asked for a plan, preview, validation, or \"make this deployable\", stop after the deployment plan\u002Fartifacts and ask before running the command that provisions resources.\n\nIf the user explicitly asked to deploy now, continue through preflight and deployment, but still surface any target choice, subscription\u002Fresource group ambiguity, or missing parameter decisions before provisioning.\n\n### Keep Azure deployment Aspire-native\n\nThe Azure deployment path in this skill is `aspire add \u003Cazure-target>`, AppHost environment configuration, `aspire publish`, and `aspire deploy`. Do not route Azure deployment work through a separate Azure deployment tool or generated infrastructure workflow.\n\n### Keep Aspire packages on one release family\n\nBefore publish or deploy, verify that `Aspire.AppHost.Sdk` and the hosting packages use\ncompatible versions in the project's selected release family. Preview-only integrations\nneed compatible preview builds selected by `aspire add` or integration docs.\nThe CLI version does not make incompatible hosting packages safe; mixed graphs can\nfail at startup with `MissingMethodException` or `TypeLoadException`.\n\nMigrate obsolete 13.5 surfaces while editing deployment code:\n\n- use `.Services` instead of hosting context `.ServiceProvider`;\n- use `AddConnectionString` instead of `PublishAsConnectionString`; and\n- migrate deprecated `Aspire.Hosting.GitHub.Models` resources to Azure AI Foundry.\n\n## Default workflow\n\n1. **Orient to the Aspire workspace.**\n   - Start with `aspire ls` to list AppHosts in the current scope, then use `aspire.config.json`, AppHost project files, or `aspire ps` if more context is needed.\n   - If no AppHost exists, stop deployment work and invoke the `aspireify` skill to initialize\u002Fwire the AppHost before continuing.\n   - Identify C# vs TypeScript AppHost.\n   - Prefer Aspire CLI commands for discovery and state inspection.\n2. **Clarify or infer the deployment target.**\n   - If the user named Docker Compose, Kubernetes, Azure Container Apps, Azure App Service, Azure Kubernetes Service (AKS), or AWS, load that target reference without asking again.\n   - If they only said \"deploy\", inspect existing AppHost target environment resources.\n   - If exactly one target environment already exists, use it and state what was detected.\n   - If multiple targets exist, none exists, or the user says only \"Azure\", ask where to deploy using the choices above.\n3. **Load target and app-type references.**\n    - Docker Compose: [references\u002Fdocker-compose.md](references\u002Fdocker-compose.md)\n    - Kubernetes and Azure Kubernetes Service (AKS): [references\u002Fkubernetes.md](references\u002Fkubernetes.md)\n    - Azure Container Apps\u002FApp Service\u002FAzure Kubernetes Service (AKS): [references\u002Fazure.md](references\u002Fazure.md)\n    - AWS: [references\u002Faws.md](references\u002Faws.md)\n    - Radius preview: use current Aspire docs and API search for `Aspire.Hosting.Radius`;\n      do not guess experimental API shapes.\n    - JavaScript app resources: [references\u002Fjavascript.md](references\u002Fjavascript.md)\n    - CI\u002FCD or GitHub Actions automation: [references\u002Fcicd.md](references\u002Fcicd.md)\n4. **Use Aspire docs search for current guidance.**\n    - Search and get the target deployment docs.\n    - Search API docs before editing AppHost code.\n5. **Apply the target code changes.**\n   - Run the target's `aspire add ...` command if the integration is missing.\n   - Add the deployment environment resource to the AppHost.\n   - Do not add explicit compute-environment assignment for the common single-environment case. Only disambiguate when the AppHost has multiple deployment environments. In C# this is usually `WithComputeEnvironment(...)`; for TypeScript AppHosts, verify the current language-specific docs before assuming an equivalent.\n   - Add only the target-specific customization APIs the deployment needs, such as endpoint exposure, Helm settings, Compose file customization, Azure site\u002Fcontainer app customization, or AWS publish target overrides.\n6. **Preflight the deployment model.**\n   - Confirm the target integration package exists in the AppHost.\n   - Confirm the AppHost has the target environment resource.\n   - Confirm compute resources are assigned to the target environment only when multiple compute environments exist. A single compute environment is the common case and can be inferred.\n   - Inventory parameters, secrets, connection strings, external endpoints, container registries, and target-specific prerequisites.\n   - For Azure or AWS, confirm auth, target account\u002Fsubscription, region\u002Flocation, and resource group\u002Fstack context.\n7. **Preview before applying.**\n   - Run `aspire publish --list-steps` or `aspire deploy --list-steps`.\n   - Use `aspire publish -o \u003Cscratch-or-output-path>` when artifact review is requested.\n   - Treat published artifacts as a preview\u002Fhandoff. `aspire deploy` resolves values and applies the deployment from the AppHost model; it does not consume a previously published output directory.\n   - Summarize resources, endpoints, parameters, secrets, identities, and generated artifacts.\n8. **Deploy or hand off.**\n   - Run `aspire deploy` when the user asked to deploy and preflight is complete.\n   - Run a named step with `aspire do \u003Cstep>` only when the user asked for a specific pipeline step.\n   - For published artifacts, explain the target-native apply step.\n9. **Destroy only when explicitly requested.**\n   - Run `aspire destroy` to execute the selected AppHost\u002Fenvironment's target destroy pipeline.\n   - Confirm the AppHost, environment, target account\u002Fsubscription\u002Fcluster, and destructive intent before running it.\n   - Use `--yes` only when the user or CI workflow already made teardown intent explicit.\n   - Prefer `aspire destroy` over target-native delete commands unless you are troubleshooting failed teardown or cleaning up unmanaged leftovers.\n10. **Verify the outcome.**\n   - Use target output, `aspire describe`, cloud CLI, Docker Compose, kubectl, or endpoint checks appropriate to the target.\n   - After destroy, verify target resources are removed or record any leftovers that require manual cleanup.\n\n## AppHost target detection\n\nSearch the AppHost for deployment environment resources:\n\n| Target | Aspire add command | Integration | AppHost environment concept |\n|--------|--------------------|-------------|-----------------------------|\n| Docker Compose | `aspire add docker` | Docker hosting | Docker Compose environment |\n| Kubernetes | `aspire add kubernetes` | Kubernetes hosting | Kubernetes environment |\n| Azure Container Apps | `aspire add azure-appcontainers` | Azure Container Apps hosting | Azure Container Apps environment |\n| Azure App Service | `aspire add azure-appservice` | Azure App Service hosting | Azure App Service environment |\n| Azure Kubernetes Service (AKS) | `aspire add azure-kubernetes` | Azure Kubernetes hosting | Azure Kubernetes Service (AKS) environment |\n| AWS | `aspire add aws` | AWS hosting | AWS CDK environment |\n| Radius (preview) | Discover with `aspire integration search radius` | `Aspire.Hosting.Radius` | Radius environment |\n\nUse this table only for orientation. Before editing code, verify the current API in Aspire docs for the AppHost language.\n\n## Parameter and secret preflight\n\nParameters are deployment inputs. They may be supplied by configuration files, user secrets, environment variables, command-line args, interactive prompts, or CI\u002FCD secret stores depending on the target and command.\n\nBefore deployment, report:\n\n- Parameter name from AppHost parameter APIs, including config-backed parameters\n- Whether it is secret\n- Expected provider syntax such as `Parameters__name`; for parameter names with dashes, use underscores in environment variables, for example `registry-endpoint` becomes `Parameters__registry_endpoint`\n- Where it flows, such as a project environment variable, connection string, Key Vault secret, Helm Secret, Compose `.env`, or Azure app setting\n- Whether a value appears configured or missing\n\nUse `aspire secret list` for AppHost user secrets when appropriate, but do not print secret values. For deployment artifacts, inspect generated placeholders and mappings, not raw secret content.\n\n## Target references\n\n- [references\u002Fdocker-compose.md](references\u002Fdocker-compose.md) - Docker Compose target, generated files, environment variables, cleanup.\n- [references\u002Fkubernetes.md](references\u002Fkubernetes.md) - Kubernetes and Azure Kubernetes Service (AKS) target selection, Helm output, registry requirements, kubectl\u002FHelm checks.\n- [references\u002Fazure.md](references\u002Fazure.md) - Azure target selection, Azure settings, Container Apps, App Service, and Azure Kubernetes Service (AKS).\n- [references\u002Faws.md](references\u002Faws.md) - AWS target selection, AWS CDK prerequisites, publish\u002Fdeploy workflow, and AWS integration docs.\n- [references\u002Fjavascript.md](references\u002Fjavascript.md) - JavaScript app deployment models, including Vite\u002Fstatic assets, Node\u002FSSR servers, Next.js, and gateway\u002Fbackend serving patterns.\n- [references\u002Fcicd.md](references\u002Fcicd.md) - CI\u002FCD and GitHub Actions workflow guidance for Aspire publish\u002Fdeploy, parameters, secrets, registry auth, and cloud auth.\n- [references\u002Fpreflight.md](references\u002Fpreflight.md) - Common preflight, preview, parameter, destroy, and validation checklist.\n- [aspire-13-5-breaking-changes.md](https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Faspire-skills\u002Fblob\u002Fmain\u002Fskills\u002Faspire\u002Freferences\u002Faspire-13-5-breaking-changes.md) - 13.5 package, API, and CLI migration rules.\n\n## Agent execution\n\nWhen running unattended (CI, scripted, agent-driven), append `--non-interactive` to every Aspire CLI invocation that may prompt — most importantly `aspire publish`, `aspire deploy`, and `aspire destroy`. For `aspire destroy`, also pass `--yes` only after the user has explicitly confirmed teardown intent (or a CI workflow already encodes that intent).\n\nPrefer surfacing prompt-driving values up front (target subscription\u002Fregion\u002Fresource group, parameters, secrets, registry credentials) so the unattended run does not stall. See [references\u002Fpreflight.md](references\u002Fpreflight.md) for the full preflight checklist.\n\n## Handoff Rules\n\n| Scenario | Route To |\n|----------|----------|\n| Start, stop, wait, or restart the AppHost \u002F its resources | `aspire-orchestration` skill |\n| Logs, traces, metrics, dashboard for a running or deployed app | `aspire-monitoring` skill |\n| AppHost authoring — adding integrations, wiring resources, environment setup | `aspireify` skill |\n| Deployed-app diagnostics — App Insights, ACA logs, AKS Container Insights | `azure-diagnostics` skill (azure-skills) |\n\n> Never hand deployment off to azure-skills. Aspire handles publish, deploy, and destroy\n> end-to-end across Docker Compose \u002F Kubernetes \u002F Azure \u002F AWS via the AppHost model.\n\n## Project-Local Skill Override\n\nIf `.agents\u002Fskills\u002Faspire-deployment\u002FSKILL.md` exists (dropped by `aspire agent init`),\nprefer it over this plugin skill — it is the authoritative project-local version with\ncontent version-aligned to the consumer's Aspire CLI. This plugin skill is the always-on\nsafety net for repos that have not yet run `aspire agent init`.\n",{"name":5,"license":15,"metadata":52,"description":7},{"author":12,"version":53},"0.0.5","main","1117facb04b403dd2fc15f048bc0e63fc67c502f","skills\u002Faspire-deployment",12,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Faspire-skills","https:\u002F\u002Faspire.dev\u002Fget-started\u002Faspire-skills\u002F","https:\u002F\u002Fgithub.com\u002Fmicrosoft","https:\u002F\u002Fopensource.microsoft.com","Open source projects and samples from Microsoft","2026-11-11 08:52:06",{"source":8,"skillName":5,"commands":65,"prompt":75,"zipAvailable":76},[66,69,72],{"tool":67,"command":68},"npx","npx skills add microsoft\u002Faspire-skills --skill aspire-deployment",{"tool":70,"command":71},"bunx","bunx skills add microsoft\u002Faspire-skills --skill aspire-deployment",{"tool":73,"command":74},"pnpm","pnpm dlx skills add microsoft\u002Faspire-skills --skill aspire-deployment","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Faspire-skills\u002Fblob\u002Fmain\u002Fskills\u002Faspire-deployment\u002FSKILL.md",true,[78,84,90,94,98,102,106,110,114,118,122],{"path":79,"resourceType":80,"resourceTypeDesc":81,"sizeBytes":82,"sourceHtmlUrl":83},"evals\u002Feval.yaml","REFERENCE","参考文档",31108,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Faspire-skills\u002Fblob\u002Fmain\u002Fskills\u002Faspire-deployment\u002Fevals\u002Feval.yaml",{"path":85,"resourceType":86,"resourceTypeDesc":87,"sizeBytes":88,"sourceHtmlUrl":89},"evals\u002Ffixtures","OTHER","其他",14,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Faspire-skills\u002Fblob\u002Fmain\u002Fskills\u002Faspire-deployment\u002Fevals\u002Ffixtures",{"path":91,"resourceType":80,"resourceTypeDesc":81,"sizeBytes":92,"sourceHtmlUrl":93},"references\u002Faws.md",8678,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Faspire-skills\u002Fblob\u002Fmain\u002Fskills\u002Faspire-deployment\u002Freferences\u002Faws.md",{"path":95,"resourceType":80,"resourceTypeDesc":81,"sizeBytes":96,"sourceHtmlUrl":97},"references\u002Fazure.md",20740,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Faspire-skills\u002Fblob\u002Fmain\u002Fskills\u002Faspire-deployment\u002Freferences\u002Fazure.md",{"path":99,"resourceType":80,"resourceTypeDesc":81,"sizeBytes":100,"sourceHtmlUrl":101},"references\u002Fcicd.md",14879,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Faspire-skills\u002Fblob\u002Fmain\u002Fskills\u002Faspire-deployment\u002Freferences\u002Fcicd.md",{"path":103,"resourceType":80,"resourceTypeDesc":81,"sizeBytes":104,"sourceHtmlUrl":105},"references\u002Fdocker-compose.md",7509,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Faspire-skills\u002Fblob\u002Fmain\u002Fskills\u002Faspire-deployment\u002Freferences\u002Fdocker-compose.md",{"path":107,"resourceType":80,"resourceTypeDesc":81,"sizeBytes":108,"sourceHtmlUrl":109},"references\u002Fgithub-actions-azure-csharp.yml",1594,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Faspire-skills\u002Fblob\u002Fmain\u002Fskills\u002Faspire-deployment\u002Freferences\u002Fgithub-actions-azure-csharp.yml",{"path":111,"resourceType":80,"resourceTypeDesc":81,"sizeBytes":112,"sourceHtmlUrl":113},"references\u002Fgithub-actions-azure-typescript.yml",1560,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Faspire-skills\u002Fblob\u002Fmain\u002Fskills\u002Faspire-deployment\u002Freferences\u002Fgithub-actions-azure-typescript.yml",{"path":115,"resourceType":80,"resourceTypeDesc":81,"sizeBytes":116,"sourceHtmlUrl":117},"references\u002Fjavascript.md",8136,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Faspire-skills\u002Fblob\u002Fmain\u002Fskills\u002Faspire-deployment\u002Freferences\u002Fjavascript.md",{"path":119,"resourceType":80,"resourceTypeDesc":81,"sizeBytes":120,"sourceHtmlUrl":121},"references\u002Fkubernetes.md",14495,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Faspire-skills\u002Fblob\u002Fmain\u002Fskills\u002Faspire-deployment\u002Freferences\u002Fkubernetes.md",{"path":123,"resourceType":80,"resourceTypeDesc":81,"sizeBytes":124,"sourceHtmlUrl":125},"references\u002Fpreflight.md",9874,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Faspire-skills\u002Fblob\u002Fmain\u002Fskills\u002Faspire-deployment\u002Freferences\u002Fpreflight.md",[127,156,180,199,206,225],{"skillNo":128,"name":129,"nameZh":6,"description":130,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":131,"categories":132,"keywords":139,"publishedAt":47},"01M6HDNG43XGF64N14PV9VGGKB","aspire-terminals","**WORKFLOW SKILL** - Author and automate Aspire terminals. USE FOR: WithTerminal, withTerminal, TerminalService, TerminalLaunchOptions, docked terminals, terminal prompts, PromptTerminalAsync, TerminalPlacement, AspireTerminalKey, WithRepl, withRepl, aspire terminal ps\u002Fattach\u002Ftape play, VHS tapes for Aspire, or terminal screen\u002Finput automation. DO NOT USE FOR: generic shell commands, ordinary AppHost resource wiring (aspireify), start\u002Fstop\u002Fwait (aspire-orchestration), logs\u002Ftraces or browser telemetry (aspire-monitoring), deployment (aspire-deployment), or nonterminal Interaction Service prompts (aspireify). INVOKES: Aspire docs\u002FAPI lookup, AppHost edits, Aspire terminal CLI; aspire-orchestration for lifecycle validation. FOR SINGLE OPERATIONS: Choose the terminal owner and lifetime first, then read the matching reference.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Faspire-skills\u002Fblob\u002Fmain\u002Fskills\u002Faspire-terminals\u002FSKILL.md",[133,134],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":135,"categoryName":136,"taxonomyType":137,"taxonomyTypeDesc":138},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[28,140,46,141,142,43,143,144,145,146,147,148,149,150,151,152,153,154,155,41],"aspire terminals","terminal","orchestration","aspireify","browser","logs","monitoring","start","api","choose","read","attach","commands","interaction","screen","input",{"skillNo":157,"name":143,"nameZh":6,"description":158,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":159,"categories":160,"keywords":166,"publishedAt":47},"01M6HDMDCMMBTXTWKBVGJM0615","**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\u002Fscaffold AppHost, add Postgres\u002FRedis\u002FRabbit\u002FMongo, connect frontend to API, after `aspire init`, AddNextJsApp, AddViteApp, WithBrowserLogs, Interaction Service, command arguments, apphost.cs, apphost.mts, unified withEnvironment, .aspire\u002Fmodules refusal, config\u002Fsecrets, TS dependency restore, pnpm\u002Fyarn\u002Fbun, or Yarn Classic. DO NOT USE FOR: skeleton drop (aspire-init), lifecycle-only start\u002Fstop\u002Fwait\u002Frestart or `aspire update --migrate` (aspire-orchestration), publish\u002Fdeploy\u002Fdestroy (aspire-deployment), logs\u002Ftraces (aspire-monitoring), terminal authoring or automation (aspire-terminals). INVOKES: aspire CLI, AppHost source edits, ServiceDefaults wiring. FOR SINGLE OPERATIONS: Run `aspire add PACKAGE` directly for a one-off integration.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Faspire-skills\u002Fblob\u002Fmain\u002Fopencode\u002Fv1\u002Faspireify\u002FSKILL.md",[161,164,165],{"categoryNo":162,"categoryName":163,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000009","前端开发",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":135,"categoryName":136,"taxonomyType":137,"taxonomyTypeDesc":138},[143,167,141,168,169,170,171,172,173,145,146,147,174,175,176,177,73,178,153,179],"frontend","typescript","config","connect","run","update","yarn","migrate","command","modules","stop","authoring","wait",{"skillNo":181,"name":28,"nameZh":6,"description":182,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":183,"categories":184,"keywords":189,"publishedAt":47},"01M6HDM7MR6SFZHAM32RNM2MKB","**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\u002Fstop\u002Fresource\u002Fdeploy\u002Fdestroy\u002Fpublish\u002Finit\u002Fnew\u002Fadd\u002Fwait\u002Fdescribe\u002Fps\u002Flogs\u002Fotel, aspire agent init, WithBrowserLogs, WithTerminal, TerminalService, terminal prompts, WithRepl, tapes, Interaction Service, apphost.mts, TS package managers, Yarn Classic, custom resource commands, .aspire\u002Fmodules recovery, ProjectResource to DotnetProjectResource migration, or Playwright URL discovery. DO NOT USE FOR: non-Aspire projects or ordinary build\u002Ftest tasks. INVOKES: aspire-init, aspireify, aspire-project-v2-migration, aspire-orchestration, aspire-deployment, aspire-monitoring, aspire-terminals. FOR SINGLE OPERATIONS: Route directly to the matching sub-skill.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Faspire-skills\u002Fblob\u002Fmain\u002Fopencode\u002Fv1\u002Faspire\u002FSKILL.md",[185,188],{"categoryNo":186,"categoryName":187,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[28,142,43,190,143,191,145,146,35,192,193,194,176,195,196,42,153,41,197,198],"init","tasks","Guardrails","projects","router","route","project","URL","managers",{"skillNo":200,"name":129,"nameZh":6,"description":130,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":201,"categories":202,"keywords":205,"publishedAt":47},"01M6HDM2RMF6Q15YHYTS7G9SWZ","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Faspire-skills\u002Fblob\u002Fmain\u002Fopencode\u002Fv1\u002Faspire-terminals\u002FSKILL.md",[203,204],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":135,"categoryName":136,"taxonomyType":137,"taxonomyTypeDesc":138},[28,140,46,141,142,43,143,144,145,146,147,148,149,150,151,152,153,154,155,41],{"skillNo":207,"name":208,"nameZh":6,"description":209,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":210,"categories":211,"keywords":213,"publishedAt":47},"01M6HDKY1PNCDYBC317440ZHZ0","aspire-project-v2-migration","**WORKFLOW SKILL** - Safely migrates eligible Aspire 13.6+ AppHosts from legacy ProjectResource APIs to experimental DotnetProjectResource APIs after a per-resource assessment and explicit approval of exact edits. USE FOR: assess or migrate existing AddProject, addProject, AddCSharpApp, addCSharpApp, or AddBlazorGateway resources to Project v2; migrate ProjectResource to DotnetProjectResource; clean up the resulting obsolete AppHost ProjectReference edges. DO NOT USE FOR: upgrading Aspire versions, creating\u002Fwiring a new AppHost, Azure Functions migration, generic source modernization, ordinary C# resource wiring or adding a new AddProject resource (use aspireify), publishing, or build\u002Flifecycle diagnostics. INVOKES: Aspire docs\u002FAPI lookup, aspire add\u002Frestore\u002Fstart\u002Fwait, AppHost and package edits. FOR SINGLE OPERATIONS: Assess first; never edit from a generic migration request alone.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Faspire-skills\u002Fblob\u002Fmain\u002Fopencode\u002Fv1\u002Faspire-project-v2-migration\u002FSKILL.md",[212],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[28,214,215,196,43,143,216,217,218,147,148,174,219,220,221,222,179,41,223,224],"aspire project v2 migration","migration","diagnostics","modernization","assessment","edit","never","up","clean","resources","source",{"skillNo":226,"name":227,"nameZh":6,"description":228,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":229,"categories":230,"keywords":233,"publishedAt":47},"01M6HDKQX187B70G2MK589KWC7","aspire-orchestration","**WORKFLOW SKILL** — Manage Aspire lifecycle in VS Code or the CLI. WHEN: \"start or stop my Aspire app\", \"aspire_apphost_start\", \"aspire_apphost_stop\", \"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 stop --force --volumes\", 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\u002Fpublish\u002Fdestroy (aspire-deployment), logs\u002Ftraces\u002Fmetrics (aspire-monitoring), terminal authoring\u002Fattach\u002Ftapes (aspire-terminals), or AppHost code and resource wiring (aspireify). FOR SINGLE OPERATIONS: Load the matching editor tool first; follow exact-target, worktree-isolation, and stop-result rules.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Faspire-skills\u002Fblob\u002Fmain\u002Fopencode\u002Fv1\u002Faspire-orchestration\u002FSKILL.md",[231,232],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":135,"categoryName":136,"taxonomyType":137,"taxonomyTypeDesc":138},[142,28,234,43,143,235,145,146,35,174,236,237,238,151,239,42,41,240,241,242],"aspire orchestration","code","git worktrees","default","conflicts","self","port","errors","lock"]