aspire

Overview of aspire skill

What the aspire skill helps you do

The aspire skill is for users who need to create, run, debug, configure, or publish an Aspire-based distributed application without piecing the workflow together from scattered docs. It is most useful when your real job is not “learn Aspire in theory” but “get an AppHost working, wire services correctly, inspect failures, and prepare artifacts for deployment.”

Who should use aspire

Best fit readers are:

• developers evaluating Aspire for local orchestration of multi-service apps
• teams adding an AppHost around existing APIs, containers, or executables
• users who want an AI assistant to help with aspire install, setup, troubleshooting, and deployment-oriented publishing
• polyglot teams mixing .NET AppHost with Python, Node.js, Go, Java, or containerized services

What makes this aspire skill different

This aspire skill is stronger than a generic prompt because it points the agent to the right reference path for the task:

• CLI usage and install details in references/cli-reference.md
• AppHost and runtime concepts in references/architecture.md
• dashboard and observability workflows in references/dashboard.md
• publish-for-target guidance in references/deployment.md
• integration discovery via MCP in references/integrations-catalog.md

That matters because Aspire has a specific mental model: the AppHost defines resources and dependencies, while the runtime and dashboard help you operate them locally.

Core decision point before you install aspire

Use Aspire if you want one code-defined place to orchestrate services, dependencies, endpoints, logs, traces, and publish artifacts for a target platform. Do not choose it expecting direct production deployment from one command: the repo makes clear that Aspire publishes manifests and artifacts, then your CI/CD or platform handles actual deploys.

How to Use aspire skill

Install context for the aspire skill

A practical install path for the aspire skill starts with adding the skill, then using its references as task-specific context:

1. Install the skill:
   npx skills add github/awesome-copilot --skill aspire
2. Open skills/aspire/SKILL.md
3. Load only the reference file that matches your task instead of reading everything

Suggested read order:

• SKILL.md
• references/cli-reference.md
• references/architecture.md
• references/deployment.md
• references/troubleshooting.md

How to install Aspire itself

If your goal is actual Aspire usage, the skill points to the standalone CLI flow:

# Linux / macOS
curl -sSL https://aspire.dev/install.sh | bash

# Windows PowerShell
irm https://aspire.dev/install.ps1 | iex

aspire --version

This is important because the Aspire CLI is a primary interface, not just a side feature of dotnet.

Start with the right task framing

The aspire skill works best when your request includes one of these explicit intents:

• create a new Aspire app
• add an AppHost to an existing solution
• wire a dependency such as Redis or PostgreSQL
• run and debug a local distributed app
• publish Aspire output for Docker or Kubernetes
• troubleshoot startup, health, or service discovery issues

A weak request like “help with Aspire” forces guessing. A stronger request like “set up an AppHost for my API, Redis, and a Python worker, then prepare Docker publish output” gives the agent enough shape to use the right references.

What input the aspire skill needs

For high-quality output, provide:

• your current repo structure
• target languages and runtimes
• whether you already have an AppHost
• local runtime constraints such as Docker or Podman availability
• target publish platform: Docker, Kubernetes, or Azure-oriented output
• observed failure symptoms, if troubleshooting

Useful example input:

I have a .NET API, a React frontend, and a Redis dependency. I want Aspire for local orchestration and Docker publish artifacts. I already use Docker Desktop. Show me the AppHost shape, CLI commands, and likely package choices.

How to turn a rough goal into a strong aspire prompt

A good aspire guide prompt usually includes five parts:

1. current app shape
2. desired resources
3. local run expectations
4. deployment target
5. what format you want back

Example:

Use the aspire skill to propose an AppHost for:
- .NET API in src/Api
- Node frontend in src/Web
- PostgreSQL for local dev
Need:
- service startup order
- endpoint wiring
- environment variable strategy
- Aspire CLI commands
- publish path for Kubernetes
Return code snippets plus a short explanation of tradeoffs.

Repository files to read first for real usage

If you are evaluating the aspire skill for adoption, these files matter most:

• SKILL.md for scope and routing
• references/cli-reference.md for install, aspire new, aspire run, aspire publish, and version-aware commands
• references/deployment.md for the key boundary between publish and deploy
• references/polyglot-apis.md if your services are not all .NET
• references/mcp-server.md if you want assistant-driven inspection and docs lookup
• references/troubleshooting.md if local orchestration fails

This structure is practical: the skill is reference-led, so quality depends on loading the right file, not all files.

How aspire usage works in practice

Typical aspire usage follows this order:

1. create or open the AppHost
2. define resources and references
3. run locally with aspire run
4. inspect resource state, logs, endpoints, and traces in the dashboard
5. iterate on configuration
6. publish artifacts for your deployment target

That workflow is better than jumping straight to deployment because Aspire is opinionated about local orchestration and observability first.

Using aspire for Deployment the right way

For aspire for Deployment, the most important fact is that aspire publish generates deployment artifacts; it does not directly deploy them.

Examples from the references:

aspire publish -p docker -o ./docker-output
aspire publish -p kubernetes -o ./k8s-output

