/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 | `orleans` | | razor component, web component | `razorcomponent` | | razor class library | `razorclasslib` | | gitignore / editorconfig / nuget config / global json | `gitignore` / `editorconfig` / `nugetconfig` / `globaljson` |

**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