Add standalone runtime test repro skills

[jkoritzinsky]

Runtime CI failures often identify tests through generated wrapper paths or fully qualified methods. Reproducing them requires preserving project-specific environment variables and named stress scenarios while producing an editable source-level app that runs directly with corerun.

Summary

• Add a shared workflow that extracts managed src/tests tests into standalone console applications runnable with corerun.
• Split wrapper-path and fully qualified method resolution into focused skills.
• Add scenario environment generation backed by src/tests/Common/testenvironment.proj.
• Merge scenario variables with evaluated CLRTestEnvironmentVariable values in runtime-wrapper order, with project settings taking precedence.

Validation

• The repository skill validator passed all 20 registered skills.
• A deterministic fleet run (seed 20260812) selected 100 unique Windows x64-compatible tests across 45 projects against a Debug Core_Root with Release libraries.
• All 45 projects built successfully.
• Clean lightweight workers generated every source-level repro, compared it with the exact selected source method and required project contract, ran the exact original method, and independently reran the standalone output.
• All 100 original methods and all 100 standalone repros exited with the expected code 100.
• The set included five tests marked RequiresProcessIsolation = true (indices 37, 47, 65, 86, and 93); each original and repro ran in its own corerun process.
• Applicable .env settings and local native dependencies were preserved and exercised.
• One initially selected arm64/SVE-only test was replaced with the next deterministic eligible x64 test, retaining 100 unique tests and five isolation cases.

Note

This pull request description was generated by GitHub Copilot.

[azure-pipelines]

Azure Pipelines:
Successfully started running 1 pipeline(s).
15 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[Copilot]

Pull request overview

This PR adds new GitHub Copilot skills under .github/skills/ to help turn managed src/tests CoreCLR tests into standalone, editable console repro apps runnable with corerun, including scenario-aware environment generation via testenvironment.proj.

Changes:

• Add test-scenario-env skill to evaluate src/tests/Common/testenvironment.proj via MSBuild and produce a CoreRun-compatible .env, optionally merged with a test project’s CLRTestEnvironmentVariable items.
• Add standalone-test-repro skill plus two resolution sub-skills (-cmd and -method) to map wrappers / fully qualified test methods to an owning project + source method, then guide extraction into artifacts/tmp.
• Document wrapper-order env merging semantics (scenario first, project items second) and fidelity checks for the resulting repro.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 3 comments.

File	Description
.github/skills/test-scenario-env/SKILL.md	New skill spec for generating a CoreRun dotenv file from testenvironment.proj and optionally merging project env items.
.github/skills/standalone-test-repro/SKILL.md	New end-to-end workflow spec to extract a single managed runtime test into a standalone repro app under artifacts/tmp.
.github/skills/standalone-test-repro-method/SKILL.md	New sub-skill spec for resolving a test from a fully qualified method name / xUnit display name.
.github/skills/standalone-test-repro-cmd/SKILL.md	New sub-skill spec for resolving a test from a generated .cmd/.sh wrapper path and capturing effective invocation.

[Copilot]

Pull request overview

Copilot reviewed 4 out of 4 changed files in this pull request and generated no new comments.

Suppressed comments (3)

.github/skills/test-scenario-env/SKILL.md:74

• The MSBuild example passes /p:TestEnvFileName=<temporary.sh> without a path, but the preceding text says the temporary script should be generated under the resolved output directory. Unless the working directory is changed, MSBuild will write this file relative to the current directory, not the output directory. Use an explicit (and quoted) path so the temp script location is deterministic.

./dotnet.sh msbuild src/tests/Common/testenvironment.proj /t:CreateTestEnvFile /p:Scenario=<scenario> /p:TestEnvFileName=<temporary.sh> /p:TargetsWindows=false /p:RuntimeVariant=<variant>

.github/skills/test-scenario-env/SKILL.md:68

• The MSBuild example passes /p:TestEnvFileName=<temporary.cmd> without a path, but the preceding text says the temporary script should be generated under the resolved output directory. Unless the working directory is changed, MSBuild will write this file relative to the current directory (likely the repo root), not the output directory. Use an explicit (and quoted) path so the temp script location is deterministic.

This issue also appears on line 74 of the same file.

.\dotnet.cmd msbuild src\tests\Common\testenvironment.proj /t:CreateTestEnvFile /p:Scenario=<scenario> /p:TestEnvFileName=<temporary.cmd> /p:TargetsWindows=true /p:RuntimeVariant=<variant>

.github/skills/test-scenario-env/SKILL.md:103

• Dotenv values can’t escape $ via backslash in CoreRun’s parser, and variable expansion is only supported as ${NAME} and is disabled only by quoting the entire value with single quotes. The current wording (“single-quote escaping”) is ambiguous and could be read as escaping just the $. Consider clarifying that the whole value should be single-quoted (and how to escape embedded ').

- Preserve non-expansion format tokens such as `%d`. Protect a literal `$` with
  single-quote escaping so CoreRun does not interpret it as substitution.