Aspire

Name: Aspire
Author: microsoft

microsoft/aspire-skills

151 installs
74 repo stars
Updated July 27, 2026
microsoft/aspire-skills

aspire is a workflow router skill that detects Aspire AppHosts and routes CLI tasks to orchestration, deployment, monitoring, or bootstrap sub-skills.

About

The aspire skill is a workflow router for Aspire 13.4 distributed applications. It detects AppHosts via Aspire.AppHost.Sdk in csproj, file-based apphost.cs, TypeScript apphost.ts, aspire.config.json, or .aspire directories, then routes bootstrap repos without AppHosts to aspire-init or unwired stubs to aspireify. Wired AppHosts follow a default workflow: aspire start with optional --isolated, aspire wait before resource interaction, inspection via describe logs and otel traces, integration search before aspire add, and selective restarts instead of full AppHost stops. Safety guardrails forbid dotnet run on AppHosts, manual HTTP polling, editing generated .aspire/modules, and the obsolete Aspire workload. Sub-skills cover orchestration, deployment to Azure Container Apps AKS and Docker Compose, and monitoring with dashboard and Playwright handoff. Project-local .agents/skills overrides take precedence while plugin guardrails still apply. Use when operating Aspire distributed apps through the CLI rather than ad-hoc dotnet docker or shell workflows.

Detects C#, file-based, and TypeScript AppHosts with confidence scoring.
Enforces aspire start, aspire wait, and --non-interactive agent execution.
Routes to aspire-init, aspireify, orchestration, deployment, and monitoring sub-skills.
Blocks dotnet run on AppHosts and direct .aspire/modules edits.
Defers to project-local .agents/skills overrides when present.

Aspire by the numbers

151 all-time installs (skills.sh)
Ranked #452 of 1,453 DevOps & CI/CD skills by installs in the Skillselion catalog
Data as of Jul 28, 2026 (Skillselion catalog sync)

At a glance

aspire capabilities & compatibility

Capabilities: apphost detection across c# and typescript · bootstrap routing to aspire init and aspireify · cli safety guardrails for agent execution · sub skill delegation for orchestration deploymen · project local skill override precedence handling
Works with: azure · docker · kubernetes
Use cases: devops · ci cd · orchestration

npx skills add https://github.com/microsoft/aspire-skills --skill aspire

Add your badge

Show developers this skill is listed on Skillselion. Paste this into your README.

