Guides creation and validation of custom dotnet new templates from existing projects.
Template Validation
Validates custom dotnet new templates for correctness before publishing. Catches missing fields, parameter bugs, shortName conflicts, constraint issues, and common authoring mistakes that cause templates to fail silently. USE FOR: checking template.json files for errors before publishing or testing, diagnosing why a template doesn't appear after installation, reviewing template parameter definitions for type mismatches and missing defaults, finding shortName conflicts with dotnet CLI commands, validating post-action and constraint configuration. DO NOT USE FOR: finding or using existing templates (use template-discovery), creating projects from templates (use template-instantiation), creating templates from existing projects (use template-authoring).
Workflow
Step 1: Locate the template.json
The file can be at:
- Direct path:
path/to/template.json - In a template directory:
path/to/.template.config/template.json - In a
.template.configdirectory:path/.template.config/template.json
Step 2: Parse and validate
Read the JSON. If it's malformed, report the JSON parse error with line and column. If an absolute-path read fails, retry the user-supplied relative path from the working directory before concluding the file is unavailable.
Only after parsing succeeds, run all 8 validation categories above. Collect errors, warnings, and suggestions separately. Verify schema-sensitive claims against the installed SDK or the current template-engine schema; do not infer a runtime failure from a field name alone.
Step 3: Report results
Lead with a one-line verdict, then a single findings table. This decisive shape is required — do not scatter findings across prose paragraphs.
Verdict header (pick one):
❌ 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:
| Severity | Location (JSON path or line:col) | Issue | Fix | |----------|------------------------------------|-------|-----| | ERROR | shortName | "list" conflicts with a dotnet new subcommand | Rename to a distinctive value, e.g. "my-list" | | ERROR | symbols.maxRetries.defaultValue | "abc" is not a valid int | Set a numeric default, e.g. "3" | | WARNING | sourceName | Missing replacement token | Set it to the source project name |
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.
Close with the total: "N error(s), M warning(s), K suggestion(s)."
For malformed JSON the output is intentionally smaller and has exactly two parts:
❌ Not ready — JSON parse error at line N, column M: <message>.
<smallest corrected fragment showing the exact edit>Do not append a findings table or semantic totals until the corrected file parses.
Related skills
Compares two or more dotnet new templates side by side to help users choose between them based on parameters, feature support, frameworks, and classifications.
Helps find, inspect, and compare (at a high level) .NET project templates.