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-discoveryortemplate-comparison - User wants to author or validate a custom template — route to
template-authoringortemplate-validation
Inputs
Workflow
- Gather the parameters the user has explicitly set.
- Apply each rule below only where the corresponding parameter is unset — never override a value the user set explicitly.
- Confirm the chosen parameter names and choices against
dotnet new <template> --helpwhenever 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. - 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:
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.
Rules
When controllers are explicitly requested, the command must contain the controller option
shown by --help; explaining controllers without passing the option is incomplete.
Validation
- A "Defaults applied" log was produced with a Source (user/rule) and rationale per row
- The exact single
dotnet newcommand line was emitted, listing only flags actually passed - No parameter the user set explicitly was overridden
- Only unset parameters were filled
- Exact parameter names/choices were confirmed against
dotnet new <template> --help, including for advice-only exact commands - A no-file advice command includes
--dry-run - Boolean switches are emitted without a trailing
true
Common Pitfalls
More Info
- dotnet new — CLI reference
- Native AOT deployment — AOT framework requirements
