Template Comparison Agent Skill

Template Comparison

This skill helps an agent compare 2+ dotnet new templates side by side so the user can

pick the right one. It inspects each template's parameters and feature support and renders

a comparison table.

When to Use

• User is deciding between similar templates (e.g., webapi vs webapp, blazor vs blazorwasm)
• User asks "which template should I use for X?"
• User wants to understand how two or more templates differ before creating a project

When Not to Use

• User wants to create a project — route to template-instantiation
• User wants to author or validate a custom template — route to template-authoring or template-validation
• User just needs to find or inspect a single template — route to template-discovery

Inputs

| Input | Required | Description |

|-------|----------|-------------|

| Template short names | Yes | Two or more template short names to compare (e.g., webapi, webapp) |

| Comparison focus | No | Optional aspect to emphasize (auth, AOT, frameworks, interactivity) |

Workflow

Step 1: Inspect each template

Run dotnet new <template> --help for each template being compared to collect its

parameters (names, types, defaults, choices) and supported frameworks:

dotnet new webapi --help
dotnet new webapp --help

If a template is not installed, find and install it first (dotnet new search <keyword>,

then dotnet new install <package>).

> Run --help calls sequentially. The template engine uses a global mutex, so running

> several dotnet new <template> --help commands concurrently can fail with a transient

> "mutex"/"persistence" error and empty output. Inspect templates one at a time; if a call

> fails, retry it once before moving on, and still produce the comparison from whatever

> parameter knowledge you have rather than ending with no answer.

Step 2: Build the comparison table

Produce a side-by-side table covering:

• Parameters — name, type, default, choices
• Feature support — auth, AOT, Docker, controllers, interactivity
• Available frameworks — e.g., net8.0, net9.0, net10.0
• Classifications — categories the template advertises (Web, API, Blazor, etc.)

Example shape:

| Aspect | webapi | webapp |

|--------|----------|----------|

| Auth (--auth) | None, Individual, SingleOrg, Windows | None, Individual, SingleOrg, ... |

| AOT (--aot flag) | present if dotnet new webapi --help lists --aot | present if dotnet new webapp --help lists --aot |

| Controllers (--use-controllers) | Yes | n/a |

| Interactivity | n/a | n/a |

| Frameworks | net8.0 / net9.0 / net10.0 | net8.0 / net9.0 / net10.0 |

| Classifications | Web, WebAPI | Web, Razor Pages |

Step 3: Recommend

End with a decisive Recommendation line — never leave the user with just a table. Format:

> Recommendation: <template> — one sentence tying the choice to the user's stated scenario. (Pick the other if <condition>.)

Then link to template-instantiation to create it. A comparison that ends without naming a winner (or a clear "it depends on X") is incomplete — that indecision is what makes this skill tie with a plain answer.

Decision shortcuts for common pairs

Use these as the opinionated default when the user hasn't given a countervailing constraint. Still inspect with --help to confirm parameters, but lead with the verdict:

| Pair | Default pick | Because |

|------|-------------|---------|

| webapi vs webapp | webapi for a JSON/REST backend; webapp for server-rendered HTML/Razor Pages | webapi ships controllers/minimal APIs + OpenAPI, no UI |

| blazor vs blazorwasm | blazorwasm when offline / no server is required; blazor (Web App) for flexible server + client interactivity | Standalone WASM runs fully client-side, works offline |

| worker vs console | worker for long-lived/queue/background processing | Generic Host: DI, logging, config, graceful shutdown, IHostedService lifecycle |

| mvc vs webapp | webapp (Razor Pages) for page-focused apps; mvc for controller/view separation at scale | Razor Pages is lighter for CRUD-style pages |

Validation

• [ ] Every template requested was inspected via dotnet new <template> --help
• [ ] The comparison covers parameters, feature support, frameworks, and classifications
• [ ] Differences relevant to the user's scenario are called out explicitly
• [ ] A recommendation (or clear trade-off) is provided

Common Pitfalls

| Pitfall | Solution |

|---------|----------|

| Comparing uninstalled templates from memory | Install and inspect each template so the comparison reflects the real parameters and choices. |

| Assuming feature parity | Parameter names and feature support vary by template — confirm each with --help. |

| Comparing fundamentally different template types | Only compare templates that solve overlapping problems; note when they target different scenarios. |

More Info

• dotnet new templates — built-in template reference
• dotnet new — CLI reference