1. The user asks to deploy, publish, generate deployment artifacts, create Bicep/Helm/Compose/CDK output, host on Azure or AWS, deploy to Azure, AWS, Kubernetes, Docker Compose, or Radius, tear down deployed resources, or validate a deployment.
2. The workspace has Aspire markers:
   • Aspire workspace configuration
   • C# or TypeScript AppHost files
   • an AppHost project
   • AppHost code using Aspire distributed application builder APIs

aspire ls

aspire config list

aspire ps

aspire describe

aspire publish --list-steps
aspire deploy --list-steps
aspire publish
aspire deploy
aspire destroy
aspire do <step>

• Docker Compose: inspect generated

  aspire-output/docker-compose.yaml

  and

  .env*

  ; Aspire can also run

  docker compose up

  through

  aspire deploy

  .
• Kubernetes: inspect generated Helm chart output; use Helm/kubectl when applying published artifacts yourself.
• Azure: use

  aspire add <azure-target>

  ,

  aspire publish

  , and

  aspire deploy

  through the AppHost deployment environment.
• AWS: use

  aspire add aws

  to add the integration, inspect generated CDK/CloudFormation output, and follow the AWS integrations repository guidance.
• Radius: treat

  Aspire.Hosting.Radius

  as preview. Use integration/docs search to verify the package and API, then model

  AddRadiusEnvironment(...).WithNamespace(...)

  .

Where do you want to deploy this Aspire app?

aspire add docker

aspire add kubernetes

aspire add azure-appcontainers

aspire add azure-appservice

aspire add azure-kubernetes

aspire add aws

Aspire.AppHost.Sdk

aspire add

MissingMethodException

TypeLoadException

• use

  .Services

  instead of hosting context

  .ServiceProvider

  ;
• use

  AddConnectionString

  instead of

  PublishAsConnectionString

  ; and
• migrate deprecated

  Aspire.Hosting.GitHub.Models

  resources to Azure AI Foundry.

1. Orient to the Aspire workspace.
   • 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.
   • If no AppHost exists, stop deployment work and invoke the

     aspireify

     skill to initialize/wire the AppHost before continuing.
   • Identify C# vs TypeScript AppHost.
   • Prefer Aspire CLI commands for discovery and state inspection.
2. Clarify or infer the deployment target.
   • 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.
   • If they only said "deploy", inspect existing AppHost target environment resources.
   • If exactly one target environment already exists, use it and state what was detected.
   • If multiple targets exist, none exists, or the user says only "Azure", ask where to deploy using the choices above.
3. Load target and app-type references.
   • Docker Compose: references/docker-compose.md
   • Kubernetes and Azure Kubernetes Service (AKS): references/kubernetes.md
   • Azure Container Apps/App Service/Azure Kubernetes Service (AKS): references/azure.md
   • AWS: references/aws.md
   • Radius preview: use current Aspire docs and API search for

     Aspire.Hosting.Radius

     ; do not guess experimental API shapes.
   • JavaScript app resources: references/javascript.md
   • CI/CD or GitHub Actions automation: references/cicd.md
4. Use Aspire docs search for current guidance.
   • Search and get the target deployment docs.
   • Search API docs before editing AppHost code.
5. Apply the target code changes.
   • Run the target's

     aspire add ...

     command if the integration is missing.
   • Add the deployment environment resource to the AppHost.
   • 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.
   • Add only the target-specific customization APIs the deployment needs, such as endpoint exposure, Helm settings, Compose file customization, Azure site/container app customization, or AWS publish target overrides.
6. Preflight the deployment model.
   • Confirm the target integration package exists in the AppHost.
   • Confirm the AppHost has the target environment resource.
   • 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.
   • Inventory parameters, secrets, connection strings, external endpoints, container registries, and target-specific prerequisites.
   • For Azure or AWS, confirm auth, target account/subscription, region/location, and resource group/stack context.
7. Preview before applying.
   • Run

     aspire publish --list-steps

     or

     aspire deploy --list-steps

     .
   • Use

     aspire publish -o <scratch-or-output-path>

     when artifact review is requested.
   • Treat published artifacts as a preview/handoff.

     aspire deploy

     resolves values and applies the deployment from the AppHost model; it does not consume a previously published output directory.
   • Summarize resources, endpoints, parameters, secrets, identities, and generated artifacts.
8. Deploy or hand off.
   • Run

     aspire deploy

     when the user asked to deploy and preflight is complete.
   • Run a named step with

     aspire do <step>

     only when the user asked for a specific pipeline step.
   • For published artifacts, explain the target-native apply step.
9. Destroy only when explicitly requested.
   • Run

     aspire destroy

     to execute the selected AppHost/environment's target destroy pipeline.
   • Confirm the AppHost, environment, target account/subscription/cluster, and destructive intent before running it.
   • Use

     --yes

     only when the user or CI workflow already made teardown intent explicit.
   • Prefer

     aspire destroy

     over target-native delete commands unless you are troubleshooting failed teardown or cleaning up unmanaged leftovers.
10. Verify the outcome.

• Use target output,

  aspire describe

  , cloud CLI, Docker Compose, kubectl, or endpoint checks appropriate to the target.
• After destroy, verify target resources are removed or record any leftovers that require manual cleanup.

• Parameter name from AppHost parameter APIs, including config-backed parameters
• Whether it is secret
• 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

• Where it flows, such as a project environment variable, connection string, Key Vault secret, Helm Secret, Compose

  .env

  , or Azure app setting
• Whether a value appears configured or missing

aspire secret list

• references/docker-compose.md - Docker Compose target, generated files, environment variables, cleanup.
• references/kubernetes.md - Kubernetes and Azure Kubernetes Service (AKS) target selection, Helm output, registry requirements, kubectl/Helm checks.
• references/azure.md - Azure target selection, Azure settings, Container Apps, App Service, and Azure Kubernetes Service (AKS).
• references/aws.md - AWS target selection, AWS CDK prerequisites, publish/deploy workflow, and AWS integration docs.
• references/javascript.md - JavaScript app deployment models, including Vite/static assets, Node/SSR servers, Next.js, and gateway/backend serving patterns.
• references/cicd.md - CI/CD and GitHub Actions workflow guidance for Aspire publish/deploy, parameters, secrets, registry auth, and cloud auth.
• references/preflight.md - Common preflight, preview, parameter, destroy, and validation checklist.
• aspire-13-5-breaking-changes.md - 13.5 package, API, and CLI migration rules.

aspire-orchestration

aspire-monitoring

aspireify

azure-diagnostics

Never hand deployment off to azure-skills. Aspire handles publish, deploy, and destroy end-to-end across Docker Compose / Kubernetes / Azure / AWS via the AppHost model.