[![Listed on Skillselion](https://skillselion.com/badge/skills/microsoft/aspire-skills/aspire.svg)](https://skillselion.com/skills/microsoft/aspire-skills/aspire)

Installs	151
repo stars	★ 74
Last updated	July 27, 2026
Repository	microsoft/aspire-skills ↗

How should an agent operate an Aspire distributed app without unsafe dotnet run or ad-hoc shell workflows?

Route Aspire 13.4 distributed app tasks through the top-level Aspire CLI router with detection, safety guardrails, and sub-skill delegation.

Who is it for?

Developers and agents working on Aspire 13.4 distributed apps with AppHost detection and CLI lifecycle tasks.

Skip if: Skip for non-Aspire .NET projects, container-only repos without AppHost, or ordinary build and test tasks.

When should I use this skill?

User mentions Aspire AppHost, aspire CLI, distributed app start deploy, or aspire dashboard logs.

What you get

Correct sub-skill routing with aspire start, aspire wait, and guardrail-compliant CLI operations.

Files

SKILL.mdMarkdownGitHub ↗

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` for the skeleton drop. If an AppHost stub exists but is unwired (no resources declared), route to `aspireify`. 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 <resource> 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 <query> when the package is unknown, then aspire add <package> 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 <resource>, never manual HTTP polling
Use aspire resource <resource-name> <command> 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 <topic> before editing unfamiliar AppHost APIs
Always aspire docs api search <query> --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 <query> --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
Create a new Aspire project from a template (`aspire new`)	→ aspire-init (in-plugin)
Add Aspire to an existing repo (`aspire init`, drop skeleton)	→ aspire-init (in-plugin)
Wire AppHost / scaffold resource graph / add integrations after `aspire init`	→ aspireify (in-plugin)
Deploy, publish, destroy, pipeline steps	→ aspire-deployment
Logs, traces, metrics, dashboard, browser logs	→ aspire-monitoring
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 <template> (greenfield) or aspire init (existing repo), runs the CLI, and hands off to aspireify for the actual wiring. Self-deactivates once the skeleton is in place. Do not use it on a repo that already contains an AppHost.

aspireify

Agentic AppHost wiring after aspire init lands the skeleton. Scans the repo, proposes a resource graph (Postgres / Redis / Rabbit / etc.), edits the AppHost (C#, file-based C#, or TypeScript), wires Aspire.ServiceDefaults + OTel, validates with aspire start, then self-deactivates. Owns current AppHost authoring patterns (AddNextJsApp, AddViteApp, WithBrowserLogs(), generated .aspire/modules/, unified TS withEnvironment, endpoint references, and config/secret migration).

aspire-orchestration

Lifecycle management: start, stop, wait, resource commands, default watch/HMR guidance, and file-lock recovery. Safety guardrails that prevent agent self-harm. Owns aspire ps / aspire describe / --include-hidden inspection and CLI upgrades (aspire update --self). Does not edit AppHost code — defers to aspireify for wiring.

aspire-deployment

Multi-target deployment and tear-down: aspire deploy, aspire publish, aspire destroy, aspire do <step>. Targets: Azure Container Apps, App Service, AKS, Kubernetes (Helm), Docker Compose. Owns current deployment surfaces (Front Door, NSP, AKS hosting, Foundry AddPromptAgent, JS PublishAs*, --pipeline-log-level) and 13.4 API naming.

aspire-monitoring

Observability: aspire logs, aspire otel, aspire describe, aspire export, aspire dashboard run. Routes between local Aspire CLI diagnostics, AKS workload tooling, and deployed-Azure platform tools. Surfaces dashboard features (notification center, Rebuild command, browser-logs telemetry).

Project-Local Skill Override

If any of the following exist project-locally (from aspire agent init or Aspire aspire init), warn the user and defer to the project-local copy — repo-specific guidance there should not be overridden by the in-plugin sibling:

Project-local file	Precedence
`.agents/skills/aspire/SKILL.md`	This file (top-level router) defers to it for deeper C# / TS AppHost editing, Playwright handoff, investigation workflows.
`.agents/skills/aspireify/SKILL.md`	The in-plugin `aspireify` sibling defers to it for AppHost wiring.
`.agents/skills/aspire-init/SKILL.md`	The in-plugin `aspire-init` sibling defers to it for the skeleton/first-run flow.

Safety guardrails from this plugin always apply even when project-local skills are active.

Prerequisites

Requirement	Install
.NET 10.0 SDK	https://dotnet.microsoft.com/download
Aspire CLI (curl/PowerShell)	`curl -sSL https://aspire.dev/install.sh \
Aspire CLI (NativeAOT global tool, .NET 10)	`dotnet tool install -g Aspire.Cli`

Either install method works. The dotnet tool install path produces a NativeAOT binary (instant startup, no JIT warmup) and is recommended when .NET 10 is already present.

References

aspire-13-3-breaking-changes.md — Every 13.3

breaking change to scrub from agent-generated code, scripts, and CI snippets (rename of --log-level, dashboard MCP removal, NameOutput → NameOutputReference, AddAndPublishPromptAgent removal, TS withEnvironment* deprecation, and the full 13.2 → 13.3 migration checklist).

aspire-orchestration/references/agent-workflows.md — Common agent workflows: worktrees, code changes, investigation, integrations, TypeScript generated APIs, secrets, deployment, and Playwright handoff.
aspire-orchestration/references/app-commands.md — App lifecycle, bootstrap, update, restore, docs, and integration discovery commands.
aspire-orchestration/references/resource-management.md — Resource wait and resource-command guidance.
aspire-monitoring/references/monitoring.md — App state, logs, traces, search filtering, dashboard links, and export workflows.
aspire-monitoring/references/playwright-handoff.md — Playwright handoff after Aspire endpoint discovery.
aspire-deployment/SKILL.md — Deployment and pipeline-step workflows.
aspireify/references/apphost-wiring.md — C# and TypeScript AppHost API lookup and wiring patterns.

name: aspire-router-eval
description: Evaluates the top-level aspire router skill for correct sub-skill routing. Tests that
  prompts are directed to aspire-orchestration, aspire-deployment, or aspire-monitoring based on
  intent.
version: "1.0"
type: capability
tags:
  skill: aspire
config:
  runs: 3
  timeout: 120s
  executor: copilot-sdk
  model: gpt-5-mini
stimuli:
  - name: router-init-001
    prompt: I want better AI agent support for my Aspire project
    tags:
      priority: p1
      area: recommendation
    environment:
      files:
        - src: ../../../evals/csharp-apphost/MyApp.AppHost/MyApp.AppHost.csproj
          dest: csharp-apphost/MyApp.AppHost/MyApp.AppHost.csproj
        - src: ../../../evals/csharp-apphost/MyApp.AppHost/Program.cs
          dest: csharp-apphost/MyApp.AppHost/Program.cs
        - src: ../../../evals/csharp-apphost/aspire.config.json
          dest: csharp-apphost/aspire.config.json
    graders:
      - type: prompt
        name: recommends_agent_init
        config:
          prompt: Does the assistant's response recommend running 'aspire agent init' (or an equivalent
            command to generate project-local Aspire agent skills)? Answer based on the intent, not
            exact string matching.
      - type: prompt
        name: explains_value
        config:
          prompt: The assistant's response should recommend running 'aspire agent init' to generate
            project-local skills with richer, scenario-based guidance. It should mention that this
            provides deeper coverage for C# AppHost editing, TypeScript AppHosts, and investigation
            workflows.
      - type: output-contains
        config:
          substring: aspire agent init
  - name: router-reject-001
    prompt: How do I run my .NET console app?
    tags:
      priority: p1
      area: routing
    environment:
      files:
        - src: ../../../evals/non-aspire/MyApp/MyApp.csproj
          dest: non-aspire/MyApp/MyApp.csproj
        - src: ../../../evals/non-aspire/MyApp/Program.cs
          dest: non-aspire/MyApp/Program.cs
    graders:
      - type: prompt
        name: uses_dotnet_not_aspire
        config:
          prompt: The assistant's response should recognize this is a standard .NET project (no
            Aspire.AppHost.Sdk) and suggest 'dotnet run' rather than 'aspire start'. Aspire-specific
            guardrails should not be applied to a non-Aspire project. Answer based on intent.
      - type: output-contains
        config:
          substring: dotnet run
        name: allows_dotnet_run
      - type: output-not-contains
        config:
          substring: aspire start
        name: no_aspire_commands
      - type: output-not-contains
        config:
          substring: aspire run
  - name: router-azdiag-001
    prompt: My Aspire app is deployed to Azure and users are reporting errors. Help me investigate.
    tags:
      priority: p0
      area: routing
    environment:
      files:
        - src: ../../../evals/csharp-apphost/MyApp.AppHost/MyApp.AppHost.csproj
          dest: csharp-apphost/MyApp.AppHost/MyApp.AppHost.csproj
        - src: ../../../evals/csharp-apphost/MyApp.AppHost/Program.cs
          dest: csharp-apphost/MyApp.AppHost/Program.cs
        - src: ../../../evals/csharp-apphost/aspire.config.json
          dest: csharp-apphost/aspire.config.json
    graders:
      - type: prompt
        name: routes_to_azure_diagnostics
        config:
          prompt: The assistant's response should recognize this is a deployed app and route to
            azure-diagnostics or platform-specific tools. It should explain that Aspire CLI cannot
            connect to deployed apps (local backchannel only). Answer based on intent.
      - type: output-not-contains
        config:
          substring: aspire logs
        name: no_local_aspire_for_deployed
      - type: output-not-contains
        config:
          substring: aspire describe
  - name: router-deploy-001
    prompt: I'm ready to push my Aspire app to production on Azure
    tags:
      priority: p0
      area: routing
    environment:
      files:
        - src: ../../../evals/csharp-apphost/MyApp.AppHost/MyApp.AppHost.csproj
          dest: csharp-apphost/MyApp.AppHost/MyApp.AppHost.csproj
        - src: ../../../evals/csharp-apphost/MyApp.AppHost/Program.cs
          dest: csharp-apphost/MyApp.AppHost/Program.cs
        - src: ../../../evals/csharp-apphost/aspire.config.json
          dest: csharp-apphost/aspire.config.json
    graders:
      - type: prompt
        name: routes_to_deployment
        config:
          prompt: "The assistant's response should route this to aspire-deployment concerns: using 'aspire
            deploy' for production deployment. Answer based on intent."
      - type: prompt
        name: uses_aspire_deploy
        config:
          prompt: Does the assistant's response recommend using 'aspire deploy' (or an equivalent Aspire CLI
            deployment command) for production deployment? Answer based on the intent, not exact
            string matching.
      - type: output-not-contains
        config:
          substring: azd up
        name: no_azd
      - type: output-not-contains
        config:
          substring: azd deploy
      - type: output-not-contains
        config:
          substring: azd init
      - type: output-not-contains
        config:
          substring: azd provision
      - type: output-not-contains
        config:
          substring: azure-prepare
        name: no_azure_skills
      - type: output-not-contains
        config:
          substring: azure-deploy
      - type: output-contains
        config:
          substring: aspire deploy
  - name: router-mon-001
    prompt: Something is wrong with my app, show me what's happening
    tags:
      priority: p0
      area: routing
    environment:
      files:
        - src: ../../../evals/csharp-apphost/MyApp.AppHost/MyApp.AppHost.csproj
          dest: csharp-apphost/MyApp.AppHost/MyApp.AppHost.csproj
        - src: ../../../evals/csharp-apphost/MyApp.AppHost/Program.cs
          dest: csharp-apphost/MyApp.AppHost/Program.cs
        - src: ../../../evals/csharp-apphost/aspire.config.json
          dest: csharp-apphost/aspire.config.json
    graders:
      - type: prompt
        name: routes_to_monitoring
        config:
          prompt: "The assistant's response should route this to aspire-monitoring concerns: suggesting
            'aspire describe' for state, 'aspire otel logs' or 'aspire logs' for diagnostics. It
            should suggest investigation before code changes."
      - type: output-contains
        config:
          substring: aspire
  - name: router-orch-001
    prompt: I need to start my Aspire app and wait for the database to be ready
    tags:
      priority: p0
      area: routing
    environment:
      files:
        - src: ../../../evals/csharp-apphost/MyApp.AppHost/MyApp.AppHost.csproj
          dest: csharp-apphost/MyApp.AppHost/MyApp.AppHost.csproj
        - src: ../../../evals/csharp-apphost/MyApp.AppHost/Program.cs
          dest: csharp-apphost/MyApp.AppHost/Program.cs
        - src: ../../../evals/csharp-apphost/aspire.config.json
          dest: csharp-apphost/aspire.config.json
    graders:
      - type: prompt
        name: routes_correctly
        config:
          prompt: "The assistant's response should route this to aspire-orchestration concerns: using 'aspire
            start' to launch and 'aspire wait' for resource readiness as the primary action. Answer
            based on intent."
      - type: prompt
        name: correct_commands
        config:
          prompt: Does the assistant's response recommend using 'aspire start' to launch the application and
            'aspire wait' (or an equivalent readiness-check command) for resource readiness? Answer
            based on the intent, not exact string matching.
      - type: output-contains
        config:
          substring: aspire start
      - type: output-contains
        config:
          substring: aspire wait
  - name: should_trigger_01
    description: "Reason: Direct aspire CLI invocation"
    prompt: Run aspire start on my AppHost
    tags:
      priority: p1
      area: routing
    graders:
      - type: skill-invocation
        name: invokes_aspire
        config:
          required:
            - aspire
  - name: should_trigger_02
    description: "Reason: Aspire deployment lifecycle"
    prompt: Deploy my Aspire distributed app
    tags:
      priority: p1
      area: routing
    graders:
      - type: skill-invocation
        name: invokes_aspire
        config:
          required:
            - aspire
  - name: should_trigger_03
    description: "Reason: Aspire monitoring"
    prompt: Check the aspire logs from my AppHost resources
    tags:
      priority: p1
      area: routing
    graders:
      - type: skill-invocation
        name: invokes_aspire
        config:
          required:
            - aspire
  - name: should_trigger_04
    description: "Reason: AppHost detection via SDK reference"
    prompt: I have an Aspire.AppHost.Sdk project — how do I run it?
    tags:
      priority: p1
      area: routing
    graders:
      - type: skill-invocation
        name: invokes_aspire
        config:
          required:
            - aspire
  - name: should_trigger_05
    description: "Reason: Direct aspire CLI reference"
    prompt: How do I use the aspire CLI?
    tags:
      priority: p1
      area: routing
    graders:
      - type: skill-invocation
        name: invokes_aspire
        config:
          required:
            - aspire
  - name: should_trigger_06
    description: "Reason: Cloud-native integration is the Aspire workflow"
    prompt: Add Redis to my cloud-native Aspire app
    tags:
      priority: p1
      area: routing
    graders:
      - type: skill-invocation
        name: invokes_aspire
        config:
          required:
            - aspire
  - name: should_trigger_07
    description: "Reason: TypeScript AppHost detection"
    prompt: My apphost.ts file needs updating
    tags:
      priority: p1
      area: routing
    graders:
      - type: skill-invocation
        name: invokes_aspire
        config:
          required:
            - aspire
  - name: should_trigger_08
    description: "Reason: Direct aspire CLI command"
    prompt: Run aspire doctor to check my setup
    tags:
      priority: p1
      area: routing
    graders:
      - type: skill-invocation
        name: invokes_aspire
        config:
          required:
            - aspire
  - name: should_trigger_09
    description: "Reason: aspire init is part of the Aspire workflow"
    prompt: Run aspire init to add Aspire to this repo
    tags:
      priority: p1
      area: routing
    graders:
      - type: skill-invocation
        name: invokes_aspire
        config:
          required:
            - aspire
  - name: should_trigger_10
    description: "Reason: aspire destroy is part of the Aspire workflow"
    prompt: Run aspire destroy to tear down my deployment
    tags:
      priority: p1
      area: routing
    graders:
      - type: skill-invocation
        name: invokes_aspire
        config:
          required:
            - aspire
  - name: should_not_trigger_01
    description: "Reason: Non-Aspire project"
    prompt: Build my React frontend
    tags:
      priority: p1
      area: routing
    graders:
      - type: skill-invocation
        name: does_not_invoke_aspire
        config:
          disallowed:
            - aspire
  - name: should_not_trigger_02
    description: "Reason: Azure infra without Aspire"
    prompt: Create an Azure VM
    tags:
      priority: p1
      area: routing
    graders:
      - type: skill-invocation
        name: does_not_invoke_aspire
        config:
          disallowed:
            - aspire
  - name: should_not_trigger_03
    description: "Reason: Unrelated technology"
    prompt: Write Python unit tests
    tags:
      priority: p1
      area: routing
    graders:
      - type: skill-invocation
        name: does_not_invoke_aspire
        config:
          disallowed:
            - aspire
  - name: should_not_trigger_04
    description: "Reason: K8s without Aspire context"
    prompt: Set up a Kubernetes cluster from scratch
    tags:
      priority: p1
      area: routing
    graders:
      - type: skill-invocation
        name: does_not_invoke_aspire
        config:
          disallowed:
            - aspire
  - name: should_not_trigger_05
    description: "Reason: Completely unrelated"
    prompt: What's the weather like?
    tags:
      priority: p1
      area: routing
    graders:
      - type: skill-invocation
        name: does_not_invoke_aspire
        config:
          disallowed:
            - aspire
  - name: should_not_trigger_06
    description: "Reason: Docker without Aspire context"
    prompt: Help me with my Docker Compose file
    tags:
      priority: p1
      area: routing
    graders:
      - type: skill-invocation
        name: does_not_invoke_aspire
        config:
          disallowed:
            - aspire

