aspire-deployment

Files (10)

• SKILL.md
• aws.md · references/
• azure.md · references/
• cicd.md · references/
• docker-compose.md · references/
• github-actions-azure-csharp.yml · references/
• github-actions-azure-typescript.yml · references/
• javascript.md · references/
• kubernetes.md · references/
• preflight.md · references/

SKILL.md (first lines)

# Aspire Deployment

Use 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.

Aspire 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.

Keep this as one skill with target-specific references. Load only the reference files that match the target you discover or the user requests.

## Routing precedence

This skill wins over generic cloud deployment skills when both conditions are true:

1. The user asks to deploy, publish, generate deployment artifacts, create Bicep/Helm/Compose/CDK output, host on Azure or AWS, deploy to Azure or AWS, deploy to Kubernetes, deploy to Docker Compose, 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

If 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.

## Guiding principles

### Use Aspire docs before changing deployment code

Before adding target packages, editing the AppHost, or using an unfamiliar deployment API, use Aspire docs:

```bash
aspire docs search "deploy with Aspire"
aspire docs search "Docker Compose deployment"
aspire docs search "Kubernetes deployment"
aspire docs search "Azure Container Apps deployment"
aspire docs search "Azure App Service deployment"
aspire docs search "Azure Kubernetes Service deployment"
aspire docs get "deploy-to-azure-kubernetes-service-aks"
aspire docs get "<slug-from-search-results>"
```

When 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:

```bash
aspire docs api search "<deployment API or concept>" --language csharp
aspire docs api search "<deployment API or concept>" --language typescript
aspire docs api get "<id-from-api-search>"
```

Do not invent package names, builder methods, overloads, or deployment commands. API shapes differ between C# and TypeScript AppHosts.

### Prefer Aspire-native deployment

Use Aspire deployment targets and CLI commands first:

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

Use target-specific tooling only after Aspire has generated artifacts or when the target docs call for it:

- 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.

### Ask where to deploy only when ambiguous

Do 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.

If 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:

> Where do you want to deploy this Aspire app?

Show these choices:

| Choice | Aspire add command | Use when |
|--------|--------------------|----------|
| Docker Compose | `aspire add docker` | The user wants local/server container deployment artifacts for Docker or Podman. |
| Kubernetes | `aspire add kubernetes` | The user has an existing Kubernetes cluster and wants Helm/Kubernetes artifacts or direct cluster deployment. |
| Azure Container Apps | `aspire add azure-appcontainers` | The user wants an Azure-managed container platform for distributed apps and services. |
| Azure App Service | `aspire add azure-appservice` | The user wants Azure website hosting for web apps/APIs that fit the App Service model. |
| Azure Kubernetes Service (AKS) | `aspire add azure-kubernetes` | The user wants Aspire to provision and deploy to Azure-managed Kubernetes. |
| AWS | `aspire add aws` | The user wants Aspire to publish/deploy through the AWS Aspire integrations and AWS CDK. |

If 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.

### Ask before creating cloud resources when intent is not explicit

Cloud deploys can create billable resources. If the user asked for a plan, preview, validation, or "make this deployable", stop after the deployment plan/artifacts and ask before running the command that provisions resources.

If the user explicitly asked to deploy now, continue through preflight and deployment, but still surface any target choice, subscription/resource group ambiguity, or missing parameter decisions before provisioning.

### Keep Azure deployment Aspire-native

The Azure deployment path in this skill is `aspire add <azure-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.

## Default workflow

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](references/docker-compose.md)
    - Kubernetes and Azure Kubernetes Service (AKS): [references/kubernetes.md](references/kubernetes.md)
    - Azure Container Apps/App Service/Azure Kubernetes Service (AKS): [references/azure.md](references/azure.md)
    - AWS: [references/aws.md](references/aws.md)
    - JavaScript app resources: [references/javascript.md](references/javascript.md)
    - CI/CD or GitHub Actions automation: [references/cicd.md](references/cicd.md)
4. **Use Aspire docs search for current guidance.**

From nam20485/.agents, MIT.

More from nam20485/.agents