microsoft/aspire-skills
6 skills711 installs444 starsGitHub
Install
npx skills add https://github.com/microsoft/aspire-skillsSkills in this repo
1AspireThe 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.151installs2Aspire MonitoringThe aspire-monitoring skill observes Aspire applications through logs, traces, metrics, resource state, telemetry export, browser telemetry, and the standalone dashboard. It routes between local Aspire CLI commands and deployed platform diagnostics including kubectl for AKS workloads, azure-diagnostics for Azure resources, and docker for Compose containers. Local investigation follows describe resource state, structured aspire otel logs, console aspire logs, distributed traces, and aspire export for zipped telemetry snapshots. Commands cover aspire logs, aspire otel logs, aspire otel traces, aspire otel spans, aspire describe with optional --include-hidden for proxies and helper containers, aspire ps, and aspire dashboard run for OTLP-emitting apps without an AppHost. Agents should use --format Json for machine parsing, retry with --include-hidden when resources are missing, and run aspire dashboard run asynchronously because it blocks until stopped. Browser telemetry from Aspire.Hosting.Browsers surfaces console logs and network data when WithBrowserLogs is wired, while AppHost edits route to aspireify. Handoffs send lifecycle commands to aspire-orchestration, deployment to aspir.124installs3Aspire OrchestrationThe aspire-orchestration skill manages Aspire AppHost lifecycle and recovers from file locks, port conflicts, and orphaned processes using mandatory safety guardrails. Detection fingerprints C# AppHost csproj with Aspire.AppHost.Sdk, file-based apphost.cs, TypeScript apphost.ts, aspire.config.json, and .aspire directories. Default workflow confirms the workspace is Aspire, runs aspire start or aspire start --isolated in git worktrees, waits with aspire wait using displayName from JSON output, inspects via aspire describe, and runs aspire stop to release locks when done. Safety rules forbid dotnet run on AppHost, curl polling instead of aspire wait, and dotnet build against locked files. File-lock errors MSB3491 and CS2012 always resolve with aspire stop before rebuild because Aspire holds bin and obj locks while running. Commands cover aspire ps, resource stop start rebuild, integration list and search, aspire update, aspire doctor, and --format Json for agents. Handoffs route AppHost wiring to aspireify, deployment to aspire-deployment, and logs traces to aspire-monitoring. Agents add --non-interactive and prefer resource commands for single-resource code changes.121installs4AspireifyThe aspireify skill is a one-time wiring workflow that turns an Aspire AppHost skeleton into a working local graph after aspire init. It scans the repository for .NET, Node, and Python services, docker-compose dependencies, connection strings, and integration candidates, then proposes a resource graph before editing. It supports C# SDK-style Program.cs, file-based apphost.cs, and TypeScript apphost.ts hosts while refusing any edits inside generated .aspire/modules files. Guidance follows Aspire 13.4 principles: adapt the AppHost to the app, surface tradeoffs instead of silent decisions, verify APIs with aspire docs search before coding, migrate .env and user secrets into parameters with approval, and optimize local development rather than production deployment. The workflow runs scan, propose, edit, validate with aspire start and aspire wait, then self-deactivates after a clean start. It wires Aspire.ServiceDefaults, OpenTelemetry, health checks, and optional docker-compose migration. Triggers include wire AppHost, scaffold resource graph, add Postgres or Redis to Aspire, or what next after aspire init.112installs5Aspire DeploymentThe aspire-deployment skill publishes, previews, validates, deploys, and tears down Aspire application deployments starting from the AppHost model. It wins routing precedence over generic cloud skills when Aspire markers exist such as AppHost projects, aspire.config.json, or distributed application builder APIs. The workflow orients with aspire ls and aspire describe, clarifies deployment targets including Docker Compose, Kubernetes, Azure Container Apps, App Service, AKS, or AWS, searches aspire docs before editing deployment code, and prefers native aspire publish, aspire deploy, aspire destroy, and aspire do commands. Target-specific references load only for the chosen platform. Agents ask where to deploy when multiple or zero targets exist, confirm before creating billable cloud resources unless deploy-now intent is explicit, and keep Azure paths Aspire-native rather than separate Bicep workflows. Handoffs route missing AppHosts to aspire-init or aspireify and monitoring to aspire-monitoring. Use when deploying Aspire apps, generating Kubernetes or Compose artifacts, publishing to Azure Container Apps, or tearing down deployed resources.102installs6Aspire InitThe aspire-init skill owns the first-run flow for adding Aspire to a repository without an existing AppHost. It chooses aspire new for greenfield projects or aspire init for existing repos with services to model, then hands off to aspireify for resource wiring because init only drops the skeleton. Detection requires no C# AppHost SDK, no file-based apphost.cs, no TypeScript apphost.ts, and no aspire.config.json before running init. Prerequisites include .NET 10 SDK, Aspire CLI via curl installer or dotnet global tool, and aspire doctor for diagnosis. Templates span aspire-starter, aspire-empty, aspire-ts-empty, and aspire-py-starter with non-interactive flags. aspire init drops AppHost skeleton, aspire.config.json, and the aspireify skill into the project skill directory but does not wire resources. Handoff rules route wiring to aspireify, validation to aspire-orchestration with aspire start, deployment to aspire-deployment, and monitoring to aspire-monitoring. If any AppHost signal exists, route to aspireify or aspire-orchestration instead. Use for aspire init, aspire new, bootstrap Aspire, or no AppHost detected scenarios.101installs