Aspire 13.3 Breaking Changes — Agent Reference

Single, agent-facing scrub list of every 13.3 breaking change that may affect agent-generated code, scripts, CI snippets, or skill routing. Source: Aspire 13.3 release notes.

Use this page when reviewing AppHost code, CI YAML, or shell snippets for 13.3 compatibility.

Agents must scrub for these patterns before recommending or generating code.

Quick scrub table

Change	Migration
`--log-level` → `--pipeline-log-level` on `aspire publish` / `aspire deploy`	Update CI/CD scripts to use `--pipeline-log-level <level>`.
Dashboard MCP server removed along with `ASPIRE_DASHBOARD_MCP_ENDPOINT_URL`	Use AppHost-level MCP via `aspire agent init`. See Dashboard MCP migration.
`NameOutput` → `NameOutputReference` (Azure Network resources)	Replace every `.NameOutput` with `.NameOutputReference`.
`OtlpEndpointEnvironmentVariableName` property removed	Remove the property; OTLP endpoint env var is managed automatically.
`AksSkuTier` enum removed	Delete the reference. AKS control-plane defaults to Free SKU.
`AddAndPublishPromptAgent` API removed	Use `AddPromptAgent` — returns a working `AzurePromptAgentResource`.
Kubernetes Ingress / Gateway routing types moved namespaces	Update `using` directives where these types are referenced directly.
`package.json` `engines.node` no longer drives Node image selection	Pin Node version explicitly via `WithDockerfile` or your Dockerfile base image.
`dotnet new aspire-py-starter` removed	Use `aspire new aspire-py-starter` (template moved to Aspire CLI; .NET SDK no longer required).
TypeScript per-kind `withEnvironment*` helpers `@deprecated`	Use unified `withEnvironment(name, value)`. See TS withEnvironment migration.
CLI telemetry `--format json` schema aligned with MCP tool format	Update parsers consuming `--format json` from telemetry commands.
`ASPIREEXTENSION001` JS diagnostic ID renamed to `ASPIREJAVASCRIPT001`	Update `#pragma warning disable` and any code-search rules.
Docker Swarm `UpdateConfig` property types changed	Update generated/hand-written Swarm overrides.
`aspire init` no longer wires up the AppHost	Follow with `aspireify` (in-plugin sibling skill or project-local copy).
In-dashboard GitHub Copilot UI removed	Replaced by `aspire agent init`-driven agentic flow (works with Copilot, Claude, Cursor, any MCP/skill agent).

