Use Aspire Skills so the agent follows the official CLI

Who it's for

This fits people building Aspire distributed apps who want the agent to recognize the workspace first, then use the Aspire CLI correctly. The official repository is

https://github.com/microsoft/aspire-skills

It writes Aspire Skills as a plugin, skill pack, and extension pack for this kind of work. It wants the agent to route common work to dedicated skills instead of improvising dotnet, curl, Docker, or shell. The material does not say which agent product you must use, so do not invent a client list.

It fits recognition, orchestration viewing, and diagnosis first, not publishing on the first move. In the material, aspire-deployment Publishes, deploys, and tears down Aspire apps. Do not take that path on the first try.

First try in 3 minutes

The main path uses the official Aspire CLI, and at the prompt you choose to attach agent guidance. For an existing workspace use this:

aspire agent init

The material also writes aspire new (create an app and choose guidance at the prompt) and aspire init (add an Aspire skeleton to an existing repo and choose guidance at the prompt). The first try prefers aspire agent init, because it is Add, update, or reconfigure Aspire guidance in an existing workspace. Prerequisite: this machine can already run the Aspire CLI, and the current directory is an Aspire workspace you allow to be rewritten. The material does not write the CLI installer package name or a version number.

Side effect: it writes or updates guidance config in the workspace. Confirm the directory before running. After it runs, first see whether the agent can recognize Aspire workspaces, then decide whether to start resources. Do not deploy or tear down in this step.

Low-risk task: let the top-level aspire routing skill do a read-only check only, for example whether the workspace is recognized and whether the CLI is called correctly. If you must touch a running app, use only aspire-monitoring to look at logs, traces, dashboard, telemetry, or diagnostics; do not call aspire-deployment. Success signal: the agent no longer switches to improvised dotnet / curl / Docker / shell to finish these Aspire tasks. If the CLI is missing, stop at “this machine has no Aspire CLI”; do not finish the first try with another installer.

Use cases

Case 1: Attach or update guidance on an existing workspace. This matches aspire agent init and recognize Aspire workspaces. This fits people whose repo already exists and who only want the agent to work the Aspire way. The material does not write prompt copy or which files were generated; the checkable fact is that an existing workspace can update guidance. Do not write case 1 as already deployed to the cloud.

Case 2: After orchestration, do monitoring and diagnosis. This matches aspire-orchestration (Starts, stops, waits for, and manages Aspire resources) and aspire-monitoring (Routes logs, traces, dashboard, telemetry, and diagnostics work). This fits people whose resources are already up and who only want logs or the dashboard. The material does not write a dashboard URL or alert rules; monitoring should go through that skill, not an improvised curl. Starting/stopping resources has side effects; confirm the environment allows it before running.

Boundaries

aspire-init Creates a new Aspire project or adds an Aspire skeleton to an existing repo; aspireify Wires an AppHost after aspire init. These change repository structure; do not treat them as a read-only check. aspire-deployment includes teardown and needs extra confirmation. The material also shows npx skills add microsoft/aspire-skills and a set of /plugin commands; those are other entry points. Do not mix them with the Aspire CLI into one main path on the first try, and do not infer that one client owns it exclusively.