aspire-init

name: aspire-init description: >- WORKFLOW SKILL - First-run flow for adding Aspire to a repo. Picks aspire new (greenfield) or aspire init (existing repo), drops the AppHost skeleton, then hands off to aspireify for resource wiring. USE FOR: aspire init, aspire new, aspire-starter, aspire-ts-starter, aspire-py-starter, add Aspire to existing repo, scaffold Aspire app, bootstrap Aspire, no AppHost detected, install aspireify, generated .aspire/modules. DO NOT USE FOR: AppHost wiring on an existing AppHost (use aspireify), start/stop/wait (use aspire-orchestration), deploy/publish (use aspire-deployment), logs/traces (use aspire-monitoring), repo that already has an AppHost. INVOKES: aspire CLI (init, new, doctor), aspireify (handoff after skeleton drop). FOR SINGLE OPERATIONS: Run aspire init or aspire new TEMPLATE directly. license: MIT metadata: author: Microsoft version: "0.0.1"

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 ships the CLI as a NativeAOT .NET global tool — instant startup, no JIT warmup. The curl/PowerShell installer remains supported for environments without .NET 10.

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
   

4. The new directory is fully wired by the template — no aspireify handoff needed.
5. 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
   

3. aspire init drops:
   • The AppHost skeleton (apphost.cs with #:sdk directives, or apphost.ts 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)
4. Hand off to aspireify — aspire init does not wire resources, projects, or integrations on its own.
5. After aspireify finishes wiring, validate via aspire start (aspire-orchestration).

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