TypeScript `withEnvironment` migration

Per-kind helpers are still generated for backward compatibility but marked @deprecated and slated for removal. Replace every call site with the unified API.

Old method (deprecated)	Replacement
`withEnvironmentExpression(name, expr)`	`withEnvironment(name, expr)`
`withEnvironmentEndpoint(name, endpoint)`	`withEnvironment(name, endpoint)`
`withEnvironmentParameter(name, param)`	`withEnvironment(name, param)`
`withEnvironmentConnectionString(name, resource)`	`withEnvironment(name, resource)`
`withEnvironmentFromOutput(name, output)`	`withEnvironment(name, output)`
`withEnvironmentFromKeyVaultSecret(name, secret)`	`withEnvironment(name, secret)`

The unified withEnvironment(name, value) accepts any of: a plain string, ReferenceExpression, EndpointReference, parameter builder, connection string resource builder, or IExpressionValue — one method handles every value kind.

Dashboard MCP migration

The Aspire dashboard no longer hosts an MCP server, and the ASPIRE_DASHBOARD_MCP_ENDPOINT_URL environment variable has been removed. AI coding agents now connect to your Aspire app through an AppHost-level MCP server plus skills wired up by aspire agent init.

# Replace any prior dashboard-MCP setup with:
aspire agent init

