This skill helps validate custom dotnet new templates for correctness before publishing. It encodes the validation rules that catch common authoring mistakes — issues that cause templates to silently fail, produce broken projects, or not appear in dotnet new list.
template-discoverytemplate-instantiationtemplate-authoring| Input | \nRequired | \nDescription | \n
|---|---|---|
| template.json path | \nYes | \nPath to the template.json file or the template directory containing .template.config/template.json | \n
When reviewing a template.json, check ALL of the following categories systematically. Report every finding as an error, warning, or suggestion.
\n| Field | \nSeverity | \nRule | \n
|---|---|---|
identity | \nERROR | \nMust be present and non-empty | \n
name | \nERROR | \nMust be present and non-empty | \n
shortName | \nERROR | \nMust be present and non-empty | \n
sourceName | \nWARNING | \nWithout it, --name won't customize the generated project name | \n
author | \nWARNING | \nImproves template discoverability | \n
description | \nSUGGESTION | \nHelps users understand what the template creates | \n
classifications | \nSUGGESTION | \nImproves search and categorization (e.g., [\"Web\", \"API\"]) | \n
defaultName | \nSUGGESTION | \nProvides a fallback project name when --name is not specified | \n
MyCompany.WebApi.CSharp). or -) — use reverse-DNS formatA shortName that matches a dotnet new subcommand conflicts, because dotnet new <name> is then parsed as that subcommand instead of instantiating the template. Read the reserved set for the installed SDK from the Commands: section of dotnet new --help — that is the authoritative source and avoids this rule going stale.
As of current SDKs the subcommands include (illustrative only — version-dependent, do not hardcode this list; the live dotnet new --help output is canonical): install, uninstall, update, list, search, details, create. Note that top-level dotnet verbs like build, run, test, and publish do NOT conflict — dotnet new test does not collide with dotnet test.
dotnet new --help (case-insensitive)For each symbol in the symbols object:
type fieldtype: \"parameter\":\ndatatype specified (defaults to string)description (improves --help output)datatype: \"choice\":\nchoices definedchoices is emptydefaultValue is not in the choices listisRequired) and no defaultValue — users get unexpected behaviordatatype: \"bool\":\ndefaultValue is not a valid booleandatatype: \"int\":\ndefaultValue is not a valid integerstring, bool, choice, int, float, hex, texttype: \"computed\":\nvalue expressiontype: \"generated\":\ngenerator fieldcasing, coalesce, constant, port, guid, now, random, regex, regexMatch, switch, joinParameter prefix collisions: WARNING if any parameter name is a prefix of another parameter name (e.g., Auth and AuthMode) — this creates ambiguous parsing in expression contexts.
For source modifier conditions:
\n(symbolName), not bare symbolNameFor each post-action:
\nactionIddescription — this text is shown to users when the action requires manual stepsmanualInstructions — these are shown when the action can't run automatically (e.g., in an IDE)For each constraint:
\ntype fieldargs — most constraint types require argumentslanguage tag — adding tags.language (e.g., \"C#\") improves filtering in dotnet new list --languagetype tag — adding tags.type (e.g., \"project\" or \"item\") improves categorizationThe file can be at:
\npath/to/template.jsonpath/to/.template.config/template.json.template.config directory: path/.template.config/template.jsonRead the JSON. If it's malformed, report the JSON parse error with line number.
\nRun all 8 validation categories above. Collect errors, warnings, and suggestions separately.
\nLead with a one-line verdict, then a single findings table. This decisive shape is required — do not scatter findings across prose paragraphs.
\nVerdict header (pick one):
\n❌ Not ready — N error(s), M warning(s) — has errors⚠️ Publishable but N warning(s) — no errors, has warnings✅ Ready to publish — 0 errors, 0 warnings — no errors or warnings (optional suggestions may still apply)Then one table, ordered errors → warnings → suggestions:
\n| Severity | \nLocation (JSON path or line:col) | \nIssue | \nFix | \n
|---|---|---|---|
| ERROR | \nshortName | \n\"list\" conflicts with a dotnet new subcommand | \nRename to a distinctive value, e.g. \"my-list\" | \n
| ERROR | \nsymbols.maxRetries.defaultValue | \n\"abc\" is not a valid int | \nSet a numeric default, e.g. \"3\" | \n
| ERROR | \n12:5 | \nJSON parse error: unexpected , | \nRemove the trailing comma | \n
Every ERROR and WARNING MUST include a concrete fix — the corrected value, JSON snippet, or a specific edit instruction (e.g. \"remove the trailing comma\"), not just a restatement of the problem. A finding without an actionable fix is incomplete. This is the single biggest thing that separates a useful validation from a generic lint.
\nClose with the total: \"N error(s), M warning(s), K suggestion(s).\"
\n| Pitfall | \nImpact | \n
|---|---|
| ShortName = \"list\" or \"search\" | \nTemplate can never be created — conflicts with a dotnet new subcommand | \n
Missing sourceName | \n--name MyProject doesn't rename anything in the generated files | \n
Choice parameter without defaultValue | \nConfusing user experience on optional choice params | \n
Invalid datatype value | \nTemplate engine ignores the symbol, causing silent failures | \n
Computed symbol without value | \nTemplate engine throws at instantiation time | \n
Parameter prefix collision (Auth vs AuthMode) | \nAmbiguous expression evaluation | \n
| Source condition without parentheses | \nCondition may not evaluate correctly | \n