AspireCAUTION

An Aspire reference architecture for cloud-native microservices and agentic AI with MCP, A2A & AG-UI

The instruction file, verbatim from the audited commit — this is the text the model reads, and the surface the audit's instruction layer examines. Quoted here so you can judge it without cloning anything.

---
name: aspire
description: >-
  **WORKFLOW SKILL** - Aspire router. Detects AppHosts, enforces guardrails,
  and selects the right sub-skill.
  USE FOR: Aspire AppHost, Aspire CLI, distributed app, cloud-native .NET, aspire
  start/stop/resource/deploy/destroy/publish/init/new/add/wait/describe/ps/logs/otel,
  aspire agent init, WithBrowserLogs, WithTerminal, Interaction Service, apphost.mts,
  TS package managers, Yarn Classic, custom resource commands, .aspire/modules recovery,
  ProjectResource to DotnetProjectResource migration, or Playwright URL discovery.
  DO NOT USE FOR: non-Aspire projects or ordinary build/test tasks.
  INVOKES: aspire-init, aspireify, aspire-project-v2-migration,
  aspire-orchestration, aspire-deployment, aspire-monitoring.
  FOR SINGLE OPERATIONS: Route directly to the matching sub-skill.
license: MIT
metadata:
  author: Microsoft
  version: "0.0.3"
---

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

## Triage first

Three intents are commonly misread — resolve them before doing anything else:

- **"Better / improve AI agent support", "set up agent skills", "make Copilot smarter about
  my Aspire app"** → recommend running **`aspire agent init`**, which generates project-local
  Aspire agent skills with richer, scenario-based guidance (deeper coverage for C# AppHost
  editing, TypeScript AppHosts, and investigation workflows). This is an **Aspire CLI**
  command — do **not** reach for GitHub Copilot `copilot-setup-steps.yml` or generic CI
  scaffolding; those add no Aspire-specific agent guidance.
- **"Something's wrong", "show me what's happening", "why is my app misbehaving"** → observe
  **runtime** state first: route to [aspire-monitoring](https://github.com/microsoft/aspire-skills/blob/main/skills/aspire-monitoring/SKILL.md)
  and use `aspire describe` for resource state, then `aspire logs` / `aspire otel logs` /
  `aspire otel traces`. Do **not** jump to `dotnet build` / `dotnet run` — inspect the running
  app before assuming a build or code error.
- **"My old TypeScript AppHost uses apphost.ts; how do I migrate?"** → route to
  `aspire-orchestration` for `aspire update --migrate`. This entry-point/package
  migration is not Project v2 resource migration. Its package, config, tsconfig,
  generated-import, and entry-point changes require approval before
  `aspire update --migrate --yes --non-interactive`; use `aspireify` only if
  separate source authoring remains afterward.

## 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                      | Current `apphost.mts` or legacy `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`](https://github.com/microsoft/aspire-skills/blob/main/skills/aspire-init/SKILL.md) for the skeleton drop. If an AppHost stub exists
   but is **unwired** (no resources declared), route to [`aspireify`](https://github.com/microsoft/aspire-skills/blob/main/skills/aspireify/SKILL.md).
   Only continue with the steps below once a wired AppHost is present.
1. Confirm workspace is Aspire — identify the AppHost
2. Route lifecycle work to `aspire-orchestration`: prefer `aspire_apphost_start` when the VS Code tool is available; use `aspire start --non-interactive --isolated --apphost <path>` in worktrees
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 ch

CAUTIONgrade B · trust 89/100 Install with care. The audit found things worth knowing before you trust its output.

What the source does

Filesystem

none-observed

Network

none-observed

Shell

none-observed

Dependencies

pinned

Secrets in source

none-found

Findings (1)

| Aspire CLI (curl/PowerShell)                | `curl -sSL https://aspire.dev/install.sh \| bash` |

Gates applied: no_behavioural_pass.