/template-smart-defaults

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 which target framework to pair with native AOT, deciding whether to
  keep HTTPS when authentication is enabled, recognizing that controllers and minimal-API
  flags are mutually exclusive, filling unset related parameters during project creation,
  explaining why a default was applied and ensuring an explicit user value is never
  overridden.
  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 a value the user set explicitly. 3. Confirm the chosen parameter names and choices against `dotnet new <template> --help` whenever the user asks for an exact command. This inspection does not create files and is worthwhile even for advice-only requests. Skip it only for a conceptual explanation that does not claim exact option names. 4. **Emit the two required outputs** (see below) — this is what makes the skill decisive rather than inert.

For advice-only prompts that say "don't create files", make the displayed command safe to run by appending `--dry-run`. If a scenario needs a named example and the user omitted the name, choose a short descriptive sample name and mark it `Source = rule`. Do not add a name when the user asked for a command containing only explicitly requested choices or when the template can demonstrate those choices safely without one.

Required output

Always produce **both**, in this order:

**A. A "Defaults applied" log** — one row per parameter, covering **both** the explicit values you preserved (`Source = user`) and the gaps you filled by rule (`Source = rule`), so the user can see and override every choice:

| Parameter | Value | Source | Why | |-----------|-------|--------|-----| | `--framework` | `net10.0` | rule | Native AOT (from `--aot`) needs the latest AOT-capable TFM | | `--auth` | `Individual` | user | Explicitly requested — left unchanged | | `--name` | `AotWorker` | rule | Added a descriptive sample name for this named example |

Use `Source = user` for explicit values (never overridden) and `Source = rule` for gap-fills.

**B. The exact single `dotnet new` command line** you would run — include **only** the flags you are actually passing. Do not list flags you decided *not* to pass (e.g. don't mention `--no-https` when you are keeping HTTPS; don't mention a minimal-API flag when using controllers). Silence on an omitted flag is the correct, decisive signal.

Always emit a flag the user explicitly requested when the observed template help exposes it, even when its value matches the template default; this keeps intent visible and reproducible (for example, `--auth None`). Omit only **inferred** defaults that you are not actually passing. Boolean switches such as `--no-https` are passed without `true`.

> **AOT at create time vs publish time.** `--aot` is a `dotnet new` flag only on the templates that expose it — always confirm with `dotnet new <template> --help` rather than assuming a given template does or doesn't offer it. 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 any template whose `--help` exposes it) 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. (A framework already pinned by the workspace or `global.json` counts as set — keep it unless it's incompatible with AOT.) | | `--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. | | Advice-only command must not create files | Add `--dry-run` | The command itself must