Template Authoring

Workflow

Step 1: Bootstrap from existing project

Analyze the source .csproj and create a .template.config/template.json:

1. Create .template.config directory next to the project
2. Generate template.json with identity (reverse-DNS), name, shortName, sourceName (project name for replacement), classifications, and tags
3. Preserve from source — generic dotnet new templates frequently get these wrong, so verify each is carried over from the original .csproj:

1. SDK type — Microsoft.NET.Sdk, Microsoft.NET.Sdk.Web, Microsoft.NET.Sdk.Worker, etc. 2. Analyzer/package reference metadata — PrivateAssets, IncludeAssets, ExcludeAssets 3. `OutputType` and other key properties — TreatWarningsAsErrors, Nullable, LangVersion 4. CPM participation — no inline Version attributes when a Directory.Packages.props is present 5. Custom build props/targets and Directory.Build.props conventions 6. 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" }
}

Required output — do not stop at a minimal stub. Write the *complete* .template.config/template.json for the actual source project, then emit a short conventions-preserved confirmation so the user can see nothing was silently dropped. This carry-over is the whole value of the skill; a generic dotnet new template that loses these is why authoring ties with a hand-written stub.

| Source .csproj setting | Carried over? | How | |--------------------------|---------------|-----| | SDK (Microsoft.NET.Sdk.*) | ✅ | template content .csproj uses same SDK | | TreatWarningsAsErrors / Nullable / LangVersion | ✅ | preserved verbatim in template .csproj | | PackageReference PrivateAssets / IncludeAssets / ExcludeAssets | ✅ | metadata kept on each reference | | CPM (Directory.Packages.props present) | ✅ | no inline Version attributes emitted |

Mark any row you intentionally omitted as ⚠️ with a reason — never leave it implicit.

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:

1. Add parameters with appropriate types (string, bool, choice), defaults, and descriptions
2. Add conditional content using #if preprocessor directives for optional features
3. Configure post-actions for solution add, restore, or custom scripts
4. Set constraints to restrict which SDKs or workloads the template supports
5. 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

Related skills