AutoGineer
Generated banner for Template Smart Defaults
Generated logo for Template Smart Defaults

Template Smart Defaults

.NET (Microsoft)OfficialPublished by .NET (Microsoft)

  • Skill
  • Tool integration
  • Software development
  • MIT
  • No issues found
Download ZIP

From the author

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).
— the description by .NET (Microsoft)

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

This skill provides a structured approach to filling in missing parameters when using the dotnet new command. It ensures that related project settings remain consistent by applying predefined heuristics to unset parameters, while strictly respecting any values the user has explicitly defined. The skill emphasizes transparency by providing a clear log of applied defaults and their sources, and it ensures that generated commands are accurate and safe for the user's intent.

What it does

  • Identifies missing parameters in dotnet new commands based on user intent.
  • Applies consistent default values for unset parameters using defined heuristics.
  • Generates a detailed log explaining which parameters were user-defined and which were filled by rule.
  • Constructs precise dotnet new command lines including only necessary flags.
  • Ensures compatibility between related settings like native AOT and target frameworks.
  • Appends --dry-run to commands when the user requests advice without file creation.

When to use it

  • When a user wants to create a .NET project but has not specified all required or related parameters.
  • When you need to ensure that a chosen parameter, such as native AOT, is paired with a compatible target framework.
  • When you need to explain the rationale behind specific project configuration defaults.
  • When you need to provide a safe, reproducible command line for project creation.

Advantages

  • Prevents configuration conflicts by enforcing logical parameter combinations.
  • Maintains user intent by never overriding explicitly set values.
  • Increases transparency through a clear log of parameter sources and rationales.
  • Reduces errors by validating parameter choices against template-specific help documentation.

Usage examples

“Create a webapi project with native AOT.”
The agent identifies the need for an AOT-compatible framework, selects the latest available, and outputs the command: dotnet new webapi --aot --framework net10.0
“I want to start a new webapi project with authentication, but don't create any files.”
The agent keeps HTTPS enabled due to the authentication requirement and outputs: dotnet new webapi --auth Individual --dry-run

Install

  1. Download the skill as a ZIP:

    https://autogineer.com/agent-skills/dotnet/template-smart-defaults/download

  2. Unzip it into the cross-client skills folder of your project:

    mkdir -p .agents/skills && unzip template-smart-defaults.zip -d .agents/skills

Documentation by .NET (Microsoft)

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

InputRequiredDescription
Template short nameYesThe template the project will be created from (e.g., webapi)
Parameters already chosenYesThe parameter values the user has explicitly set
Available choicesRecommendedParameter 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:

ParameterValueSourceWhy
--frameworknet10.0ruleNative AOT (from --aot) needs the latest AOT-capable TFM
--authIndividualuserExplicitly requested — left unchanged
--nameAotWorkerruleAdded 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
RuleDefault appliedRationale
--aot is set (on any template whose --help exposes it) and --framework is unsetSet --framework to the latest AOT-compatible framework the template offersNative 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 NoneDo NOT pass --no-httpsAuthentication flows (cookies, tokens, redirects) require HTTPS; disabling it breaks auth.
--use-controllers is setDo NOT also pass a minimal-API flagControllers and minimal APIs are mutually exclusive program models; passing both is contradictory.
User set a value explicitlyLeave it unchangedSmart defaults only fill gaps; explicit user intent always wins.
Advice-only command must not create filesAdd --dry-runThe 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.

Validation

  • [ ] A "Defaults applied" log was produced with a Source (user/rule) and rationale per row

  • [ ] The exact single dotnet new command 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

PitfallSolution
Treating heuristics as enforcementThese are guidance rules, not validation. Always confirm against dotnet new <template> --help choices, since parameter names vary by template.
Overriding an explicit user valueApply a rule only when the target parameter is unset.
Assuming a flag nameThe 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 supportUse 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.

More Info

Files

Requirements and compatibility

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta

“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.

Security

No issues found by our static scan· No issues found

A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.

Attribution and licence

Published by
.NET (Microsoft)
Publisher
.NET (Microsoft) (Official)
Source
dotnet/skills · plugins/dotnet-template-engine/skills/template-smart-defaults · commit 96c3d68
Licence
MIT License (redistribution allowed)
  • LICENSE (added by AutoGineer from LICENSE)
  • ATTRIBUTION.md (written by AutoGineer)
Synced

AutoGineer is not affiliated with or endorsed by .NET (Microsoft) or .NET (Microsoft).

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download template-smart-defaults.zip