template-discovery

name	template-discovery
description	Helps find, inspect, and compare (at a high level) .NET project templates. Resolves natural-language project descriptions to ranked template matches with pre-filled parameters. USE FOR: finding the right dotnet new template for a task, inspecting a template's parameters and constraints, understanding what a template produces before creating a project, resolving intent like "web API with auth" to concrete template + parameters. DO NOT USE FOR: actually creating projects (use template-instantiation), authoring custom templates (use template-authoring), producing a detailed side-by-side comparison (use template-comparison), choosing cross-parameter defaults during creation (use template-smart-defaults), MSBuild or build issues (use dotnet-msbuild plugin), NuGet package management unrelated to template packages.
license	MIT

Template Discovery

This skill helps an agent find, inspect, and select the right dotnet new template for a given task using dotnet new CLI commands for search, listing, and parameter inspection.

When to Use

• User asks "What templates are available for X?"
• User describes a project in natural language ("I need a web API with authentication")
• User wants to compare templates or understand parameters before creating a project
• User needs to know what a template produces (files, structure) before committing

When Not to Use

• User wants to create a project — route to template-instantiation skill
• User wants to author or validate a custom template — route to template-authoring skill
• User wants a detailed side-by-side comparison of templates — route to template-comparison skill
• User wants smart cross-parameter defaults during creation — route to template-smart-defaults skill
• User is troubleshooting build issues — route to dotnet-msbuild plugin

Answer first, confirm second — required, in this order. The Step 1 intent → template and keyword → parameter mappings are a complete answer on their own. Your first action is to write a concrete template + parameter recommendation (with a ready-to-run dotnet new command) from the mapping, before you run any dotnet new command. Only then use the CLI to confirm exact names/choices and update the answer. Never make a dotnet new call your final action — the engine's global mutex can make it fail with an empty "persistence"/"mutex" result under load, leaving the user nothing. Always close with the written recommendation, and never end a turn on a "let me confirm from the CLI…" teaser.

Inputs

Input	Required	Description
User intent or keywords	Yes	Natural-language description or keywords (e.g., "web API", "console app", "MAUI")
Language preference	No	C#, F#, or VB — defaults to C#
Framework preference	No	Target framework (e.g., net10.0, net9.0)

Workflow

Do Step 1 and write the recommendation to the user before running Step 2–4 commands. Steps 2–4 only confirm the answer; a dotnet new failure must never leave the turn empty.

Step 1: Resolve intent to template candidates

Map the user's natural-language description to template short names and parameters using these mappings.

Intent → template short name(s):

Intent / phrase	Template short name(s)
web api, web service, rest api, restful, api, minimal api	webapi
web app, web application	webapp, blazorserver
mvc	mvc
razor, razor pages	webapp
blazor, blazor web app	blazor
blazor server	blazorserver
blazor wasm, blazor webassembly	blazorwasm
grpc	grpc
signalr	webapi, webapp
console, console app, command line, cli	console
worker, background service, daemon, windows service	worker
class library, library, lib, nuget package	classlib
maui, mobile, cross-platform app, ios, android	maui
desktop	maui, wpf, winforms
wpf	wpf
winforms, windows forms	winforms
winui, winui3	winui3
test, unit test	xunit, nunit, mstest
xunit / nunit / mstest	xunit / nunit / mstest
solution	sln
aspire, .net aspire	aspire-starter, aspire
azure functions, function app, serverless	func
orleans

Keyword → parameter:

Keyword / phrase	Parameter	Value
authentication, auth, individual auth, individual accounts	--auth	Individual
windows auth	--auth	Windows
azure ad, entra id	--auth	SingleOrg
no auth, no authentication	--auth	None
controllers, with controllers	--use-controllers	(flag)
minimal api	(default)	—
aot, native aot	--aot	(flag)
docker, container	the template's Docker/container option	varies by template — confirm with --help (not all templates expose one)
net8 / .net 8 / dotnet 8	--framework	net8.0
net9 / .net 9 / dotnet 9	--framework	net9.0
net10 / .net 10 / dotnet 10	--framework	net10.0

