template-discovery

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

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):

Keyword → parameter:

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

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

More Info

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