Decision tip:

• choose Aspire if you want your deployment artifacts derived from the same AppHost model you use locally
• do not choose it if you expect a single tool to both define the app and fully manage production rollout

When to use the MCP path

The aspire skill is especially useful with MCP when you want an assistant to inspect a running app or fetch integration docs without manual searching.

references/mcp-server.md shows aspire mcp init, which configures supported AI environments and can create .vscode/mcp.json plus AGENTS.md. This matters for adoption because it reduces the gap between “assistant knows Aspire concepts” and “assistant can see my actual resources, logs, and traces.”

Practical tips that materially improve output

• State whether your workload is a .NET project, container, or executable; Aspire models them differently.
• Mention local runtime availability early. Polyglot apps may need the target language runtime installed even though the AppHost is .NET.
• Ask for startup order and dependency wiring explicitly; this is where AppHost value shows up.
• If deployment is the end goal, ask the agent to separate local orchestration choices from publish-target choices.
• If a command fails, include the full command and observed state from the dashboard or logs, not just “it didn’t work.”

aspire skill FAQ

Is the aspire skill good for beginners

Yes, if you already understand multi-service apps at a basic level. The aspire skill reduces the biggest beginner friction points: which CLI commands matter, what the AppHost is responsible for, where to look for dashboard behavior, and why publish is not the same as deploy.

What is the boundary of the aspire skill

The aspire skill covers local orchestration, AppHost concepts, integrations discovery, MCP setup, dashboard workflows, troubleshooting, and publish-oriented deployment prep. It is not a full replacement for your platform-specific CI/CD, cluster operations, or cloud security design.

How is aspire skill better than a normal prompt

A normal prompt may produce plausible-but-wrong setup advice. The aspire skill is better when you need:

• version-aware CLI guidance
• the correct publish-vs-deploy distinction
• polyglot hosting patterns
• dashboard and troubleshooting paths
• integration discovery via MCP tools

Is aspire only for .NET teams

No. The references explicitly cover polyglot workloads. The AppHost remains .NET-based, but orchestrated services can be containers or executables in other languages. That makes Aspire a fit for mixed stacks, not just pure .NET solutions.

When should I not use aspire

Skip Aspire if:

• you only need a single process app
• your team already has a local orchestration standard that fits well
• you need direct production deployment management rather than generated artifacts
• your environment cannot support the required local runtimes or container tooling

Does aspire install require Docker

Not always, but many practical Aspire workflows benefit from container support. The architecture reference notes containers can run through local runtimes like Docker or Podman, while executables run as native processes. Your exact requirement depends on the resources you plan to orchestrate.

How to Improve aspire skill

Give the aspire skill concrete architecture inputs

The fastest way to improve aspire skill results is to stop asking for abstract examples and provide your real topology:

• service names
• ports or endpoint expectations
• dependency graph
• local runtime constraints
• target publish platform

This leads to better AppHost suggestions, cleaner endpoint wiring, and fewer generic placeholders.

Ask for output in deployable chunks

Instead of “build me an Aspire setup,” ask for:

• AppHost code
• package and template commands
• local run steps
• dashboard verification steps
• publish commands for the target platform

That structure aligns with how Aspire is actually used and makes the output easier to validate.

Use the references folder intentionally

To improve quality, tell the agent which source to ground on:

• “use references/deployment.md for publish choices”
• “use references/polyglot-apis.md for Node and Python hosting options”
• “use references/troubleshooting.md to diagnose failed startup”

This avoids blended answers that confuse architecture, runtime behavior, and deployment.

Common failure mode: confusing local orchestration with production deployment

One of the biggest adoption mistakes is assuming Aspire itself deploys to production. If the first output drifts that way, correct it immediately: ask for publish artifacts, then a separate CI/CD handoff plan. That keeps the aspire guide practical and accurate.

Common failure mode: missing dependency and health assumptions

If services start in the wrong order or fail discovery, ask the agent to explicitly model:

• references between resources
• wait/health behavior
• environment variables derived from dependencies
• external endpoint exposure needs

This is where a vague aspire usage request often underperforms.

Improve troubleshooting by sharing observable evidence

When you want the aspire skill to debug an issue, provide:

• aspire run command used
• dashboard state of each resource
• logs from the failing resource
• whether the failure is startup, connectivity, or publish-related

Observable evidence matters more than a large code dump.

Improve aspire for Deployment outputs with target constraints

For aspire for Deployment, say what your platform expects:

• Docker Compose artifacts
• Kubernetes manifests
• Helm-friendly output
• environment-specific configuration boundaries
• replica or ingress expectations

The deployment reference shows that publish output is target-specific, so your request should be too.

Iterate after the first answer instead of restarting

A strong second-turn prompt is usually:

Revise the Aspire plan using these constraints:
- frontend must stay outside Aspire
- API and worker should run under AppHost
- use PostgreSQL container locally
- produce Kubernetes publish output
- explain what must still be handled by CI/CD

That kind of iteration improves fit much more than asking for a brand-new generic aspire guide.