Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →dotnet/template-instantiation
Creates .NET projects from templates with validated parameters, smart defaults, Central Package Management adaptation, and latest NuGet version resolution. USE FOR: creating new dotnet projects, scaffolding solutions with multiple projects, installing or uninstalling template packages, creating projects that respect Directory.Packages.props (CPM), composing multi-project solutions (API + tests + library), getting latest NuGet package versions in newly created projects. DO NOT USE FOR: finding te
Passed 7 of 13 test cases with the skill, and 10 of 13 without it.
2 fixed11 passed either way4 still failing6 broke
Tokens, turns and time describe resource use, not a dollar price.
One of 2 test cases the skill fixed. Same model, same prompt, with and without the skill.
The user specifically requested creating a solution file named `EnterpriseApp.sln`. How should the format option be determined and passed when running the template command?
| Checked | Without skill | With skill |
|---|---|---|
| Inspects dotnet new sln help output for format parameters | Missed | Passed |
| Passes --format sln when supported by the installed SDK | Missed | Passed |
The instructions your model reads when the skill loads.
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.
Match the workspace, then stop. The highest-value move is aligning the new project with the repo it lands in: detect CPM (
Directory.Packages.props) and the target framework used by neighbouring.csprojfiles, and mirror both. Treat the discovered target framework as an explicit choice — pass it as--frameworksotemplate-smart-defaultswon't override it; deviate only when it's incompatible with a requested feature (then flag the conflict). Do this in as few steps as possible — a--dry-run, the create, and onedotnet buildto confirm is usually enough. Extra exploratory turns add cost without improving the result.
Perform the requested creation. Do not return only a plan or statement of intent. Run state-dependent commands sequentially: inspect, dry-run, create, then build. Never launch create and build in parallel; a build-before-create race produces a false failure.
| Situation | Required action |
|---|---|
| Simple standalone project | inspect only the requested template, create at the exact path, then build |
| Existing neighboring projects | read their TFMs first and pass the matching supported --framework explicitly |
Directory.Packages.props found | create with --no-restore when supported, normalize generated package references, then restore/build once |
| Multi-project solution | create each project at its final path, add references, add all projects to the solution, then build the solution once |
User explicitly requests .sln | inspect dotnet new sln --help; pass --format sln when supported, otherwise use the older SDK's default .sln output |
Do not predict the generated target framework. If the user and workspace do not supply one,
inspect dotnet new <template> --help, choose a supported value (normally its documented
default), pass it explicitly, then confirm the generated .csproj. Never announce an
intermediate framework guess that was not grounded in the template's current choices.
Directory.Packages.propstemplate-discovery skill; for a detailed side-by-side comparison — route to template-comparison skilltemplate-authoring skilldotnet add package directly| Input | Required | Description |
|---|
test cases passed, vs 10 / 13 without
Published skills whose descriptions closely match this one, with their headline benchmark lift.
More skills from the same source and nearby in the registry, with their headline benchmark lift.