Skills template-instantiation

Name: template-instantiation
Author: dotnet

install

source · Clone the upstream repo

git clone https://github.com/dotnet/skills

Claude Code · Install into ~/.claude/skills/

T=$(mktemp -d) && git clone --depth=1 https://github.com/dotnet/skills "$T" && mkdir -p ~/.claude/skills && cp -r "$T/plugins/dotnet-template-engine/skills/template-instantiation" ~/.claude/skills/dotnet-skills-template-instantiation && rm -rf "$T"

manifest: plugins/dotnet-template-engine/skills/template-instantiation/SKILL.md

source content

Template Instantiation

This skill creates .NET projects from templates using

dotnet new

CLI commands, with guidance for parameter validation, Central Package Management adaptation, and multi-project composition.

When to Use

User asks to create a new .NET project, app, or service
User needs a solution with multiple projects (API + tests + library)
User wants to create a project that respects existing
```
Directory.Packages.props
```
User needs to install or manage template packages

When Not to Use

User is searching for or comparing templates — route to
```
template-discovery
```
skill
User wants to author a custom template — route to
```
template-authoring
```
skill
User wants to add packages to an existing project — use
```
dotnet add package
```
directly

Inputs

Input	Required	Description
Template name or intent	Yes	Template short name (e.g., `webapi` ) or natural-language description
Project name	Yes	Name for the created project
Output path	Recommended	Directory where the project should be created
Parameters	No	Template-specific parameters (e.g., `--framework` , `--auth` , `--aot` )

Workflow

Step 1: Resolve template and parameters

If the user provides a natural-language description, map it to a template short name (see the keyword table in the

template-discovery

skill). If they provide a template name, proceed directly.

Use

dotnet new <template> --help

to review available parameters, defaults, and types for any parameters the user did not specify.

Step 2: Analyze the workspace

Check the existing solution structure before creating:

Is Central Package Management (CPM) enabled? Look for
```
Directory.Packages.props
```
What target frameworks are in use? Check existing
```
.csproj
```
files
Is there a
```
global.json
```
pinning the SDK?

This ensures the new project is consistent with the workspace.

Step 3: Preview the creation

Use

dotnet new <template> --dry-run

to show the user what files would be created. Confirm before proceeding.

dotnet new webapi --name MyApi --framework net10.0 --dry-run

Step 4: Create the project

Use

dotnet new

with the template name and all parameters:

dotnet new webapi --name MyApi --output ./src/MyApi --framework net10.0 --auth Individual

Common parameter combinations

Template	Parameters	Example
`webapi`	`--auth` (None, Individual, SingleOrg, Windows), `--aot` (native AOT)	`dotnet new webapi -n MyApi --auth Individual --aot`
`webapi`	`--use-controllers` (use controllers vs minimal APIs)	`dotnet new webapi -n MyApi --use-controllers`
`blazor`	`--interactivity` (None, Server, WebAssembly, Auto), `--auth`	`dotnet new blazor -n MyApp --interactivity Server`
`grpc`	`--aot` (native AOT)	`dotnet new grpc -n MyService --aot`
`worker`	`--aot` (native AOT)	`dotnet new worker -n MyWorker --aot`

Note: Use

dotnet new <template> --help

to see all available parameters for any template.

After creation, if the workspace uses CPM:

Check
```
.csproj
```
for inline
```
<PackageReference>
```
versions

Move version attributes to

Directory.Packages.props

<PackageVersion>

entries

Remove
```
Version
```
attributes from the
```
.csproj
```

Step 5: Multi-project composition (optional)

For complex structures, create each project sequentially and wire them together:

dotnet new webapi --name MyApi --output ./src/MyApi
dotnet new xunit --name MyApi.Tests --output ./tests/MyApi.Tests
dotnet add ./tests/MyApi.Tests reference ./src/MyApi
dotnet sln add ./src/MyApi ./tests/MyApi.Tests

Step 6: Template package management

Install or uninstall template packages:

dotnet new install Microsoft.DotNet.Web.ProjectTemplates.10.0
dotnet new uninstall Microsoft.DotNet.Web.ProjectTemplates.10.0

Step 7: Post-creation verification

Verify the project builds:
```
dotnet build
```
If added to a solution, verify
```
dotnet build
```
at the solution level
If CPM was adapted, verify
```
Directory.Packages.props
```
has the new entries

Validation

Project was created successfully with the expected files
Project builds cleanly with
```
dotnet build
```
If CPM is active,
```
.csproj
```
has no version attributes and
```
Directory.Packages.props
```
has matching entries
Package versions in the project are current (not stale template defaults)
If multi-project, all projects build and reference each other correctly

Common Pitfalls

Pitfall	Solution
Not checking for CPM before creating a project	If `Directory.Packages.props` exists, `dotnet new` creates projects with inline versions that conflict. After creation, move versions to `Directory.Packages.props` and remove them from `.csproj` .
Creating projects without specifying the framework	Always specify `--framework` when the template supports multiple TFMs to avoid defaulting to an older version.
Not adding the project to the solution	After creation, run `dotnet sln add` to include the project in the solution.
Not verifying the project builds	Always run `dotnet build` after creation to catch missing dependencies or parameter issues early.

More Info

Central Package Management — CPM documentation
dotnet new — CLI reference