aspire — Claude Code skill: what it does, how to install
Guides .NET Aspire setup for local service orchestration, resource wiring, and service discovery. Use it when working with AppHost or shared service defaults.
npx skills add codewithmukesh/dotnet-claude-kit --skill aspire -a claude-codeWhat aspire does
This skill guides AppHost configuration for starting application projects alongside PostgreSQL, Redis, and RabbitMQ. It covers AddProject, WithReference, and Aspire integrations that pass connection details and connect resources to services.
It also covers a ServiceDefaults project for OpenTelemetry, health checks, service discovery, and standard HTTP client resilience. For local tracing, logs, and metrics, it points to the Aspire dashboard.
AppHost is a development and build-time tool, not a production process. Deployment should use assets from aspire publish or aspire deploy, so running AppHost in production is a reason to review the delivery setup.
What it helps with
- configure AppHost for multiple .NET services
- wire PostgreSQL, Redis, or RabbitMQ through Aspire
- connect projects with
WithReference - add shared health checks and telemetry
- set up service discovery for an HTTP client
Example prompts for the agent
- Set up AppHost for an API, a worker, and PostgreSQL using
AddProjectandWithReference. - Add
ServiceDefaultsto the API project with OpenTelemetry and health checks. - Connect
payment-apitoorder-apithrough Aspire service discovery.
How to install aspire
1Skills CLI (Vercel)
npx skills add codewithmukesh/dotnet-claude-kit --skill aspire -a claude-code2Manually: put the files in place
~/.claude/skills/aspire/SKILL.mdCopy the whole skill folder; for one project use .claude/skills/aspire/
1Skills CLI (Vercel)
npx skills add codewithmukesh/dotnet-claude-kit --skill aspire -a codex2Manually: put the files in place
.agents/skills/aspire/SKILL.mdFor all projects use ~/.agents/skills/
1Skills CLI (Vercel)
npx skills add codewithmukesh/dotnet-claude-kit --skill aspire -a cursor2Manually: put the files in place
.cursor/skills/aspire/SKILL.mdCursor also reads .agents/skills/ and .claude/skills/
1GitHub CLI
gh skill install codewithmukesh/dotnet-claude-kit aspire2Manually: put the files in place
.github/skills/aspire/SKILL.md1Skills CLI (Vercel)
npx skills add codewithmukesh/dotnet-claude-kit --skill aspire -a gemini-cli2Platform CLI
gemini skills install https://github.com/codewithmukesh/dotnet-claude-kit --path skills/aspireManually: put the files in place
.devin/skills/aspire/SKILL.mdThe legacy .windsurf/skills/ path still works
Skills CLI (Vercel)
npx skills add codewithmukesh/dotnet-claude-kit --skill aspire -a opencodeClaude.ai
Zip the folder and upload it in Settings → Capabilities → Skills
Step by step, with commands for each platform: How to install skills in Claude Code: five ways
Questions about aspire
How do I install aspire in Claude Code?
Run npx skills add codewithmukesh/dotnet-claude-kit --skill aspire -a claude-code, then run npx skills add codewithmukesh/dotnet-claude-kit --skill aspire -a claude-code again. The skill file is at ~/.claude/skills/aspire/SKILL.md.
What does aspire do?
The skill guides .NET Aspire work: AppHost configuration, service defaults, resources, service discovery, and the Aspire dashboard. It focuses on local orchestration of multiple services.
Can AppHost be deployed as a production process?
No. AppHost is for development and build time; use assets generated by aspire publish or use aspire deploy for deployment.
Source text
SKILL.md · MIT
---
name: aspire
description: >
.NET Aspire for cloud-native orchestration. Covers AppHost configuration,
service defaults, resource configuration, service discovery, and the Aspire
dashboard.
Load this skill when setting up local development orchestration, service
discovery, or Aspire-managed infrastructure, or when the user mentions
"Aspire", "AppHost", "service defaults", "service discovery", "orchestration",
"Aspire dashboard", "AddProject", "WithReference", or "cloud-native .NET".
---
# .NET Aspire
## Core Principles
1. **AppHost orchestrates; it is never deployed itself** — Aspire's core job is the local development experience: starting services, databases, and message brokers together. Modern Aspire also generates deployment assets (`aspire publish` for docker-compose/Kubernetes manifests, `aspire deploy` for Azure Container Apps) — but the AppHost process itself stays a dev/build-time tool, not a production runtime.
2. **Service defaults are your baseline** — The `ServiceDefaults` project configures OpenTelemetry, health checks, and resilience for all services in one place.
3. **Use Aspire integrations** — Aspire has built-in integrations for PostgreSQL, Redis, RabbitMQ, SQL Server, and more. They handle connection strings, health checks, and tracing automatically.
4. **The dashboard is your observability tool** — Use the Aspire dashboard for local development tracing, logging, and metrics instead of setting up Seq/Grafana locally.
## Patterns
### AppHost Configuration
```csharp
// AppHost/Program.cs
var builder = DistributedApplication.CreateBuilder(args);
// Infrastructure resources
var postgres = builder.AddPostgres("postgres")
.WithPgAdmin()
.AddDatabase("myappdb");
var redis = builder.AddRedis("redis")
.WithRedisInsight();
var rabbitmq = builder.AddRabbitMQ("messaging")
.WithManagementPlugin();
// Application projects
var api = builder.AddProject<Projects.MyApp_Api>("api")
.WithReference(postgres)
.WithReference(redis)
.WithReference(rabbitmq)
.WithExternalHttpEndpoints();
var worker = builder.AddProject<Projects.MyApp_Worker>("worker")
.WithReference(postgres)
.WithReference(rabbitmq);
builder.Build().Run();
```
### Service Defaults
```csharp
// ServiceDefaults/Extensions.cs — Standard Aspire service defaults
// Configures OpenTelemetry (metrics + tracing), health checks, service discovery, and resilience
public static class Extensions
{
public static IHostApplicationBuilder AddServiceDefaults(this IHostApplicationBuilder builder)
{
builder.ConfigureOpenTelemetry();
builder.AddDefaultHealthChecks();
builder.Services.AddServiceDiscovery();
builder.Services.ConfigureHttpClientDefaults(http =>
{
http.AddStandardResilienceHandler();
http.AddServiceDiscovery();
});
return builder;
}
// ConfigureOpenTelemetry: adds logging, metrics (ASP.NET, HttpClient, Runtime),
// tracing (ASP.NET, HttpClient, EF Core), and OTLP exporter if configured
// AddDefaultHealthChecks: adds a "self" liveness check tagged ["live"]
}
```
### Using Service Defaults in a Project
```csharp
// MyApp.Api/Program.cs
var builder = WebApplication.CreateBuilder(args);
builder.AddServiceDefaults();
// Add Aspire integrations
builder.AddNpgsqlDbContext<AppDbContext>("myappdb");
builder.AddRedisDistributedCache("redis");
var app = builder.Build();
app.MapDefaultEndpoints(); // health check endpoints
app.Run();
```
### Service-to-Service Communication
```csharp
// AppHost — configure service references
var orderApi = builder.AddProject<Projects.OrderApi>("order-api");
var paymentApi = builder.AddProject<Projects.PaymentApi>("payment-api")
.WithReference(orderApi); // paymentApi can discover orderApi
// In PaymentApi — use service discovery
builder.Services.AddHttpClient<OrderClient>(client =>
{
client.BaseAddress = new Uri("https+http://order-api");
});
```
### Solution Structure with Aspire
```
MyApp.slnx
├── MyApp.AppHost/ # Aspire orchestrator
│ └── Program.cs
├── MyApp.ServiceDefaults/ # Shared service configuration
│ └── Extensions.cs
├── src/
│ ├── MyApp.Api/ # Web API project
│ └── MyApp.Worker/ # Background worker
└── tests/
└── MyApp.Api.Tests/
```
## Anti-patterns
### Don't Deploy the AppHost Process
```csharp
// BAD — running the AppHost executable in production as an orchestrator
// The AppHost is a dev/build-time tool, not a production runtime
// GOOD — deploy the generated assets, not the AppHost:
// aspire publish → docker-compose / Kubernetes manifests from the app model
// aspire deploy → direct deployment (e.g., Azure Container Apps)
```
### Don't Hardcode Connection Strings with Aspire
```csharp
// BAD — hardcoding connection strings defeats Aspire's purpose
builder.Services.AddDbContext<AppDbContext>(o =>
o.UseNpgsql("Host=localhost;Database=myapp;..."));
// GOOD — use Aspire integration (connection string injected automatically)
builder.AddNpgsqlDbContext<AppDbContext>("myappdb");
```
### Don't Skip Service Defaults
```csharp
// BAD — manually configuring each service
builder.Services.AddOpenTelemetry()...
builder.Services.AddHealthChecks()...
// GOOD — use shared service defaults
builder.AddServiceDefaults();
```
## Decision Guide
| Scenario | Recommendation |
|----------|---------------|
| Local dev with multiple services | Aspire AppHost |
| Single-project local dev | `dotnet run` is fine, Aspire optional |
| Shared service configuration | ServiceDefaults project |
| Database for local dev | Aspire `AddPostgres()` / `AddSqlServer()` |
| Service discovery | Aspire's built-in service discovery |
| Production deployment | `aspire publish` (compose/K8s manifests) or `aspire deploy` (ACA); never the AppHost itself |
| Observability in local dev | Aspire dashboard (auto-configured) |
© codewithmukesh · MIT · codewithmukesh/dotnet-claude-kit