Microsoft Aspire Templates Repo: Six Starters and Two Agent Skills

Microsoft created a public GitHub repository called microsoft/aspire-templates on October 28, 2026. It is the new home for the starter templates that the Aspire team maintains, and it ships something unusual for a templates repo: two agent skills that tell an AI coding agent how to write and how to review a template. As of our check it had zero stars, a handful of commits and an MIT license, so this is a release from a top-lab organization, not a trending story. It still tells you where Aspire, a tool for composing distributed apps, is heading.

If you have not met Aspire, the project site describes it as an "agent-ready, code-first tool for composing, debugging, and deploying distributed applications," free and open source, with AppHosts written in C# or TypeScript and an announcement banner for Aspire 13.6. This post explains what the repo contains, how to try the templates with aspire new, and what the agent-skills angle means.

TL;DR: what is in microsoft/aspire-templates

What are the six templates?

Each directory under templates/ is an independently selectable .NET template-engine source, per the README. The table below reproduces what the README lists.

Two details stand out. First, the TypeScript AppHost is a first-class citizen: three of the six templates use it, and one of those pairs it with a Python FastAPI backend. That matches the Aspire homepage, which shows the same application model in C#, TypeScript and several other languages. Second, the single-file template needs .NET 10 or later, because it relies on file-based apps, and the README says it dropped an upstream dotnetcli-only discovery constraint so the Aspire CLI can find it too.

How do I try a template with aspire new?

The README's "Try a template" section assumes an Aspire CLI build that supports local or Git template sources, host metadata, SDK-version injection and nugetPackageVersion value sources. If you have such a build and a checkout of the repository, you point aspire new at a template directory:

aspire new --template-path ./templates/aspire-py-starter

For unattended generation, which is what you want in CI or inside an agent loop, the README gives this form:

aspire new --template-path ./templates/aspire-py-starter \
  --name MyApp --output ./generated/MyApp \
  --non-interactive --suppress-agent-init --use-config-source false

Note --use-config-source false: per the README it declines any separately configured initialization source, and it "does not disable template sources." The --suppress-agent-init flag is worth noticing too, since it tells the CLI not to run its agent-setup step during generation.

The README also describes a global-source flow that depends on a pending CLI change (microsoft/aspire pull request 21329): aspire template source add aspire-templates --path "$PWD/templates", then aspire new, then choose "Search for more templates." A Git source can use --repository https://github.com/microsoft/aspire-templates --path templates. The README text still says the repository "is currently private" and that local path registration works against an authenticated checkout. The GitHub API now shows it as public, so the README wording appears to predate the visibility change. Either way, it states that neither registration method "establishes trust or verifies provenance."

What are the two agent skills for?

This is the part that connects the repo to the AI-tooling story. The README says "Two repository-local agent skills guide contributions":

• Template creation covers source placement, CLI prompts, SDK and package versions, prereleases, and automated testing.
• Template review "independently checks generated behavior, package policy, and the evidence behind test coverage."

The instruction that follows is the interesting design choice: "Use creation to implement a contribution and review to challenge it before merge." One skill builds, a separate skill attacks. That is a maker and checker split, applied to templates, and it mirrors how teams are starting to use separate agent roles so the same context does not both write and approve a change. The README adds that these skills "describe the current conventions and should evolve with the harness."

If you want the background on skills as a format, read our complete guide to agent skills, and for how the format spread across vendors, see Anthropic donating Agent Skills to the Agentic AI Foundation. Microsoft is also pushing the same pattern on the Azure side, as we covered in the Microsoft FoundryX plugin for GitHub Copilot, which is also a skill-plus-CLI bundle.

How are the templates tested?

The repo is heavier on validation than most template collections, which is the reason to read it even if you never use Aspire. Per the README:

• Generation checks. A C# file-based app, run with dotnet run --file eng/validate-templates.cs, installs templates into a temporary, isolated template-engine hive, renders default and optional variants with synthetic package versions, and checks substitution, prompt metadata, ports, hostnames, selected dependencies and test-framework variants. These checks do not restore dependencies, run applications or contact package feeds.
• A daily matrix. eng/discover-e2e.cs emits a JSON matrix, and the "Validate templates" workflow creates one job per template using the latest daily CLI. Each job installs the CLI, verifies the exact commit under test, runs aspire new against a read-only mount of the template source, restores and builds the app, starts the AppHost, waits for resources to become healthy, and stops it.
• Sandboxed end-to-end runs. The MSTest harness uses Hex1b Docker-backed terminals, up to four cases in parallel locally. Each case gets a fresh privileged Linux container with its own Docker daemon, and the README says the host Docker socket, credentials and package caches are not mounted.

The last point is a good habit for anyone letting an agent generate and run projects: the generated app builds and starts inside a throwaway container, not on your machine. For the broader pattern of running coding agents next to a test-and-deploy loop, see NVIDIA RTX Spark: code, test and deploy on one machine.

What does the metadata do, and what are the caveats?

Every template carries a .template.config/template.json and an aspirecli.host.json (spelled as the CLI expects). The README explains that symbolInfo supplies readable prompt labels and hides internal parameters such as ports, framework defaults and computed versions. The TypeScript AppHosts declare a hidden AspireVersion parameter, and the CLI injects its SDK identity into the generated aspire.config.json as sdk.version.

Package versions resolve independently. Aspire package parameters use host value sources of kind nugetPackageVersion, with versionRange: "*-*", which allows prereleases. The README is candid that "the permissive package ranges are experimental, not a reproducibility or provenance policy," and that future provenance work must define what is authenticated and how versions, source revisions and generated content are bound together.

For a builder, that translates into three cautions:

1. Pin versions after generation. A template that resolves to the newest prerelease at generation time gives you a different project next week. Commit the resolved versions.
2. Treat templates as code you run. Templates execute on your machine through the template engine and CLI. Read what a template adds before you accept it, especially if it comes from a Git source you do not control.
3. Expect churn. The repo has a handful of commits, the README references an unmerged CLI change, and the author-facing skills say they "should evolve." This is early infrastructure.

How does this fit the larger Aspire and agent picture?

The Aspire homepage markets "one connection, full application context" for AI tools such as GitHub Copilot, Claude and OpenAI, and shows aspire run exposing a live resource topology and dashboard. The templates repo is the on-ramp to that: a consistent, tested starting point that an agent or a human can generate, with the right dashboard and telemetry ports preconfigured. Microsoft's wider local-and-cloud agent story is covered in Windows hybrid intelligence, and its compact coding model in MAI-Code-1.1 Flash on Windows.

The practical takeaway for teams: if you maintain internal starter templates, the repo shows a pattern worth copying. Put creation and review conventions in skills next to the templates, test generation in isolation, and run a daily end-to-end matrix against the latest CLI so template drift shows up as a failing job rather than a broken first-run experience.

What to watch next

• Whether the CLI change for global template sources merges, which would make aspire template source add the normal path.
• Whether the README catches up with the repo's public visibility and drops the "currently private" line.
• Whether the Python and TypeScript templates grow beyond the six starters, for example with agent-specific scaffolds.
• Whether Microsoft documents a provenance or signing story for community-contributed templates.

Related reading

• Expo Skills: the official agent skills for Expo and EAS
• Complete guide to agent skills
• Anthropic donates Agent Skills to the Agentic AI Foundation
• Microsoft FoundryX plugin for GitHub Copilot
• Windows hybrid intelligence for local and cloud agents
• MAI-Code-1.1 Flash on Windows
• NVIDIA RTX Spark: code, test and deploy on one machine

Repository details are as of October 28, 2026 and may change as the Aspire team updates the repo.