aspire-init

Aspire Init

First-run only. This skill owns the skeleton drop and template choice for repositories that do not yet have an Aspire AppHost. Once the skeleton is in place, hand off to `aspireify` for the actual resource wiring.

Prerequisites

Aspire also supports Nix, Homebrew, WinGet, mise, and the curl/PowerShell installers. Use the installation method already owned by the user's environment.

Detection

Activate only when adding Aspire to a workspace that does not yet have one. Confirm ALL of the following before running aspire init:

If any AppHost signal is already present, do not run `aspire init`. Route to `aspireify` (re-wire) or `aspire-orchestration` (lifecycle).

Decision: aspire new vs aspire init

See references/templates.md for the complete template list and options.

Workflow A — aspire new <template> (new project)

For brand-new projects in an empty or non-existent directory:

1. Confirm prerequisites with aspire doctor if the CLI install is uncertain.
2. Pick a template from references/templates.md.
3. Run the template, append --non-interactive for agent flows:

   aspire new aspire-starter --name MyApp --output ./MyApp --non-interactive

1. The new directory is fully wired by the template — no aspireify handoff needed.
2. Route to `aspire-orchestration` for first run

(aspire start).

Workflow B — aspire init (existing repo)

For repositories that already contain services (Express API, .NET API, Python service, etc.) and need an AppHost added alongside them:

1. Verify the Detection table — confirm no AppHost is present.
2. Run aspire init, choosing language explicitly for non-interactive flows:

   aspire init --language csharp --non-interactive
   # or
   aspire init --language typescript --non-interactive

1. aspire init drops:

• The AppHost skeleton (apphost.cs with #:sdk directives, or apphost.mts with the

generated .aspire/modules/ folder)

• AppHost configuration describing language + AppHost path
• The `aspireify` agent skill into the project's skill directory (same one

aspire agent init uses). In 13.6+, the chained agent setup preselects the recommended skills, including aspireify, and does not offer Aspire MCP server configuration. If MCP config is missing after a successful init, that is expected and isn't a defect. MCP is a separate opt-in; see the aspire router's Skills vs. MCP guidance.

1. Hand off to `aspireify` — aspire init does not wire resources, projects, or

integrations on its own.

1. After aspireify finishes wiring, validate via aspire start

(`aspire-orchestration`).

In 13.5, a TypeScript init inside a repo that already has a root package.json creates a nested aspire-apphost/ package and points the root aspire.config.json at aspire-apphost/apphost.mts. A solution-backed C# repo can receive a project-based AppHost; new C# AppHosts enable AspireUseCliBundle=true by default. Preserve these generated choices.

See references/init-workflow.md for the full sequence including what aspire.config.json contains and what to do if aspire init fails partway.

Handoff Rules

Project-Local Skill Override

If .agents/skills/aspire-init/SKILL.md exists project-locally (legacy install from an older aspire init run), warn the user and defer to it. The legacy project-local skill may carry repo-specific guidance that should not be overridden by this in-plugin skill.

The project-local aspireify skill (installed by aspire init) takes precedence over this plugin's in-plugin aspireify for the same reason — defer to the project-local copy and warn.

Error Handling

References

• templates.md — aspire new templates and options
• init-workflow.md — aspire init flow, aspire.config.json

layout, and aspireify handoff

• aspire-13-5-breaking-changes.md —

13.5 migrations, CLI-bundle behavior, and fixes for affected releases