mtp-hot-reload — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited mtp-hot-reload (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.
Set up and use a long-lived Microsoft Testing Platform host that applies code edits and automatically reruns tests.
run-tests)| Input | Required | Description |
|---|---|---|
| Test project path | No | Path to the test project (.csproj). Defaults to current directory. |
| Failing test name or filter | No | Specific test(s) to iterate on |
return one dotnet run --project <path> command and one sentence explaining that it starts the persistent host. Do not repeat package, launch profile, or rude-edit guidance.
steps. Do not suggest reinstalling it or add optional persistence/recovery paths unless requested.
that framework's filter syntax. Never substitute MSTest/NUnit --filter for xUnit v3 --filter-method or TUnit --treenode-filter.
dotnet runstays alive and the HotReload extension reacts to edits. Do not replace it with dotnet watch run for the normal MTP path; reserve dotnet watch for the explicit restart fallback below.
Hot reload requires MTP. It does not work with VSTest.
Follow the complete evaluated-property procedure in the platform-detection skill. Read imported props and package versions as well as the project file. Do this before installing packages, editing files, or returning an MTP launch command.
Hard stop for VSTest: report that MTP hot reload is unavailable for the project as configured and stop the MTP setup path. Do not install the extension, create launchSettings.json, set the environment variable, change runner properties/packages, or return a dotnet run hot-reload command. Never turn a setup request into an implicit VSTest-to-MTP migration.
Offer one valid non-MTP fallback that preserves the project:
dotnet watch --project <project-path> testThis rebuilds and reruns the existing VSTest project when files change; it is not MTP hot reload. Offer an explicit migration as a separate option, but do not perform it unless the user asks. Exact one-shot test commands remain owned by run-tests.
First inspect the effective package references. If Microsoft.Testing.Extensions.HotReload is already installed, preserve its version and skip this step. Otherwise install it:
dotnet add <project-path> package Microsoft.Testing.Extensions.HotReloadNote: When using Microsoft.Testing.Platform.MSBuild (included transitively by MSTest, NUnit, and xUnit runners), the extension is auto-registered when you install its NuGet package -- no code changes needed.Hot reload is activated by setting the TESTINGPLATFORM_HOTRELOAD_ENABLED environment variable to 1.
Option A -- Set it in the shell before running tests:
# PowerShell
$env:TESTINGPLATFORM_HOTRELOAD_ENABLED = "1"
# bash/zsh
export TESTINGPLATFORM_HOTRELOAD_ENABLED=1Option B -- Add it to `launchSettings.json` (recommended for repeatable use):
Create or update Properties/launchSettings.json in the test project:
{
"profiles": {
"<ProjectName>": {
"commandName": "Project",
"environmentVariables": {
"TESTINGPLATFORM_HOTRELOAD_ENABLED": "1"
}
}
}
}Run the test project directly (not through dotnet test) to use hot reload in console mode:
dotnet run --project <project-path>To filter to specific failing tests, pass the filter after --. Read the supplied or runtime-listed filter-syntax catalog file only when the examples below do not resolve the framework's syntax; do not invoke this reference-only helper. Quick examples:
| Framework | Filter syntax |
|---|---|
| MSTest | dotnet run --project <path> -- --filter "FullyQualifiedName~TestMethodName" |
| NUnit | dotnet run --project <path> -- --filter "FullyQualifiedName~TestMethodName" |
| xUnit v3 | dotnet run --project <path> -- --filter-method "*TestMethodName" |
| TUnit | dotnet run --project <path> -- --treenode-filter "/*/*/ClassName/TestMethodName" |
The test host will start, run the tests, and remain running waiting for code changes.
Important: Hot reload currently works in console mode only. There is no support for hot reload in Test Explorer for Visual Studio or Visual Studio Code.
#### Unsupported edits and rude edits
Method-signature changes, new types, and other unsupported edits cannot be applied to the active process. Never imply that the stale host picked them up.
For a directly launched MTP host:
started the current host.
Ctrl+C.dotnet build <project-path>.invocation with a generic dotnet run command.
If repeated unsupported edits are expected, offer a watch-managed restart fallback:
# PowerShell
$env:TESTINGPLATFORM_HOTRELOAD_ENABLED = "1"
$env:DOTNET_WATCH_RESTART_ON_RUDE_EDIT = "1"
dotnet watch --project <project-path> run -- <existing-MTP-arguments>dotnet watch restarts the process when a rude edit cannot be applied. Without the auto-restart variable, accept the restart prompt or press Ctrl+R. Preserve any existing test filter after --. DOTNET_WATCH_RESTART_ON_RUDE_EDIT is a documented .NET SDK switch, not an MTP extension setting. When correctness may be questioned, cite the dotnet watch documentation and say that it makes the watcher restart instead of prompting. Never omit the original filter or replace the requested watch-managed fallback with a one-shot dotnet run.
Once all tests pass:
run-tests when the user requests an exact one-shot validation command,flags, filter, TRX, or dump
TESTINGPLATFORM_HOTRELOAD_ENABLED from the environment or keep launchSettings.json for future useMicrosoft.Testing.Extensions.HotReload package is installedTESTINGPLATFORM_HOTRELOAD_ENABLED environment variable is set to 1| Pitfall | Solution |
|---|---|
Using dotnet test instead of dotnet run | Hot reload requires dotnet run --project <path> to run the test host directly in console mode |
| Project uses VSTest, not MTP | Do not mutate it. Offer dotnet watch --project <path> test as a rebuild/rerun fallback or a separate explicit migration |
| Forgetting to set the environment variable | Set TESTINGPLATFORM_HOTRELOAD_ENABLED=1 before running |
| Expecting Test Explorer integration | Console mode only -- no VS/VS Code Test Explorer support |
| Making unsupported code changes (rude edits) | Stop, rebuild, and rerun the same host invocation, or use dotnet watch with restart-on-rude-edit behavior |
~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.