template-instantiation — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited template-instantiation (Agent Skill) and scored it 45/100 (orange). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 7 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 7 flagged
A base64 string of 128+ characters appears in a documentation file. Encoded prompt injection hides the hostile instruction in base64 — invisible to keyword filters — and relies on the agent's ability to decode it at runtime. There is no normal authoring reason to embed a multi-hundred-byte base64 blob in skill docs.
*.sig, SIGNATURES) outside the documentation.A base64 string of 128+ characters appears in a documentation file. Encoded prompt injection hides the hostile instruction in base64 — invisible to keyword filters — and relies on the agent's ability to decode it at runtime. There is no normal authoring reason to embed a multi-hundred-byte base64 blob in skill docs.
*.sig, SIGNATURES) outside the documentation.A base64 string of 128+ characters appears in a documentation file. Encoded prompt injection hides the hostile instruction in base64 — invisible to keyword filters — and relies on the agent's ability to decode it at runtime. There is no normal authoring reason to embed a multi-hundred-byte base64 blob in skill docs.
*.sig, SIGNATURES) outside the documentation.A base64 string of 128+ characters appears in a documentation file. Encoded prompt injection hides the hostile instruction in base64 — invisible to keyword filters — and relies on the agent's ability to decode it at runtime. There is no normal authoring reason to embed a multi-hundred-byte base64 blob in skill docs.
*.sig, SIGNATURES) outside the documentation.A base64 string of 128+ characters appears in a documentation file. Encoded prompt injection hides the hostile instruction in base64 — invisible to keyword filters — and relies on the agent's ability to decode it at runtime. There is no normal authoring reason to embed a multi-hundred-byte base64 blob in skill docs.
*.sig, SIGNATURES) outside the documentation.A base64 string of 128+ characters appears in a documentation file. Encoded prompt injection hides the hostile instruction in base64 — invisible to keyword filters — and relies on the agent's ability to decode it at runtime. There is no normal authoring reason to embed a multi-hundred-byte base64 blob in skill docs.
*.sig, SIGNATURES) outside the documentation.A base64 string of 128+ characters appears in a documentation file. Encoded prompt injection hides the hostile instruction in base64 — invisible to keyword filters — and relies on the agent's ability to decode it at runtime. There is no normal authoring reason to embed a multi-hundred-byte base64 blob in skill docs.
*.sig, SIGNATURES) outside the documentation.Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
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 |
|---|---|---|
| Template name or intent | Yes | Template short name (e.g., webapi) or natural-language description |
| Project name | Yes | Name for the created project |
| Output path | Recommended | Directory where the project should be created |
| Parameters | No | Template-specific parameters (e.g., --framework, --auth, --aot) |
If the user provides a natural-language description, map it to a template short name (see the keyword table in the template-discovery skill). If they provide a template name, proceed directly.
Use dotnet new <template> --help to review available parameters, defaults, and types for any parameters the user did not specify.
When a parameter the user chose implies a value for an unset related parameter, invoke the `template-smart-defaults` skill to resolve the gap before assembling the command line — e.g., native AOT implies a recent AOT-capable target framework, a non-None --auth choice means HTTPS must stay enabled (don't add --no-https), and --use-controllers excludes the minimal-API option. Smart defaults only fill gaps; never let them override a value the user set explicitly. The workspace framework discovered in Step 2 counts as such an explicit value — pass it to smart-defaults as the chosen --framework so it isn't treated as an unset gap; deviate only if it is incompatible with the requested feature/template (then surface the conflict to the user).
Check the existing solution structure before creating:
Directory.Packages.props.csproj filesglobal.json pinning the SDK?This ensures the new project is consistent with the workspace.
Use dotnet new <template> --dry-run to show the user what files would be created. Confirm before proceeding.
dotnet new webapi --name MyApi --framework net10.0 --dry-runUse dotnet new with the template name and all parameters:
dotnet new webapi --name MyApi --output ./src/MyApi --framework net10.0 --auth IndividualBefore running it, emit one compact decision line:
Creating <template> at <path>; framework=<value> (<user|workspace|template>); CPM=<on|off>.
This makes workspace adaptations explicit without adding a long report.
#### Common parameter combinations
| Template | Parameters | Example |
|---|---|---|
webapi | --auth (None, Individual, SingleOrg, Windows), --aot (native AOT) | dotnet new webapi -n MyApi --auth Individual --aot |
webapi | --use-controllers (use controllers vs minimal APIs) | dotnet new webapi -n MyApi --use-controllers |
blazor | --interactivity (None, Server, WebAssembly, Auto), --auth | dotnet new blazor -n MyApp --interactivity Server |
grpc | --aot (native AOT) | dotnet new grpc -n MyService --aot |
worker | --aot (native AOT) | dotnet new worker -n MyWorker --aot |
Note: Use dotnet new <template> --help to see all available parameters for any template.
After creation, adapt the project to Central Package Management and refresh stale versions:
Directory.Packages.props.--no-restore, pass it during creation so package centralization happens first.
<PackageReference Include="X" Version="Y" />, remove the Version attribute (leaving <PackageReference Include="X" />).<PackageVersion Include="X" Version="Y" /> entry in Directory.Packages.props; preserve unrelated existing entries.dotnet list package --outdated and confirm the proposed bumps with the user before changing anything.index.json endpoint for that package ID lists published versions; never select a prerelease unless requested.dotnet build once to restore and confirm the centralized/refreshed versions resolve.For complex structures, create each project sequentially and wire them together:
dotnet new webapi --name MyApi --output ./src/MyApi
dotnet new xunit --name MyApi.Tests --output ./tests/MyApi.Tests
dotnet add ./tests/MyApi.Tests reference ./src/MyApi
dotnet sln add ./src/MyApi ./tests/MyApi.TestsInstall or uninstall template packages:
dotnet new install Microsoft.DotNet.Web.ProjectTemplates.10.0
dotnet new uninstall Microsoft.DotNet.Web.ProjectTemplates.10.0dotnet buildconsole, run the generated app when the request issimple and no external service is required; report the observed output rather than only build success.
dotnet build at the solution levelDirectory.Packages.props has the new entriesdotnet build.csproj has no version attributes and Directory.Packages.props has matching entries| Pitfall | Solution |
|---|---|
| Not checking for CPM before creating a project | If Directory.Packages.props exists, dotnet new creates projects with inline versions that conflict. After creation, move versions to Directory.Packages.props and remove them from .csproj. |
| Letting template restore fail before adapting CPM | Detect CPM first and use the template's --no-restore option when available; centralize versions before the first restore/build. |
| Creating projects without specifying the framework | Always specify --framework when the template supports multiple TFMs to avoid defaulting to an older version. |
| Not adding the project to the solution | After creation, run dotnet sln add to include the project in the solution. |
| Not verifying the project builds | Always run dotnet build after creation to catch missing dependencies or parameter issues early. |
~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.