diff --git a/plugins/dotnet-template-engine/.codex-plugin/plugin.json b/plugins/dotnet-template-engine/.codex-plugin/plugin.json
index 6bfa099d85..fa64bc3587 100644
--- a/plugins/dotnet-template-engine/.codex-plugin/plugin.json
+++ b/plugins/dotnet-template-engine/.codex-plugin/plugin.json
@@ -3,5 +3,5 @@
   "version": "0.1.0",
   "description": ".NET Template Engine skills for dotnet new: create projects (console app, class library, web API, Blazor, MAUI), discover and search templates, inspect template parameters and frameworks (net8.0, net9.0, net10.0), scaffold solutions, author and validate custom templates, install template packages from NuGet.",
   "skills": ["./skills/"],
-    "agents": ["./agents/template-engine.agent.md"]
+  "agents": ["./agents/template-engine.agent.md"]
 }
diff --git a/plugins/dotnet-template-engine/agents/template-engine.agent.md b/plugins/dotnet-template-engine/agents/template-engine.agent.md
index 69776f9200..9fcbd905c3 100644
--- a/plugins/dotnet-template-engine/agents/template-engine.agent.md
+++ b/plugins/dotnet-template-engine/agents/template-engine.agent.md
@@ -37,13 +37,24 @@ Classify the user's request and invoke the appropriate skill:
 | "Create a new project/app/service" | `template-instantiation` skill |
 | "What templates are available for X?" | `template-discovery` skill |
 | "Show me template details/parameters" | `template-discovery` skill (inspect via `dotnet new <template> --help`) |
+| "Compare templates X vs Y" / "which template should I use" | `template-comparison` skill |
+| "Apply smart defaults" / cross-parameter questions during creation | `template-smart-defaults` skill |
 | "Create a template from my project" | `template-authoring` skill |
-| "Validate my custom template" | `template-authoring` skill |
+| "Validate my custom template" / "check my template.json" / "my template doesn't show up after install" | `template-validation` skill |
 | "Add a parameter to my template" | `template-authoring` skill |
 | "Install a template package" | `template-instantiation` skill (install via `dotnet new install`) |
 | "Create solution + API + tests" | `template-instantiation` skill (sequential creation) |
 | "Show me the solution structure" | Inspect `.sln` and `.csproj` files directly |
 
+## Skills Inventory
+
+- `template-discovery` — find, inspect, and select templates from natural-language intent
+- `template-comparison` — compare 2+ templates side by side to help users choose
+- `template-instantiation` — create projects/solutions, manage template packages, adapt to CPM
+- `template-smart-defaults` — apply cross-parameter default rules during creation
+- `template-authoring` — create custom templates from existing projects
+- `template-validation` — validate `template.json` for correctness before publishing
+
 ## Workflow: Creating a Project
 
 When a user asks to create a new project, follow this workflow:
@@ -59,7 +70,7 @@ Ask clarifying questions if needed:
 Map the user's description to a template short name (see template-discovery skill for keyword mappings), or use `dotnet new search` for keyword-based search. Present options if multiple matches exist.
 
 ### 3. Inspect Parameters