These are starting guesses. Always confirm the real parameter names/choices with dotnet new <template> --help, because parameter names vary by template (e.g., --auth vs --Authentication).

Some mapped short names are not present in a default SDK install — templates like maui, winui3, aspire-starter/aspire, func, and orleans typically require a workload (dotnet workload install <id>) and/or an additional template package (dotnet new install <package>). If a mapped short name does not appear in dotnet new list, fall back to dotnet new list/dotnet new search to find the right template and the package/workload that provides it before recommending it.

Resilience — always answer, even if the CLI fails. The intent mapping above is a usable answer on its own. Run dotnet new commands sequentially, one at a time — the template engine uses a global mutex, so firing several dotnet new <template> --help/--dry-run calls concurrently can produce a transient "mutex"/"persistence" error and empty output. If a command fails, retry it once; if it still fails, fall back to this intent/parameter mapping and give the user a concrete recommendation, noting that the exact parameter names/choices could not be CLI-confirmed. Never end the turn with no answer because a CLI call errored.

Step 2: Search for templates

Use dotnet new search to find templates by keyword across both locally installed templates and NuGet.org:

dotnet new search blazor

Use dotnet new list to show only installed templates, with optional filters:

dotnet new list --language C# --type project
dotnet new list web

If the user explicitly asks you to check both installed templates and NuGet.org, run and report both searches even when the SDK already includes a suitable template. Distinguish the built-in choice from installable alternatives:

• For an SDK-shipped template, say "no install needed — ships with the SDK" and do not invent a package requirement.
• For each relevant NuGet result you recommend, copy the package ID from the actual search output and give dotnet new install <package-id>.
• If the NuGet search returns no credible alternative, say so explicitly; the local match still answers the request.

Step 3: Inspect template details

Use dotnet new <template> --help to get full parameter details for a specific template — parameter names, types, defaults, and allowed values:

dotnet new webapi --help

Step 4: Preview output

Use dotnet new <template> --dry-run to show what files and directories a template would create without writing anything to disk:

dotnet new webapi --name MyApi --auth Individual --dry-run

If the dry-run fails (transient "mutex"/"persistence" error), retry once; if it still fails, give a representative structure (template family and typical file kinds) and note it isn't CLI-confirmed. Do not invent specific values, choices, or file paths. When the dry-run succeeds, present the actual file list from its output faithfully — don't summarize, regroup, or invent files — and add a one-line purpose for the key entry points (e.g. Program.cs, App.razor).

Step 5: Present findings

Lead with the answer as a ready-to-run command, then justify it. Required shape:

Use <template> — one-line why.

dotnet new <template> --name <Name> [--key params]

Then add supporting detail:

• Key parameters and recommended values (with the choices, e.g. --auth: None | Individual | SingleOrg | Windows)
• What to expect (files created, project structure)
• Any prerequisites — name the exact package to install (dotnet new install <id>), or say "no install needed — ships with the SDK" for a built-in template

An answer without a concrete, copy-pasteable command is what makes this skill tie with a plain reply — always give the command to run next.

Validation

• At least one template match was found for the user's intent
• Template parameters are explained with types and defaults
• User understands what the template produces before proceeding to creation

Common Pitfalls

Pitfall	Solution
Skipping an explicitly requested NuGet search because a local template exists	Run both dotnet new list <keyword> and dotnet new search <keyword>, then distinguish the built-in template from real installable alternatives.
Not searching NuGet when no local template matches	Use dotnet new search <keyword> to find installable templates on NuGet.org.
Not checking template constraints	Some templates require specific SDKs or workloads. Use dotnet new <template> --help to surface constraints before recommending.
Recommending a template without previewing output	Always use dotnet new <template> --dry-run to confirm the template produces what the user expects.
A dotnet new call fails with a "mutex"/"persistence" error and you return nothing	These are transient (often from concurrent invocations). Run dotnet new calls sequentially, retry once, then fall back to the Step 1 intent mapping and still give the user a concrete answer.

More Info

• dotnet new templates — built-in template reference
• Template Engine Wiki — template engine internals