
Aspire Init
- 118 installs
- 76 repo stars
- Updated August 4, 2026
- microsoft/aspire-skills
aspire-init is an agent skill for first-run Aspire scaffolding via aspire new or aspire init with aspireify handoff for wiring.
About
The 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.
- First-run only skill for repos without existing AppHost markers.
- Decision table for aspire new greenfield versus aspire init existing repo.
- Detection gates prevent init when AppHost already present.
- Drops skeleton and aspireify skill but requires aspireify handoff for wiring.
- Handoff rules to orchestration, deployment, and monitoring sibling skills.
Aspire Init by the numbers
- 118 all-time installs (skills.sh)
- +17 installs in the week ending Aug 4, 2026 (Skillselion tracking)
- Ranked #519 of 1,435 DevOps & CI/CD skills by installs in the Skillselion catalog
- Data as of Aug 5, 2026 (Skillselion catalog sync)
aspire-init capabilities & compatibility
- Capabilities
- apphost absence detection gates · aspire new versus aspire init decision workflow · non interactive template and init commands · aspireify skill drop and wiring handoff · sibling skill routing for orchestration and depl
- Works with
- azure · docker · kubernetes
- Use cases
- devops · orchestration
npx skills add https://github.com/microsoft/aspire-skills --skill aspire-initAdd your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| Installs | 118 |
|---|---|
| repo stars | ★ 76 |
| Last updated | August 4, 2026 |
| Repository | microsoft/aspire-skills ↗ |
How do I add Aspire to a repo that has no AppHost yet?
Add Aspire to a repo with aspire new or aspire init, then hand off to aspireify for resource wiring.
Who is it for?
Teams bootstrapping Aspire in new or existing repos before AppHost resource wiring begins.
Skip if: Skip when AppHost already exists, for deploy publish, or for logs and traces monitoring.
When should I use this skill?
User asks aspire init, aspire new, add Aspire to repo, scaffold Aspire, or no AppHost detected.
What you get
AppHost skeleton, aspire.config.json, and aspireify skill drop ready for resource wiring and aspire start validation.
Files
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
| Requirement | Install |
|---|---|
| .NET 10.0 SDK | https://dotnet.microsoft.com/download |
| Aspire CLI (curl installer) | `curl -sSL https://aspire.dev/install.sh \ |
| Aspire CLI (NativeAOT global tool) | dotnet tool install -g Aspire.Cli (.NET 10 required) |
| Diagnose missing prerequisites | aspire doctor |
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:
| Signal | How to Detect | Meaning |
|---|---|---|
| No C# AppHost | No .csproj containing Aspire.AppHost.Sdk | OK to init |
| No file-based AppHost | No apphost.cs with #:sdk Aspire.AppHost.Sdk | OK to init |
| No TypeScript AppHost | No apphost.ts in repo root | OK to init |
| No Aspire config | No aspire.config.json in repo root | OK to init |
| User intent | Explicit "add Aspire", "scaffold Aspire", "aspire init" | OK to 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
| Situation | Command | Why |
|---|---|---|
| Empty directory or brand-new project | aspire new <template> | Generates a full starter solution |
| Existing repo with services to model | aspire init | Drops minimal skeleton + aspire.config.json next to existing code |
| User wants a sample to learn from | aspire new aspire-starter | Includes ApiService + Web + ServiceDefaults |
| User wants the smallest possible scaffold | aspire new aspire-empty (C#) or aspire new aspire-ts-empty (TS) | No resources pre-wired |
| User wants Python services | aspire new aspire-py-starter (TypeScript AppHost drives Python) | Not dotnet new — that template was removed in 13.3 |
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-interactive4. 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-interactive3. aspire init drops:
- The AppHost skeleton (
apphost.cswith#:sdkdirectives, orapphost.tswith 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
After aspire init / aspire new finishes... | Route To |
|---|---|
| Skeleton dropped, resources need wiring | → aspireify skill (in-plugin or project-local) |
| Skeleton dropped, validate it starts | → aspire-orchestration (run aspire start) |
| New project from template, ready to run | → aspire-orchestration |
| User asks to deploy after init | → aspire-deployment |
| User asks for logs/traces after init | → aspire-monitoring |
| Existing AppHost detected — do NOT run init | → aspireify (re-wire) or aspire-orchestration (lifecycle) |
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
| Symptom | Cause | Action |
|---|---|---|
aspire init reports AppHost already exists | Repo already has an AppHost | Stop. Route to aspireify (re-wire) or aspire-orchestration (lifecycle) |
aspire init fails in non-interactive mode without --language | Multiple language paths available | Re-run with --language csharp or --language typescript |
aspire new rejects --output path | Path exists and is non-empty | Use a different --output or empty the directory |
aspire command not found | CLI not installed | dotnet tool install -g Aspire.Cli (.NET 10) or `curl -sSL https://aspire.dev/install.sh \ |
aspire doctor reports missing .NET 10 | SDK missing | Install .NET 10 SDK before retrying |
aspire init succeeded but no aspireify skill installed | Agent skill directory not detected | Run aspire agent init to install aspireify, then continue wiring |
| Skeleton dropped but resources not wired | Expected — aspire init does not wire | Hand off to aspireify |
References
- templates.md —
aspire newtemplates and options - init-workflow.md —
aspire initflow,aspire.config.json
layout, and aspireify handoff
name: aspire-init-eval
description: "Evaluates the aspire-init skill for correct first-run guidance: choosing between
`aspire new` and `aspire init`, dropping the skeleton, handing off to `aspireify` for wiring, and
never re-initializing a repo that already has an AppHost."
version: "1.0"
type: capability
tags:
skill: aspire-init
defaults:
runs: 3
timeout: 120s
executor: copilot-sdk
model: gpt-5-mini
stimuli:
- name: init-cli-install-001
prompt: I tried `aspire init` but it says command not found. How do I install the Aspire CLI?
tags:
priority: p1
area: prerequisites
graders:
- type: prompt
name: suggests_supported_install
config:
prompt: Does the assistant's response suggest at least one of the two supported Aspire CLI install
paths in 13.3? (1) `dotnet tool install -g Aspire.Cli` — the NativeAOT .NET 10 global
tool, OR (2) `curl -sSL https://aspire.dev/install.sh | bash` — the curl installer.
Either is acceptable; ideally the response mentions both and notes that the global-tool
path requires .NET 10.
- type: output-not-contains
config:
substring: dotnet workload install aspire
name: no_obsolete_workload
- type: output-not-contains
config:
substring: dotnet workload install Aspire
- type: prompt
name: mentions_doctor_or_prereqs
config:
prompt: After installing the CLI, does the assistant's response also tell the user how to verify the
install (for example, `aspire doctor`, `aspire --version`, or re-running `aspire init`)?
Light mention is acceptable.
- type: output-contains
config:
substring: Aspire.Cli
- type: output-not-contains
config:
substring: dotnet workload install aspire
- type: output-not-contains
config:
substring: dotnet new aspire-py-starter
name: never_dotnet_new_aspire
- type: output-not-contains
config:
substring: dotnet new aspire-starter
- type: output-not-contains
config:
substring: dotnet workload install aspire
- name: init-skip-001
prompt: Set up Aspire in this project.
tags:
priority: p0
area: safety-guardrail
environment:
files:
- src: ../../../evals/csharp-apphost/MyApp.AppHost/MyApp.AppHost.csproj
dest: csharp-apphost/MyApp.AppHost/MyApp.AppHost.csproj
- src: ../../../evals/csharp-apphost/MyApp.AppHost/Program.cs
dest: csharp-apphost/MyApp.AppHost/Program.cs
- src: ../../../evals/csharp-apphost/aspire.config.json
dest: csharp-apphost/aspire.config.json
graders:
- type: prompt
name: detects_existing_apphost
config:
prompt: The assistant's response should detect that an AppHost already exists in the repo (the
`.csproj` references `Aspire.AppHost.Sdk` and `aspire.config.json` is present) and
explicitly say `aspire init` is NOT needed.
- type: prompt
name: routes_to_correct_skill
config:
prompt: The assistant's response should route the user to either `aspireify` (for adding/changing
resources in the existing AppHost) or `aspire-orchestration` (for starting and managing
the running AppHost).
- type: output-not-contains
config:
substring: Run `aspire init`
name: no_init_or_new
- type: output-not-contains
config:
substring: run aspire init
- type: output-not-contains
config:
substring: run `aspire new`
- type: output-not-contains
config:
substring: aspire init
- type: output-not-contains
config:
substring: aspire new
- type: output-not-contains
config:
substring: dotnet new aspire-py-starter
name: never_dotnet_new_aspire
- type: output-not-contains
config:
substring: dotnet new aspire-starter
- type: output-not-contains
config:
substring: dotnet workload install aspire
- name: init-existing-001
prompt: Add Aspire to this repository so I can orchestrate my Express frontend and .NET API.
tags:
priority: p0
area: core-flow
graders:
- type: prompt
name: runs_aspire_init
config:
prompt: Does the assistant's response recommend running `aspire init` (not `aspire new`) to
bootstrap the existing repository? It should pick init because the repo already contains
services. Answer based on intent, not exact string matching.
- type: prompt
name: hands_off_to_aspireify
config:
prompt: Does the assistant's response explicitly hand off the resource-wiring step to the
`aspireify` skill (or the project-local `aspireify` skill installed by `aspire init`)?
It should make clear that `aspire init` only drops the skeleton plus
`aspire.config.json` and that wiring is `aspireify`'s job.
- type: output-not-contains
config:
substring: dotnet workload install aspire
name: no_obsolete_workload
- type: output-contains
config:
substring: aspire init
- type: output-contains
config:
substring: aspireify
- type: output-not-contains
config:
substring: dotnet workload install aspire
- type: output-not-contains
config:
substring: dotnet new aspire
- type: output-not-contains
config:
substring: dotnet new aspire-py-starter
name: never_dotnet_new_aspire
- type: output-not-contains
config:
substring: dotnet new aspire-starter
- type: output-not-contains
config:
substring: dotnet workload install aspire
- name: init-new-001
prompt: I'm starting a brand-new distributed app from scratch. Scaffold an Aspire starter project
for me.
tags:
priority: p0
area: core-flow
graders:
- type: prompt
name: uses_aspire_new
config:
prompt: Does the assistant's response recommend `aspire new aspire-starter` (or a similar `aspire
new` template) to scaffold a brand-new project? Answer based on intent.
- type: output-not-contains
config:
substring: dotnet new aspire-starter
name: no_dotnet_new_template
- type: output-not-contains
config:
substring: dotnet new aspire-empty
- type: output-not-contains
config:
substring: dotnet new aspire-ts-starter
- type: prompt
name: no_init_for_greenfield
config:
prompt: For a brand-new, empty project, the assistant's response should pick `aspire new` rather
than `aspire init`. The `aspire init` command is for existing repositories that already
contain services. Does the response correctly avoid suggesting `aspire init` for this
greenfield scenario? Answer based on intent.
- type: output-contains
config:
substring: aspire new
- type: output-contains
config:
substring: aspire-starter
- type: output-not-contains
config:
substring: dotnet new aspire
- type: output-not-contains
config:
substring: dotnet workload install aspire
- type: output-not-contains
config:
substring: dotnet new aspire-py-starter
name: never_dotnet_new_aspire
- type: output-not-contains
config:
substring: dotnet new aspire-starter
- type: output-not-contains
config:
substring: dotnet workload install aspire
- name: init-py-001
prompt: Scaffold an Aspire FastAPI + React Python starter, and please include Redis.
tags:
priority: p0
area:
- core-flow
- 13.3-breaking
graders:
- type: prompt
name: uses_aspire_new_py_starter
config:
prompt: Does the assistant's response use `aspire new aspire-py-starter` (the Aspire 13.3 path) and
NOT `dotnet new aspire-py-starter` (which was removed in 13.3)? It should also explain
that the AppHost will be TypeScript and orchestrates the Python service.
- type: prompt
name: includes_redis_flag
config:
prompt: Since the user asked for Redis, the assistant's response should include the
`--use-redis-cache true` template option (or note that this option exists for the
py-starter template).
- type: output-not-contains
config:
substring: dotnet new aspire-py-starter
name: no_dotnet_new
- type: output-not-contains
config:
substring: dotnet new aspire-py
- type: output-contains
config:
substring: aspire new aspire-py-starter
- type: output-contains
config:
substring: --use-redis-cache
- type: output-not-contains
config:
substring: dotnet new aspire-py-starter
- type: output-not-contains
config:
substring: dotnet new aspire-py-starter
name: never_dotnet_new_aspire
- type: output-not-contains
config:
substring: dotnet new aspire-starter
- type: output-not-contains
config:
substring: dotnet workload install aspire
- name: should_trigger_01
description: "Reason: Existing repo without AppHost — first-run init flow"
prompt: Add Aspire to this Express + .NET API repo
tags:
priority: p1
area: routing
graders:
- type: skill-invocation
name: invokes_aspire_init
config:
required:
- aspire-init
- name: should_trigger_02
description: "Reason: Brand-new project — aspire new template selection"
prompt: Scaffold a new Aspire app from scratch
tags:
priority: p1
area: routing
graders:
- type: skill-invocation
name: invokes_aspire_init
config:
required:
- aspire-init
- name: should_trigger_03
description: "Reason: Bootstrap = aspire init/new flow"
prompt: Bootstrap Aspire into this directory
tags:
priority: p1
area: routing
graders:
- type: skill-invocation
name: invokes_aspire_init
config:
required:
- aspire-init
- name: should_trigger_04
description: "Reason: Direct template scaffold request"
prompt: Run aspire new aspire-starter to create a new project
tags:
priority: p1
area: routing
graders:
- type: skill-invocation
name: invokes_aspire_init
config:
required:
- aspire-init
- name: should_trigger_05
description: "Reason: Direct init request on existing repo"
prompt: Run aspire init in this repo
tags:
priority: p1
area: routing
graders:
- type: skill-invocation
name: invokes_aspire_init
config:
required:
- aspire-init
- name: should_trigger_06
description: "Reason: Existing Python repo needing AppHost — aspire init or aspire-py-starter"
prompt: Bootstrap Aspire into my FastAPI project
tags:
priority: p1
area: routing
graders:
- type: skill-invocation
name: invokes_aspire_init
config:
required:
- aspire-init
- name: should_trigger_07
description: "Reason: Greenfield TS AppHost — aspire new aspire-ts-starter"
prompt: Create a new Aspire TypeScript starter app
tags:
priority: p1
area: routing
graders:
- type: skill-invocation
name: invokes_aspire_init
config:
required:
- aspire-init
- name: should_trigger_08
description: "Reason: aspireify is installed via aspire init / aspire agent init — init flow owns it"
prompt: How do I install the aspireify skill via aspire init?
tags:
priority: p1
area: routing
graders:
- type: skill-invocation
name: invokes_aspire_init
config:
required:
- aspire-init
- name: should_not_trigger_01
description: "Reason: App lifecycle routes to aspire-orchestration"
prompt: Start my Aspire app
tags:
priority: p1
area: routing
graders:
- type: skill-invocation
name: does_not_invoke_aspire_init
config:
disallowed:
- aspire-init
- name: should_not_trigger_02
description: "Reason: Deployment routes to aspire-deployment"
prompt: Deploy my Aspire app to Azure
tags:
priority: p1
area: routing
graders:
- type: skill-invocation
name: does_not_invoke_aspire_init
config:
disallowed:
- aspire-init
- name: should_not_trigger_03
description: "Reason: Logs route to aspire-monitoring"
prompt: Show me logs for my Aspire app
tags:
priority: p1
area: routing
graders:
- type: skill-invocation
name: does_not_invoke_aspire_init
config:
disallowed:
- aspire-init
- name: should_not_trigger_04
description: "Reason: Resource wiring on an existing AppHost routes to aspireify, not aspire-init"
prompt: Wire up my existing AppHost with new resources
tags:
priority: p1
area: routing
graders:
- type: skill-invocation
name: does_not_invoke_aspire_init
config:
disallowed:
- aspire-init
- name: should_not_trigger_05
description: "Reason: aspire add on an existing AppHost routes to aspireify"
prompt: Add a Redis integration to my AppHost
tags:
priority: p1
area: routing
graders:
- type: skill-invocation
name: does_not_invoke_aspire_init
config:
disallowed:
- aspire-init
- name: should_not_trigger_06
description: "Reason: Resource lifecycle routes to aspire-orchestration"
prompt: Restart my database resource
tags:
priority: p1
area: routing
graders:
- type: skill-invocation
name: does_not_invoke_aspire_init
config:
disallowed:
- aspire-init
- name: should_not_trigger_07
description: "Reason: aspire wait routes to aspire-orchestration"
prompt: Wait for my API to be ready
tags:
priority: p1
area: routing
graders:
- type: skill-invocation
name: does_not_invoke_aspire_init
config:
disallowed:
- aspire-init
aspire init Workflow
Reference for the aspire init flow on existing repositories. Source: https://aspire.dev/reference/cli/commands/aspire-init/.
What aspire init Does
aspire init initializes Aspire support in an existing repo or workspace. It scaffolds a minimal AppHost skeleton plus an aspire.config.json, then optionally installs the `aspireify` agent skill so the AI coding agent can complete the wiring.
It does not:
- Wire resources, projects, or integrations into the AppHost
- Modify existing project files
- Change the repo's .NET SDK version (
global.jsonis left alone) - Trust the developer certificate (run
aspire certs trustseparately if needed)
Command and Options
aspire init [options]| Option | Purpose |
|---|---|
--language | csharp or typescript. Required in --non-interactive mode if both paths are available |
--channel | stable (default), staging, daily |
--non-interactive | Required for agent execution. Disables prompts and spinners |
--nologo | Suppress startup banner / telemetry notice |
--banner | Show the animated welcome banner |
-l, --log-level | Critical, Debug, Error, Information, None, Trace, Warning |
--wait-for-debugger | Pause until a debugger attaches |
-?, -h, --help | Print help |
What Gets Dropped
C# Path (--language csharp)
- `apphost.cs` — single-file AppHost using
#:sdk Aspire.AppHost.Sdkand#:package
directives. No .csproj is created in the file-based mode.
- `aspire.config.json` at repo root.
TypeScript Path (--language typescript)
- `apphost.ts` at repo root.
- `.aspire/modules/` generated folder (do not edit by hand — regenerate with
aspire add). - `aspire.config.json` at repo root.
aspireify Skill
- A Markdown skill file is installed into the AI agent's skill directory — the same
directory chosen by aspire agent init (e.g., .agents/skills/aspireify/, .github/skills/aspireify/, .claude/skills/aspireify/, or .opencode/skill/aspireify/).
- The skill instructs the agent to scan the repo, propose a resource graph, edit the
AppHost, and validate via aspire start.
aspire.config.json Layout
| Field | Values | Meaning |
|---|---|---|
appHost.language | "csharp" or "typescript/nodejs" | Which AppHost syntax to use |
appHost.path | Path to AppHost file or directory | Where the AppHost lives |
C# has two sub-modes the agent may encounter:
- Single-file —
appHost.pathpoints atapphost.cs(uses#:sdkdirective). - Full project —
appHost.pathpoints at a directory containing a.csprojplus
Program.cs. In solution-backed repos, full project mode lets the AppHost participate in IDE and solution workflows.
End-to-End Sequence
1. Pre-flight — verify no AppHost already exists. If one does, stop and route to aspireify or aspire-orchestration. 2. Run init:
aspire init --language <csharp|typescript> --non-interactive3. Confirm artifacts — apphost.cs (or apphost.ts + .aspire/modules/) and aspire.config.json should be in the repo root. 4. Confirm `aspireify` skill installed — the agent's skill directory contains aspireify/SKILL.md. If missing, run aspire agent init to install it. 5. Hand off to `aspireify` for wiring:
- Scan repo and discover existing projects, services, containers
- Ask the user clarifying questions (which services to orchestrate, hardcoded ports,
whether to map env vars or switch to Aspire service discovery)
- Wire resources with
WithReference,WaitFor, endpoints, volumes - Optionally configure OpenTelemetry
- Validate with a smoke-test
aspire start
6. Validate — once aspireify finishes wiring, run aspire start (handled by aspire-orchestration) and confirm resources reach a healthy state.
Project-Local Skill Precedence
aspire init installs aspireify into the project's skill directory when an agent skill location is detected. When a project-local .agents/skills/aspireify/SKILL.md (or equivalent location) is present, defer to it and warn the user — the project-local copy may carry repo-specific guidance.
The same precedence applies to a legacy .agents/skills/aspire-init/SKILL.md from older aspire init runs: warn and defer.
Failure Modes and Recovery
| Symptom | Cause | Recovery |
|---|---|---|
aspire init reports an AppHost already exists | Repo is already an Aspire app | Stop. Route to aspireify or aspire-orchestration |
aspire init fails without --language in --non-interactive | CLI needs the language explicitly when prompts are disabled | Re-run with --language csharp or --language typescript |
Skeleton dropped but no aspireify skill | Agent skill directory not detected during init | Run aspire agent init to install aspireify, then continue |
apphost.cs references a missing #:package | Channel mismatch or transient feed issue | Re-run with --channel stable (or daily for pre-release) |
aspire start after wiring fails immediately | Wiring incomplete or wrong AppHost path | Re-invoke aspireify; confirm aspire.config.json appHost.path is correct |
Don't Do This
- Don't run `aspire init` if any AppHost signal already exists — it duplicates the
skeleton and confuses subsequent tooling.
- Don't edit `.aspire/modules/` in TypeScript AppHosts. Use
aspire addto regenerate APIs;
use aspire restore if files are missing.
- Don't install the obsolete Aspire workload (
dotnet workload install aspire). Use
aspire init, aspire new, or aspire add instead.
- Don't perform the resource wiring inside this skill. Hand off to
aspireify. This
skill's job ends when the skeleton + aspire.config.json + aspireify skill are in place.
aspire new Templates
Reference for choosing and invoking templates with aspire new. Source: https://aspire.dev/reference/cli/commands/aspire-new/
Template List
| Template | Description | AppHost Language |
|---|---|---|
aspire-starter | Starter App (ASP.NET Core / Blazor) | C# |
aspire-ts-cs-starter | Starter App (ASP.NET Core / React) | C# |
aspire-py-starter | Starter App (FastAPI / React) | TypeScript (drives Python) |
aspire-ts-starter | Starter App (Express / React) | TypeScript |
aspire-empty | Minimal scaffold, no resources pre-wired | C# |
aspire-ts-empty | Minimal scaffold, no resources pre-wired | TypeScript |
Important — Python starter changed in 13.3. dotnet new aspire-py-starter was removed.The current path is aspire new aspire-py-starter, and the AppHost is TypeScript, notC#. The TypeScript AppHost orchestrates the FastAPI service plus the React frontend.
Common Options
| Option | Purpose |
|---|---|
-n, --name | Name of the project to create |
-o, --output | Output path. Defaults to ./<template-name> (auto-suffixed if non-empty) |
-s, --source | NuGet source for the project templates |
-v, --version | Version of the project templates to use |
--channel | Template channel: stable (default), staging, daily |
--non-interactive | Required for agent execution. Disables prompts and spinners |
--nologo | Suppress startup banner / telemetry notice |
--suppress-agent-init | Skip the post-create prompt to configure AI agent environments |
-l, --log-level | Critical, Debug, Error, Information, None, Trace, Warning |
Template-Specific Options
aspire-py-starter
| Option | Values | Default |
|---|---|---|
--use-redis-cache | true / false | Prompts interactively |
aspire new aspire-py-starter --use-redis-cache true --non-interactiveInteractive Prompts (avoid by passing flags)
| Prompt | What It Decides | Skip With |
|---|---|---|
| Project name | Output directory name | --name <value> |
| Template version | Which release to use | --version <value> |
| Output folder | Where files land | --output <value> |
Use *.dev.localhost URLs? | HTTPS subdomain launch profile vs http://localhost:<port> | Pass --non-interactive to take the default (No, standard localhost) |
If a project picks *.dev.localhost, the user must trust the developer certificate first:
aspire certs trustOutput Path Validation
- Invalid characters (e.g., null bytes) are rejected with an error.
- Existing non-empty directories are rejected — pick a new
--outputor empty the target. - When
--outputis omitted, the CLI derives the directory from the template name and
appends a numeric suffix (./aspire-starter-2, ./aspire-starter-3, ...) if the default already exists.
Examples
# Interactive — CLI prompts for name, output, version
aspire new aspire-starter
# Non-interactive C# empty scaffold pinned to a specific version
aspire new aspire-empty --version <version> --name aspireapp --output ./dev --non-interactive
# Pre-release templates from the daily channel
aspire new aspire-starter --channel daily
# TypeScript-AppHost-driven Python starter with Redis cache
aspire new aspire-py-starter --use-redis-cache true --name py-shop --output ./py-shop --non-interactiveWhen aspire new Is Wrong
| Situation | Use Instead |
|---|---|
| Repo already contains services to model | aspire init (Workflow B in SKILL.md) |
| AppHost already exists in the repo | aspireify (re-wire) or aspire-orchestration (lifecycle) |
| Need to add an integration to an existing AppHost | aspire add <package> (handled by aspire-orchestration) |
Related skills
FAQ
What does aspire-init produce?
AppHost skeleton, aspire.config.json, and aspireify skill installation before resource wiring handoff.
When should I use aspire-init?
When adding Aspire to a workspace with no existing AppHost, config, or apphost files.
Is aspire-init safe to install?
Review the Security Audits panel on this page before installing in production.