-Use `dotnet new <template> --help` to show available parameters and their defaults, types, and choices.
+Use `dotnet new <template> --help` to show available parameters and their defaults, types, and choices. Apply cross-parameter defaults via the `template-smart-defaults` skill (e.g., AOT → latest compatible framework; auth set → don't disable HTTPS) without overriding values the user set explicitly.
 
 ### 4. Analyze Workspace
 Inspect the existing project structure: check for `Directory.Packages.props` (CPM), `global.json`, and existing `.csproj` files to determine framework conventions.
@@ -83,7 +94,7 @@ When a user asks to create a custom template:
 Read the `.csproj` and create a `.template.config/template.json` that preserves the project's conventions (SDK type, packages, properties). Review the generated template.json.
 
 ### 2. Validate
-Review the generated `template.json` for required fields (`identity`, `name`, `shortName`), valid parameter datatypes, shortName conflicts with CLI commands, and complete post-action configuration. Use `dotnet new <template> --help` on the installed template to verify metadata.
+Validate the generated `template.json` with the `template-validation` skill — it owns the full rule set (required fields, identity format, reserved shortName conflicts, parameter datatypes, post-actions, constraints, tags). Then use `dotnet new <template> --help` on the installed template to verify metadata.
 
 ### 3. Refine
 Help the user add parameters, conditional content, post-actions, and constraints.
diff --git a/plugins/dotnet-template-engine/skills/template-authoring/SKILL.md b/plugins/dotnet-template-engine/skills/template-authoring/SKILL.md
index 8a14a04c11..73c1f2d2e6 100644
--- a/plugins/dotnet-template-engine/skills/template-authoring/SKILL.md
+++ b/plugins/dotnet-template-engine/skills/template-authoring/SKILL.md
@@ -46,7 +46,13 @@ Analyze the source `.csproj` and create a `.template.config/template.json`:
 
 1. Create `.template.config` directory next to the project
 2. Generate `template.json` with `identity` (reverse-DNS), `name`, `shortName`, `sourceName` (project name for replacement), `classifications`, and `tags`
-3. Preserve from source: SDK type, package references with metadata (PrivateAssets, IncludeAssets), properties (OutputType, TreatWarningsAsErrors), CPM patterns
+3. Preserve from source — generic `dotnet new` templates frequently get these wrong, so verify each is carried over from the original `.csproj`:
+   1. **SDK type** — `Microsoft.NET.Sdk`, `Microsoft.NET.Sdk.Web`, `Microsoft.NET.Sdk.Worker`, etc.
+   2. **Analyzer/package reference metadata** — `PrivateAssets`, `IncludeAssets`, `ExcludeAssets`
+   3. **`OutputType` and other key properties** — `TreatWarningsAsErrors`, `Nullable`, `LangVersion`
+   4. **CPM participation** — no inline `Version` attributes when a `Directory.Packages.props` is present
+   5. **Custom build props/targets** and `Directory.Build.props` conventions
+   6. **Repo conventions** — folder layout, naming, `global.json` SDK pin
 
 Minimal example:
 ```json
@@ -64,15 +70,12 @@ Minimal example:
 
 ### Step 2: Validate template.json
 
-Read and review the `template.json` for common authoring issues:
+Validate the generated `template.json` using the **template-validation** skill (it owns the full rule set — required fields, identity format, reserved shortName conflicts, parameter datatypes, post-actions, constraints, and tags).
 
-Validation checks to perform:
-- **Required fields** — verify `identity`, `name`, and `shortName` are present
-- **Identity format** — use reverse-DNS format (e.g., `MyOrg.Templates.WebApi`)
-- **Parameter issues** — check datatypes are valid (`string`, `bool`, `choice`, `int`, `float`), choices have defaults, descriptions are present
-- **ShortName conflicts** — avoid names that collide with built-in CLI commands (`build`, `run`, `test`, `publish`). Check with `dotnet new list` to see if the name is already taken
-- **Post-action completeness** — verify post-actions have all required configuration
-- **Tags** — ensure language, type, and classification tags are set for discoverability
+Quick summary of what gets checked:
+- **Required fields** — `identity`, `name`, and `shortName` must be present.
+- **ShortName conflicts** — avoid names that collide with `dotnet new` subcommands. Read the authoritative set from the `Commands:` section of `dotnet new --help` for the installed SDK and do not hardcode it (it can change between versions); illustrative examples from current SDKs are `install`, `uninstall`, `update`, `list`, `search`, `details`, `create`. A conflict happens because `dotnet new <name>` would be parsed as the subcommand of the same name. Top-level `dotnet` verbs like `build`, `run`, `test`, and `publish` do NOT conflict. Run `dotnet new list` to confirm the name is not already taken.
+- **Parameters, post-actions, tags** — see template-validation for the complete rules, including the valid datatype list.
 
 ### Step 3: Refine the template
 
@@ -107,7 +110,7 @@ dotnet build ./test-output/TestProject
 | Pitfall | Solution |
 |---------|----------|
 | Identity format issues | Use reverse-DNS format (e.g., `MyOrg.Templates.WebApi`). Avoid spaces or special characters. |
-| ShortName conflicts with CLI commands | Avoid names like `build`, `run`, `test`, `publish`. Check by running `dotnet new list` to see if the name is already taken. |
+| ShortName conflicts with CLI commands | Avoid names that match a `dotnet new` subcommand; read the live set from `dotnet new --help` and don't hardcode it (illustrative examples: `install`, `uninstall`, `update`, `list`, `search`, `details`, `create`). Top-level verbs like `build`/`run`/`test`/`publish` are fine. Run `dotnet new list` to see if the name is already taken. |
 | Missing parameter descriptions | Every parameter should have a `description` and `displayName` for discoverability. |
 | Not testing all parameter combinations | Use `dotnet new <template> --dry-run` with different parameter values to verify conditional content works correctly. |
 | Hardcoded versions in template | Use `sourceName` replacement for project names and consider parameterizing framework versions. |
diff --git a/plugins/dotnet-template-engine/skills/template-comparison/SKILL.md b/plugins/dotnet-template-engine/skills/template-comparison/SKILL.md
new file mode 100644
index 0000000000..5268c29eeb
--- /dev/null
+++ b/plugins/dotnet-template-engine/skills/template-comparison/SKILL.md
@@ -0,0 +1,104 @@
+---
+name: template-comparison
+description: >
+  Compares two or more dotnet new templates side by side to help users choose between
+  them based on parameters, feature support, frameworks, and classifications.
+  USE FOR: deciding between similar templates (webapi vs webapp, blazor vs
+  blazorwasm, console vs worker), producing a side-by-side comparison of parameters and
+  feature support, understanding how templates differ before creating a project.
+  DO NOT USE FOR: creating a project from a template (use template-instantiation),
+  authoring or validating custom templates (use template-authoring and template-validation),
+  general single-template discovery (use template-discovery).
+license: MIT
+---
+
+# 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:
+
+```bash
+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) | n/a — native AOT via publish-time `PublishAot` | n/a |
+| 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
+
+Summarize the key differences and recommend a template for the user's stated scenario,
+linking to `template-instantiation` to create it.
+
+## 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](https://learn.microsoft.com/dotnet/core/tools/dotnet-new-sdk-templates) — built-in template reference
+- [dotnet new](https://learn.microsoft.com/dotnet/core/tools/dotnet-new) — CLI reference
diff --git a/plugins/dotnet-template-engine/skills/template-discovery/SKILL.md b/plugins/dotnet-template-engine/skills/template-discovery/SKILL.md
index 3475af482b..349246bfeb 100644
--- a/plugins/dotnet-template-engine/skills/template-discovery/SKILL.md
+++ b/plugins/dotnet-template-engine/skills/template-discovery/SKILL.md
@@ -9,7 +9,8 @@ description: >
   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), MSBuild or build issues (use dotnet-msbuild
+  custom templates (use template-authoring), comparing templates side by side in detail
+  (use template-comparison), MSBuild or build issues (use dotnet-msbuild
   plugin), NuGet package management unrelated to template packages.
 license: MIT
 ---
@@ -29,6 +30,7 @@ This skill helps an agent find, inspect, and select the right `dotnet new` templ
 
 - 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 is troubleshooting build issues — route to `dotnet-msbuild` plugin
 
 ## Inputs
@@ -43,19 +45,59 @@ This skill helps an agent find, inspect, and select the right `dotnet new` templ
 
 ### Step 1: Resolve intent to template candidates
 
-Map the user's natural-language description to template short names using these common keyword mappings:
-
-| User Intent | Template | Suggested Parameters |
-|-------------|----------|---------------------|
-| web API, REST API | `webapi` | `--auth Individual --use-controllers` if auth requested |
-| web app, website | `webapp` | |
-| Blazor, interactive web | `blazor` | |
-| console app, CLI tool | `console` | |
-| class library, shared code | `classlib` | |
-| worker service, background job | `worker` | |
-| gRPC service | `grpc` | |
-| MAUI app, mobile app | `maui` | |
-| test project, unit tests | `xunit`, `mstest`, or `nunit` | |
+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, azure ad, entra | `--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
 
@@ -109,6 +151,7 @@ Summarize the best template match with:
 | Not searching NuGet for templates | If `dotnet new list` shows no 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
 
diff --git a/plugins/dotnet-template-engine/skills/template-instantiation/SKILL.md b/plugins/dotnet-template-engine/skills/template-instantiation/SKILL.md
index c66131dc94..fff141c507 100644
--- a/plugins/dotnet-template-engine/skills/template-instantiation/SKILL.md
+++ b/plugins/dotnet-template-engine/skills/template-instantiation/SKILL.md
@@ -84,10 +84,16 @@ dotnet new webapi --name MyApi --output ./src/MyApi --framework net10.0 --auth I
 
 Note: Use `dotnet new <template> --help` to see all available parameters for any template.
 
-After creation, if the workspace uses CPM:
-1. Check `.csproj` for inline `<PackageReference>` versions
-2. Move version attributes to `Directory.Packages.props` as `<PackageVersion>` entries
-3. Remove `Version` attributes from the `.csproj`
+After creation, adapt the project to Central Package Management and refresh stale versions:
+
+1. **Detect CPM** — walk up the directory tree from the new project looking for a `Directory.Packages.props`.
+2. **Strip inline versions** — if found, for each `<PackageReference Include="X" Version="Y" />` the template generated, remove the `Version` attribute from the `.csproj` (leaving `<PackageReference Include="X" />`).
+3. **Centralize the version** — add or merge a `<PackageVersion Include="X" Version="Y" />` entry in `Directory.Packages.props`.
+4. **Optionally refresh stale template-default versions** — templates often hardcode old versions. Keep the template's versions by default (safest for reproducibility and controlled upgrades). Only refresh when the user asks, and when you do:
+   - Prefer a tooling-driven flow: run `dotnet list package --outdated` and confirm the proposed bumps with the user before changing anything.
+   - Constrain upgrades to the same **major** (or major/minor) version unless the user explicitly opts into larger upgrades, since cross-major bumps can introduce breaking changes.
+   - When checking the latest **stable** version of a package conceptually, the NuGet V3 flat-container `index.json` endpoint for that package ID lists published versions; never select a prerelease unless requested.
+5. **Build** — run `dotnet build` to confirm the centralized/refreshed versions resolve.
 
 ### Step 5: Multi-project composition (optional)
 
diff --git a/plugins/dotnet-template-engine/skills/template-smart-defaults/SKILL.md b/plugins/dotnet-template-engine/skills/template-smart-defaults/SKILL.md
new file mode 100644
index 0000000000..5beea109a3
--- /dev/null
+++ b/plugins/dotnet-template-engine/skills/template-smart-defaults/SKILL.md
@@ -0,0 +1,78 @@
+---
+name: template-smart-defaults
+description: >
+  Applies cross-parameter default rules when creating .NET projects with dotnet new,
+  filling gaps consistently without overriding values the user set explicitly.
+  USE FOR: choosing sensible defaults for related parameters during project creation,
+  resolving cross-parameter interactions (AOT implies a compatible framework, auth implies
+  HTTPS, controllers excludes minimal-API flags), explaining why a default was applied.
+  DO NOT USE FOR: creating the project itself (use template-instantiation), finding or
+  comparing templates (use template-discovery and template-comparison), authoring or
+  validating custom templates (use template-authoring and template-validation).
+license: MIT
+---
+
+# Template Smart Defaults
+
+This skill helps an agent fill in cross-parameter defaults when creating a `dotnet new`
+project. The rules below are guidance heuristics that keep related parameters consistent —
+they only fill gaps and never override a value the user set explicitly.
+
+## When to Use
+
+- The user asks to create a project but leaves related parameters unspecified
+- A parameter the user chose implies a sensible value for another parameter
+- You need to explain why a particular default was selected
+
+## When Not to Use
+
+- User wants to actually create the project — route to `template-instantiation`
+- User wants to find or compare templates — route to `template-discovery` or `template-comparison`
+- User wants to author or validate a custom template — route to `template-authoring` or `template-validation`
+
+## Inputs
+
+| Input | Required | Description |
+|-------|----------|-------------|
+| Template short name | Yes | The template the project will be created from (e.g., `webapi`) |
+| Parameters already chosen | Yes | The parameter values the user has explicitly set |
+| Available choices | Recommended | Parameter names/choices from `dotnet new <template> --help` |
+
+## Workflow
+
+1. Gather the parameters the user has explicitly set.
+2. Apply each rule below **only where the corresponding parameter is unset** — never override an explicit user value.
+3. Log every applied default with a short rationale so the user can see and override it.
+4. Confirm the chosen parameter names and choices against `dotnet new <template> --help` before creating.
+
+> **AOT at create time vs publish time.** `--aot` is a `dotnet new` flag only on the templates that expose it (e.g. `console`, `worker`, `grpc`); it is **not** on `webapi`/`webapp`. There is no `--publish-aot` template flag — publish-time native AOT is enabled with the MSBuild property `PublishAot=true` (via `dotnet publish` or in the `.csproj`), not through `dotnet new`. Apply the framework rule only when the template actually offers `--aot`.
+
+### Rules
+
+| Rule | Default applied | Rationale |
+|------|-----------------|-----------|
+| `--aot` is set (on templates that support it, e.g. `console`/`worker`/`grpc`) and `--framework` is unset | Set `--framework` to the latest AOT-compatible framework the template offers | Native AOT requires a recent, AOT-capable target framework; using the latest avoids build failures. |
+| `--auth` is anything other than `None` | Do NOT pass `--no-https` | Authentication flows (cookies, tokens, redirects) require HTTPS; disabling it breaks auth. |
+| `--use-controllers` is set | Do NOT also pass a minimal-API flag | Controllers and minimal APIs are mutually exclusive program models; passing both is contradictory. |
+| User set a value explicitly | Leave it unchanged | Smart defaults only fill gaps; explicit user intent always wins. |
+
+## Validation
+
+- [ ] Each applied default was logged and explained to the user
+- [ ] No parameter the user set explicitly was overridden
+- [ ] Only unset parameters were filled
+- [ ] The resulting parameter names/choices were confirmed against `dotnet new <template> --help`
+
+## Common Pitfalls
+
+| Pitfall | Solution |
+|---------|----------|
+| Treating heuristics as enforcement | These are guidance rules, not validation. Always confirm against `dotnet new <template> --help` choices, since parameter names vary by template. |
+| Overriding an explicit user value | Apply a rule only when the target parameter is unset. |
+| Assuming a flag name | The exact flag differs per template (`--aot` exists on `console`/`worker`/`grpc` but not `webapi`; controllers use `--use-controllers`) — verify with `--help`. |
+| Picking a framework the template doesn't support | Use the latest framework that appears in the template's `--framework` choices, not an arbitrary newest version. |
+
+## More Info
+
+- [dotnet new](https://learn.microsoft.com/dotnet/core/tools/dotnet-new) — CLI reference
+- [Native AOT deployment](https://learn.microsoft.com/dotnet/core/deploying/native-aot/) — AOT framework requirements
diff --git a/plugins/dotnet-template-engine/skills/template-validation/SKILL.md b/plugins/dotnet-template-engine/skills/template-validation/SKILL.md
index 30845573be..d89daf3c21 100644
--- a/plugins/dotnet-template-engine/skills/template-validation/SKILL.md
+++ b/plugins/dotnet-template-engine/skills/template-validation/SKILL.md
@@ -61,11 +61,11 @@ When reviewing a template.json, check ALL of the following categories systematic
 
 ### 3. ShortName Conflicts
 
-The following short names conflict with dotnet CLI commands and will cause problems:
+A shortName that matches a `dotnet new` subcommand conflicts, because `dotnet new <name>` is then parsed as that subcommand instead of instantiating the template. Read the reserved set for the installed SDK from the `Commands:` section of `dotnet new --help` — that is the authoritative source and avoids this rule going stale.
 
-`new`, `build`, `run`, `test`, `publish`, `restore`, `clean`, `pack`, `add`, `remove`, `list`, `nuget`, `tool`, `sln`, `help`
+As of current SDKs the subcommands include (illustrative only — version-dependent, do not hardcode this list; the live `dotnet new --help` output is canonical): `install`, `uninstall`, `update`, `list`, `search`, `details`, `create`. Note that top-level `dotnet` verbs like `build`, `run`, `test`, and `publish` do NOT conflict — `dotnet new test` does not collide with `dotnet test`.
 
-- ERROR if shortName matches any reserved name (case-insensitive)
+- ERROR if shortName matches any subcommand reported by `dotnet new --help` (case-insensitive)
 - WARNING if shortName is only 1 character — too short for discoverability
 - Note: shortName can be a string or an array of strings; check all values
 
@@ -147,7 +147,7 @@ Include the total: "X error(s), Y warning(s), Z suggestion(s)"
 
 | Pitfall | Impact |
 |---------|--------|
-| ShortName = "test" or "build" | Template can never be created — conflicts with CLI |
+| ShortName = "list" or "search" | Template can never be created — conflicts with a `dotnet new` subcommand |
 | Missing `sourceName` | `--name MyProject` doesn't rename anything in the generated files |
 | Choice parameter without `defaultValue` | Confusing user experience on optional choice params |
 | Invalid `datatype` value | Template engine ignores the symbol, causing silent failures |
diff --git a/tests/dotnet-template-engine/template-comparison/eval.vally.yaml b/tests/dotnet-template-engine/template-comparison/eval.vally.yaml
new file mode 100644
index 0000000000..9e88bd59d0
--- /dev/null
+++ b/tests/dotnet-template-engine/template-comparison/eval.vally.yaml
@@ -0,0 +1,79 @@
+name: template-comparison
+description: Evaluates the dotnet-template-engine/template-comparison skill
+type: capability
+config:
+  timeout: 3m
+stimuli:
+  - name: Compare webapi vs webapp side by side
+    prompt: "I'm deciding between the 'webapi' and 'webapp' templates for a new .NET project. Compare them side by side — show parameters, which supports authentication, AOT, Docker, and controllers, and the available frameworks. Then recommend one for a JSON REST backend."
+    graders:
+      - type: exit-success
+      - type: output-matches
+        config:
+          pattern: (?i)webapi
+      - type: output-matches
+        config:
+          pattern: (?i)webapp
+      - type: output-matches
+        config:
+          pattern: (?i)auth
+      - type: output-matches
+        config:
+          pattern: (?i)aot
+      - type: output-matches
+        config:
+          pattern: (?i)docker
+      - type: output-matches
+        config:
+          pattern: (?i)controllers
+      - type: prompt
+      - type: pairwise
+    rubric:
+      - The agent used the template-comparison skill to compare the two templates
+      - The agent inspected each template with `dotnet new <template> --help`
+      - The agent produced a side-by-side comparison table (not just two separate lists)
+      - The comparison covered parameters, feature support (auth/AOT/Docker/controllers), and frameworks
+      - The agent gave a clear recommendation for a JSON REST backend
+    constraints:
+      expect_tools:
+        - skill
+  - name: Choose between blazor and blazorwasm
+    prompt: "Which template should I use for an app that needs offline support: 'blazor' (Blazor Web App) or 'blazorwasm' (Blazor WebAssembly Standalone)? Inspect both with `dotnet new <template> --help`, compare the interactivity/hosting trade-offs, and recommend one."
+    graders:
+      - type: exit-success
+      - type: output-matches
+        config:
+          pattern: (?i)\bblazor\b
+      - type: output-matches
+        config:
+          pattern: (?i)blazorwasm
+      - type: prompt
+      - type: pairwise
+    rubric:
+      - The agent used the template-comparison skill to compare both Blazor templates
+      - The agent inspected each template's parameters via `dotnet new <template> --help`
+      - The agent explained the hosting/interactivity trade-offs (server-rendered vs WebAssembly)
+      - The agent connected the offline-support requirement to a concrete recommendation
+    constraints:
+      expect_tools:
+        - skill
+  - name: Decide which template fits a background processing scenario
+    prompt: "I need to run a long-lived background job that processes a queue. Which template should I use — 'worker' or 'console'? Compare them and justify the choice."
+    graders:
+      - type: exit-success
+      - type: output-matches
+        config:
+          pattern: (?i)worker
+      - type: output-matches
+        config:
+          pattern: (?i)console
+      - type: prompt
+      - type: pairwise
+    rubric:
+      - The agent used the template-comparison skill rather than just creating a project
+      - The agent compared worker and console templates side by side
+      - The agent explained why the worker template fits a long-lived queue processor (hosted service lifecycle)
+      - The agent did NOT create any project files
+    constraints:
+      expect_tools:
+        - skill
diff --git a/tests/dotnet-template-engine/template-comparison/eval.yaml b/tests/dotnet-template-engine/template-comparison/eval.yaml
new file mode 100644
index 0000000000..743bfc2115
--- /dev/null
+++ b/tests/dotnet-template-engine/template-comparison/eval.yaml
@@ -0,0 +1,60 @@
+scenarios:
+  - name: "Compare webapi vs webapp side by side"
+    prompt: "I'm deciding between the 'webapi' and 'webapp' templates for a new .NET project. Compare them side by side — show parameters, which supports authentication, AOT, Docker, and controllers, and the available frameworks. Then recommend one for a JSON REST backend."
+    assertions:
+      - type: "exit_success"
+      - type: "output_matches"
+        pattern: "(?i)webapi"
+      - type: "output_matches"
+        pattern: "(?i)webapp"
+      - type: "output_matches"
+        pattern: "(?i)auth"
+      - type: "output_matches"
+        pattern: "(?i)aot"
+      - type: "output_matches"
+        pattern: "(?i)docker"
+      - type: "output_matches"
+        pattern: "(?i)controllers"
+    rubric:
+      - "The agent used the template-comparison skill to compare the two templates"
+      - "The agent inspected each template with `dotnet new <template> --help`"
+      - "The agent produced a side-by-side comparison table (not just two separate lists)"
+      - "The comparison covered parameters, feature support (auth/AOT/Docker/controllers), and frameworks"
+      - "The agent gave a clear recommendation for a JSON REST backend"
+    expect_tools:
+      - skill
+    timeout: 180
+
+  - name: "Choose between blazor and blazorwasm"
+    prompt: "Which template should I use for an app that needs offline support: 'blazor' (Blazor Web App) or 'blazorwasm' (Blazor WebAssembly Standalone)? Inspect both with `dotnet new <template> --help`, compare the interactivity/hosting trade-offs, and recommend one."
+    assertions:
+      - type: "exit_success"
+      - type: "output_matches"
+        pattern: "(?i)\\bblazor\\b"
+      - type: "output_matches"
+        pattern: "(?i)blazorwasm"
+    rubric:
+      - "The agent used the template-comparison skill to compare both Blazor templates"
+      - "The agent inspected each template's parameters via `dotnet new <template> --help`"
+      - "The agent explained the hosting/interactivity trade-offs (server-rendered vs WebAssembly)"
+      - "The agent connected the offline-support requirement to a concrete recommendation"
+    expect_tools:
+      - skill
+    timeout: 180
+
+  - name: "Decide which template fits a background processing scenario"
+    prompt: "I need to run a long-lived background job that processes a queue. Which template should I use — 'worker' or 'console'? Compare them and justify the choice."
+    assertions:
+      - type: "exit_success"
+      - type: "output_matches"
+        pattern: "(?i)worker"
+      - type: "output_matches"
+        pattern: "(?i)console"
+    rubric:
+      - "The agent used the template-comparison skill rather than just creating a project"
+      - "The agent compared worker and console templates side by side"
+      - "The agent explained why the worker template fits a long-lived queue processor (hosted service lifecycle)"
+      - "The agent did NOT create any project files"
+    expect_tools:
+      - skill
+    timeout: 180
diff --git a/tests/dotnet-template-engine/template-smart-defaults/eval.vally.yaml b/tests/dotnet-template-engine/template-smart-defaults/eval.vally.yaml
new file mode 100644
index 0000000000..2bec454f10
--- /dev/null
+++ b/tests/dotnet-template-engine/template-smart-defaults/eval.vally.yaml
@@ -0,0 +1,87 @@
+name: template-smart-defaults
+description: Evaluates the dotnet-template-engine/template-smart-defaults skill
+type: capability
+config:
+  timeout: 3m
+stimuli:
+  - name: AOT implies a compatible framework
+    prompt: "Create a native AOT worker service. I haven't picked a target framework — choose an appropriate one for me and explain why. Don't write any files yet, just tell me the parameters you'd use."
+    graders:
+      - type: exit-success
+      - type: output-matches
+        config:
+          pattern: (?i)(aot)
+      - type: output-matches
+        config:
+          pattern: (?i)net(8|9|10)\.0
+      - type: prompt
+      - type: pairwise
+    rubric:
+      - The agent used the template-smart-defaults skill to fill the cross-parameter gap
+      - Because AOT was requested, the agent also selected a target framework
+      - The agent chose the latest AOT-compatible framework available rather than an arbitrary one
+      - The agent explained the rationale (native AOT needs a recent AOT-capable TFM)
+      - The agent confirmed it would verify parameter names against `dotnet new <template> --help`
+    constraints:
+      expect_tools:
+        - skill
+  - name: Auth implies HTTPS stays enabled
+    prompt: "I want to create a webapi with Individual authentication. First output the exact single `dotnet new` command line you would run — include only the flags you will actually pass, and do not mention any flags you are not using. Then give a brief explanation. Don't create anything yet."
+    graders:
+      - type: exit-success
+      - type: output-matches
+        config:
+          pattern: (?i)individual
+      - type: output-not-matches
+        config:
+          pattern: (?i)dotnet new[^\n]*--no-https
+      - type: prompt
+      - type: pairwise
+    rubric:
+      - The agent used the template-smart-defaults skill
+      - Because auth is not None, the agent did NOT add a --no-https flag
+      - The agent explained that authentication flows require HTTPS
+      - The agent only filled gaps and logged each applied default
+    constraints:
+      expect_tools:
+        - skill
+  - name: Controllers exclude the minimal-API flag
+    prompt: "Create a web API that uses controllers. First output the exact single `dotnet new` command line you would run — include only the flags you will actually pass, and do not mention any flags you are not using. Then explain. Do not create files."
+    graders:
+      - type: exit-success
+      - type: output-matches
+        config:
+          pattern: (?i)(use-controllers|controllers)
+      - type: output-not-matches
+        config:
+          pattern: (?i)dotnet new[^\n]*--[a-z-]*minimal
+      - type: prompt
+      - type: pairwise
+    rubric:
+      - The agent used the template-smart-defaults skill
+      - The agent passed the controllers flag
+      - The agent did NOT also pass a minimal-API flag (the two are mutually exclusive)
+      - The agent explained the reasoning
+    constraints:
+      expect_tools:
+        - skill
+  - name: Never override an explicit user value
+    prompt: "Create a native AOT console app, but I specifically want it targeting net8.0 — keep it on net8.0 no matter what. First output the exact single `dotnet new` command line you would run — include only the flags and framework value you will actually pass, and do not mention any flags or framework versions you are not using. Then tell me the parameters."
+    graders:
+      - type: exit-success
+      - type: output-contains
+        config:
+          substring: net8.0
+      - type: output-not-matches
+        config:
+          pattern: (?i)dotnet new[^\n]*--framework[ =]+net(9|10)\.0
+      - type: prompt
+      - type: pairwise
+    rubric:
+      - The agent used the template-smart-defaults skill
+      - The agent respected the explicit net8.0 framework the user set
+      - The agent did NOT override the user value with a newer framework despite AOT being requested
+      - The agent explained that smart defaults only fill gaps and never override explicit user choices
+    constraints:
+      expect_tools:
+        - skill
diff --git a/tests/dotnet-template-engine/template-smart-defaults/eval.yaml b/tests/dotnet-template-engine/template-smart-defaults/eval.yaml
new file mode 100644
index 0000000000..ba5e31c10c
--- /dev/null
+++ b/tests/dotnet-template-engine/template-smart-defaults/eval.yaml
@@ -0,0 +1,69 @@
+scenarios:
+  - name: "AOT implies a compatible framework"
+    prompt: "Create a native AOT worker service. I haven't picked a target framework — choose an appropriate one for me and explain why. Don't write any files yet, just tell me the parameters you'd use."
+    assertions:
+      - type: "exit_success"
+      - type: "output_matches"
+        pattern: "(?i)(aot)"
+      - type: "output_matches"
+        pattern: "(?i)net(8|9|10)\\.0"
+    rubric:
+      - "The agent used the template-smart-defaults skill to fill the cross-parameter gap"
+      - "Because AOT was requested, the agent also selected a target framework"
+      - "The agent chose the latest AOT-compatible framework available rather than an arbitrary one"
+      - "The agent explained the rationale (native AOT needs a recent AOT-capable TFM)"
+      - "The agent confirmed it would verify parameter names against `dotnet new <template> --help`"
+    expect_tools:
+      - skill
+    timeout: 180
+
+  - name: "Auth implies HTTPS stays enabled"
+    prompt: "I want to create a webapi with Individual authentication. First output the exact single `dotnet new` command line you would run — include only the flags you will actually pass, and do not mention any flags you are not using. Then give a brief explanation. Don't create anything yet."
+    assertions:
+      - type: "exit_success"
+      - type: "output_matches"
+        pattern: "(?i)individual"
+      - type: "output_not_matches"
+        pattern: "(?i)dotnet new[^\\n]*--no-https"
+    rubric:
+      - "The agent used the template-smart-defaults skill"
+      - "Because auth is not None, the agent did NOT add a --no-https flag"
+      - "The agent explained that authentication flows require HTTPS"
+      - "The agent only filled gaps and logged each applied default"
+    expect_tools:
+      - skill
+    timeout: 180
+
+  - name: "Controllers exclude the minimal-API flag"
+    prompt: "Create a web API that uses controllers. First output the exact single `dotnet new` command line you would run — include only the flags you will actually pass, and do not mention any flags you are not using. Then explain. Do not create files."
+    assertions:
+      - type: "exit_success"
+      - type: "output_matches"
+        pattern: "(?i)(use-controllers|controllers)"
+      - type: "output_not_matches"
+        pattern: "(?i)dotnet new[^\\n]*--[a-z-]*minimal"
+    rubric:
+      - "The agent used the template-smart-defaults skill"
+      - "The agent passed the controllers flag"
+      - "The agent did NOT also pass a minimal-API flag (the two are mutually exclusive)"
+      - "The agent explained the reasoning"
+    expect_tools:
+      - skill
+    timeout: 180
+
+  - name: "Never override an explicit user value"
+    prompt: "Create a native AOT console app, but I specifically want it targeting net8.0 — keep it on net8.0 no matter what. First output the exact single `dotnet new` command line you would run — include only the flags and framework value you will actually pass, and do not mention any flags or framework versions you are not using. Then tell me the parameters."
+    assertions:
+      - type: "exit_success"
+      - type: "output_contains"
+        value: "net8.0"
+      - type: "output_not_matches"
+        pattern: "(?i)dotnet new[^\\n]*--framework[ =]+net(9|10)\\.0"
+    rubric:
+      - "The agent used the template-smart-defaults skill"
+      - "The agent respected the explicit net8.0 framework the user set"
+      - "The agent did NOT override the user value with a newer framework despite AOT being requested"
+      - "The agent explained that smart defaults only fill gaps and never override explicit user choices"
+    expect_tools:
+      - skill
+    timeout: 180