npx skills add ...
npx skills add dotnet/skills --skill template-smart-defaults
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).
npx skills add dotnet/skills --skill 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.
template-instantiationtemplate-discovery or template-comparisontemplate-authoring or template-validation| 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 |
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.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.
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.
--aotis adotnet newflag only on the templates that expose it — always confirm withdotnet new <template> --helprather than assuming a given template does or doesn't offer it. There is no--publish-aottemplate flag — publish-time native AOT is enabled with the MSBuild propertyPublishAot=true(viadotnet publishor in the.csproj), not throughdotnet new. Apply the framework rule only when the template actually offers--aot.
| 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 honor the no-write constraint, not only the agent's behavior. |
When controllers are explicitly requested, the command must contain the controller option
shown by --help; explaining controllers without passing the option is incomplete.
dotnet new command line was emitted, listing only flags actually passeddotnet new <template> --help, including for advice-only exact commands--dry-runtrue| 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 — always verify with --help (e.g. --aot is present only where --help lists it; controllers use --use-controllers). |
| 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. |
| Showing a plain creation command after "don't create files" | Append --dry-run so the displayed command is safe to execute. |