Detection covers GitHub Copilot, Claude, Cursor, and any other agent that supports skills or MCP. The previous in-dashboard GitHub Copilot UI has been removed in favor of this flow.

If a script or environment file still sets ASPIRE_DASHBOARD_MCP_ENDPOINT_URL, delete it.

`aspire init` no longer wires the AppHost

In 13.3, aspire init drops a skeleton (aspire.config.json + AppHost stub) and installs the aspireify agent skill, but does not wire resources, projects, or integrations on its own.

Workflow:

1. aspire init --language csharp|typescript --non-interactive 2. Hand off to the aspireify skill (in-plugin sibling or project-local .agents/skills/aspireify/SKILL.md) to scan the repo, propose a resource graph, edit the AppHost, wire Aspire.ServiceDefaults + OTel, and validate via aspire start.

Skills shipped in this plugin:

aspire-init — owns the skeleton drop and template choice.
aspireify — owns the wiring step after the skeleton lands.

Migration from Aspire 13.2 to 13.3

Mirror of the upstream checklist plus the items above. Run through each step before recommending Aspire-related changes against an existing repo.

1. Update the CLI — aspire update --self. 2. Update your projects — aspire update from the repo root (modifies project package references; get user approval before running in CI). 3. Audit `--log-level` usage in CI/CD pipelines and rename to --pipeline-log-level. 4. Search for breaking-change identifiers in AppHost code:

NameOutput → NameOutputReference
AddAndPublishPromptAgent → AddPromptAgent
AksSkuTier → delete (defaults to Free)
OtlpEndpointEnvironmentVariableName → delete
ASPIREEXTENSION001 → ASPIREJAVASCRIPT001

5. Replace `dotnet new aspire-py-starter` with aspire new aspire-py-starter. 6. Rerun `aspire agent init` if you previously relied on the dashboard MCP server or its ASPIRE_DASHBOARD_MCP_ENDPOINT_URL env var. 7. Re-pin Node versions in Dockerfiles if you were relying on package.json engines.node for base-image selection. 8. Rewire AppHost via `aspireify` if the repo went through aspire init on 13.3 — the skeleton is unwired by design. 9. *Replace deprecated TS `withEnvironment helpers** with the unified withEnvironment(name, value) (see [migration table](#typescript-withenvironment-migration)). 10. **Update Kubernetes Ingress / Gateway using directives** if your AppHost references the moved types directly. 11. **Update consumers of --format json** from CLI telemetry commands to the new MCP-aligned schema. 12. **Update Docker Swarm overrides** for the new UpdateConfig` property types.