Template Authoring
This skill helps an agent create and validate custom dotnet new templates. It guides bootstrapping templates from existing projects and validates template.json files for authoring issues before publishing.
When to Use
- User wants to create a reusable template from an existing .csproj
- User wants to validate a template.json for correctness
- User is setting up
.template.config/template.json from scratch
- User wants to package a template for NuGet distribution
When Not to Use
- User wants to find or use existing templates — route to
template-discovery or template-instantiation
- User has MSBuild issues unrelated to template authoring — route to
dotnet-msbuild plugin
Inputs
| Input |
Required |
Description |
| Source project path |
For creation |
Path to the .csproj to use as template source |
| template.json path |
For validation |
Path to an existing template.json to validate |
| Template name |
For creation |
Human-readable name for the template |
| Short name |
Recommended |
Short name for dotnet new <shortname> usage |
Workflow
Step 1: Bootstrap from existing project
Analyze the source .csproj and create a .template.config/template.json:
- Create
.template.config directory next to the project
- Generate
template.json with identity (reverse-DNS), name, shortName, sourceName (project name for replacement), classifications, and tags
- Preserve from source — generic
dotnet new templates frequently get these wrong, so verify each is carried over from the original .csproj:
- SDK type —
Microsoft.NET.Sdk, Microsoft.NET.Sdk.Web, Microsoft.NET.Sdk.Worker, etc.
- Analyzer/package reference metadata —
PrivateAssets, IncludeAssets, ExcludeAssets
OutputType and other key properties — TreatWarningsAsErrors, Nullable, LangVersion
- CPM participation — no inline
Version attributes when a Directory.Packages.props is present
- Custom build props/targets and
Directory.Build.props conventions
- Repo conventions — folder layout, naming,
global.json SDK pin
Minimal example:
{
"$schema": "http://json.schemastore.org/template",
"author": "MyOrg",
"classifications": ["Library"],
"identity": "MyOrg.Templates.MyLib",
"name": "My Library Template",
"shortName": "mylib",
"sourceName": "MyLib",
"tags": { "language": "C#", "type": "project" }
}
Step 2: Validate template.json
Validate the generated template.json using the template-validation skill (it owns the full rule set — required fields, identity format, reserved shortName conflicts, parameter datatypes, post-actions, constraints, and tags).
Quick summary of what gets checked:
- Required fields —
identity, name, and shortName must be present.
- ShortName conflicts — avoid names that collide with
dotnet new subcommands. Read the authoritative set from the Commands: section of dotnet new --help for the installed SDK and do not hardcode it (it can change between versions); illustrative examples from current SDKs are install, uninstall, update, list, search, details, create. A conflict happens because dotnet new <name> would be parsed as the subcommand of the same name. Top-level dotnet verbs like build, run, test, and publish do NOT conflict. Run dotnet new list to confirm the name is not already taken.
- Parameters, post-actions, tags — see template-validation for the complete rules, including the valid datatype list.
Step 3: Refine the template
Based on validation results and user requirements:
- Add parameters with appropriate types (string, bool, choice), defaults, and descriptions
- Add conditional content using
#if preprocessor directives for optional features
- Configure post-actions for solution add, restore, or custom scripts
- Set constraints to restrict which SDKs or workloads the template supports
- Add classifications and tags for discoverability
Step 4: Test the template locally
dotnet new install ./path/to/template/root
dotnet new mylib --name TestProject --dry-run
dotnet new mylib --name TestProject --output ./test-output
dotnet build ./test-output/TestProject
Validation
Common Pitfalls
| Pitfall |
Solution |
| Identity format issues |
Use reverse-DNS format (e.g., MyOrg.Templates.WebApi). Avoid spaces or special characters. |
| ShortName conflicts with CLI commands |
Avoid names that match a dotnet new subcommand; read the live set from dotnet new --help and don't hardcode it (illustrative examples: install, uninstall, update, list, search, details, create). Top-level verbs like build/run/test/publish are fine. Run dotnet new list to see if the name is already taken. |
| Missing parameter descriptions |
Every parameter should have a description and displayName for discoverability. |
| Not testing all parameter combinations |
Use dotnet new <template> --dry-run with different parameter values to verify conditional content works correctly. |
| Hardcoded versions in template |
Use sourceName replacement for project names and consider parameterizing framework versions. |
| Not setting classifications |
Add appropriate classifications (e.g., ["Web", "API"]) for template discovery. |
More Info
1---2name: template-authoring3description: Guides creation and validation of custom dotnet new templates from existing projects, including template.json authoring and packaging for NuGet distribution.4license: MIT5---67# Template Authoring89This skill helps an agent create and validate custom `dotnet new` templates. It guides bootstrapping templates from existing projects and validates `template.json` files for authoring issues before publishing.1011## When to Use1213- User wants to create a reusable template from an existing .csproj14- User wants to validate a template.json for correctness15- User is setting up `.template.config/template.json` from scratch16- User wants to package a template for NuGet distribution1718## When Not to Use1920- User wants to find or use existing templates — route to `template-discovery` or `template-instantiation`21- User has MSBuild issues unrelated to template authoring — route to `dotnet-msbuild` plugin2223## Inputs2425| Input | Required | Description |26|-------|----------|-------------|27| Source project path | For creation | Path to the .csproj to use as template source |28| template.json path | For validation | Path to an existing template.json to validate |29| Template name | For creation | Human-readable name for the template |30| Short name | Recommended | Short name for `dotnet new <shortname>` usage |3132## Workflow3334### Step 1: Bootstrap from existing project3536Analyze the source `.csproj` and create a `.template.config/template.json`:37381. Create `.template.config` directory next to the project392. Generate `template.json` with `identity` (reverse-DNS), `name`, `shortName`, `sourceName` (project name for replacement), `classifications`, and `tags`403. Preserve from source — generic `dotnet new` templates frequently get these wrong, so verify each is carried over from the original `.csproj`:41 1. **SDK type** — `Microsoft.NET.Sdk`, `Microsoft.NET.Sdk.Web`, `Microsoft.NET.Sdk.Worker`, etc.42 2. **Analyzer/package reference metadata** — `PrivateAssets`, `IncludeAssets`, `ExcludeAssets`43 3. **`OutputType` and other key properties** — `TreatWarningsAsErrors`, `Nullable`, `LangVersion`44 4. **CPM participation** — no inline `Version` attributes when a `Directory.Packages.props` is present45 5. **Custom build props/targets** and `Directory.Build.props` conventions46 6. **Repo conventions** — folder layout, naming, `global.json` SDK pin4748Minimal example:49```json50{51 "$schema": "http://json.schemastore.org/template",52 "author": "MyOrg",53 "classifications": ["Library"],54 "identity": "MyOrg.Templates.MyLib",55 "name": "My Library Template",56 "shortName": "mylib",57 "sourceName": "MyLib",58 "tags": { "language": "C#", "type": "project" }59}60```6162### Step 2: Validate template.json6364Validate the generated `template.json` using the **template-validation** skill (it owns the full rule set — required fields, identity format, reserved shortName conflicts, parameter datatypes, post-actions, constraints, and tags).6566Quick summary of what gets checked:67- **Required fields** — `identity`, `name`, and `shortName` must be present.68- **ShortName conflicts** — avoid names that collide with `dotnet new` subcommands. Read the authoritative set from the `Commands:` section of `dotnet new --help` for the installed SDK and do not hardcode it (it can change between versions); illustrative examples from current SDKs are `install`, `uninstall`, `update`, `list`, `search`, `details`, `create`. A conflict happens because `dotnet new <name>` would be parsed as the subcommand of the same name. Top-level `dotnet` verbs like `build`, `run`, `test`, and `publish` do NOT conflict. Run `dotnet new list` to confirm the name is not already taken.69- **Parameters, post-actions, tags** — see template-validation for the complete rules, including the valid datatype list.7071### Step 3: Refine the template7273Based on validation results and user requirements:74751. **Add parameters** with appropriate types (string, bool, choice), defaults, and descriptions762. **Add conditional content** using `#if` preprocessor directives for optional features773. **Configure post-actions** for solution add, restore, or custom scripts784. **Set constraints** to restrict which SDKs or workloads the template supports795. **Add classifications** and tags for discoverability8081### Step 4: Test the template locally8283```bash84dotnet new install ./path/to/template/root85dotnet new mylib --name TestProject --dry-run86dotnet new mylib --name TestProject --output ./test-output87dotnet build ./test-output/TestProject88```8990## Validation9192- [ ] `template.json` passes manual validation with zero errors93- [ ] Template identity and shortName are unique and meaningful94- [ ] All parameters have descriptions and appropriate defaults95- [ ] Template can be installed, dry-run, and instantiated successfully96- [ ] Created projects build cleanly with `dotnet build`97- [ ] Conditional content produces correct output for all parameter combinations9899## Common Pitfalls100101| Pitfall | Solution |102|---------|----------|103| Identity format issues | Use reverse-DNS format (e.g., `MyOrg.Templates.WebApi`). Avoid spaces or special characters. |104| ShortName conflicts with CLI commands | Avoid names that match a `dotnet new` subcommand; read the live set from `dotnet new --help` and don't hardcode it (illustrative examples: `install`, `uninstall`, `update`, `list`, `search`, `details`, `create`). Top-level verbs like `build`/`run`/`test`/`publish` are fine. Run `dotnet new list` to see if the name is already taken. |105| Missing parameter descriptions | Every parameter should have a `description` and `displayName` for discoverability. |106| Not testing all parameter combinations | Use `dotnet new <template> --dry-run` with different parameter values to verify conditional content works correctly. |107| Hardcoded versions in template | Use `sourceName` replacement for project names and consider parameterizing framework versions. |108| Not setting classifications | Add appropriate `classifications` (e.g., `["Web", "API"]`) for template discovery. |109110## More Info111112- [Custom templates for dotnet new](https://learn.microsoft.com/dotnet/core/tools/custom-templates) — official authoring guide113- [template.json reference](https://github.com/dotnet/templating/wiki/Reference-for-template.json) — full schema reference114- [Template Engine Wiki](https://github.com/dotnet/templating/wiki) — template engine internals