Automates the extraction of JIT regression test cases from GitHub issue reports into the JitBlue directory.
Install
mkdir -p .claude/skills/jit-regression-test && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/6808" && unzip -o skill.zip -d .claude/skills/jit-regression-test && rm skill.zipInstalls to .claude/skills/jit-regression-test
Activation
This is the description your AI agent reads to decide when to run this skill — the better it matches your request, the more reliably it fires.
Extract a standalone JIT regression test case from a given GitHub issue and save it under the JitBlue folder. Use this when asked to create or extract a JIT regression test from an issue.Key capabilities
- →Converts issue reproduction code into standalone xunit test files
- →Structures tests according to JitBlue directory conventions
- →Extracts environmental variables required for bug reproduction
- →Applies required.NET Foundation license headers
How it works
It parses input to construct a standard boilerplate class file with the correct naming convention and test entry points.
Inputs & outputs
When to use jit-regression-test
- →Create a JIT regression test
- →Convert issue repro code to test
- →Automate bug reproduction setup
About this skill
JIT Regression Test Extraction
🚨 Do NOT create a test when: the issue has no reproducible code and you cannot compose a minimal repro, the issue is a duplicate of an existing JIT regression test, or the bug is in libraries/runtime rather than the JIT compiler itself.
Extract a JIT regression test case from a GitHub issue into a properly structured test under src/tests/JIT/Regression_*/.
Step 1: Gather Information from the GitHub Issue
From the GitHub issue, extract:
- Issue number → folder/file name (e.g., #99391 →
Runtime_99391) - Reproduction code — if none provided, compose a minimal repro yourself
- Environment variables — any
DOTNET_*vars needed to reproduce - Expected behavior — correct output/behavior
Step 2: Choose the Test Location
For a simple test using optimized compilation without debug information, add the source file directly to:
src/tests/JIT/Regression_ro_2/Runtime_<issue_number>.cs
Regression_ro_2/Regression_ro_2.csproj recursively includes sources in its directory. Do not edit its source list or create a project for the test. Use a Runtime_<issue_number>/ subdirectory only when keeping multiple related files together.
If the test needs its own project (see Step 4), use a separate directory outside the globbed source directories:
src/tests/JIT/Regression_2/Runtime_<issue_number>/
Step 3: Create the Test File
Create a Runtime_<issue_number>.cs file following these conventions:
Example:
// Licensed to the .NET Foundation under one or more agreements.
// The .NET Foundation licenses this file to you under the MIT license.
using System;
using System.Runtime.CompilerServices;
using Xunit;
public class Runtime_<issue_number>
{
[Fact]
public static void TestEntryPoint()
{
// Test code that exercises the bug
// Use Assert.Equal, Assert.True, etc. for validation
}
}
Key Conventions
- License header: Always include the standard .NET Foundation license header
- Class name: Match the file name exactly (
Runtime_<issue_number>) - Test method:
[Fact]attribute, namedTestEntryPoint() - Minimize the reproduction: Strip to the minimal case that triggers the bug
- Use
[MethodImpl(MethodImplOptions.NoInlining)]when preventing inlining is needed to reproduce
Example: Simple Test (from Runtime_99391)
// Licensed to the .NET Foundation under one or more agreements.
// The .NET Foundation licenses this file to you under the MIT license.
namespace Runtime_99391;
using System;
using System.Runtime.CompilerServices;
using System.Numerics;
using Xunit;
public class Runtime_99391
{
[Fact]
public static void TestEntryPoint()
{
Vector2 result2a = Vector2.Normalize(Value2);
Assert.Equal(new Vector2(0, 1), result2a);
}
private static Vector2 Value2
{
[MethodImpl(MethodImplOptions.NoInlining)]
get => new Vector2(0, 2);
}
}
Step 4: Create a .csproj File Only When Required
A custom .csproj file is only required when:
- Environment variables are needed to reproduce the bug (such as
DOTNET_JitStressModeNames) - Special compilation settings are required
- Separate assemblies, native dependencies, or process isolation are required
Otherwise, the source glob in Regression_ro_2.csproj includes the test automatically. Keep custom projects and their sources under src/tests/JIT/Regression_2/Runtime_<issue_number>/. Regression_2/Regression_2.csproj discovers those projects recursively without compiling their sources directly. Do not place them in source-glob directories such as src/tests/JIT/Regression_ro_2/, where they would also be compiled with the runner's settings.
If a custom .csproj file is needed, it should be located next to the test source file with the following name: Runtime_<issue_number>.csproj. Example:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<Optimize>True</Optimize>
<DebugType>None</DebugType>
<!-- Needed for CLRTestEnvironmentVariable -->
<RequiresProcessIsolation>true</RequiresProcessIsolation>
</PropertyGroup>
<ItemGroup>
<Compile Include="$(MSBuildProjectName).cs" />
<CLRTestEnvironmentVariable Include="DOTNET_TieredCompilation" Value="0" />
</ItemGroup>
</Project>
Tips
- No .csproj edits needed for simple tests — add the
.csfile undersrc/tests/JIT/Regression_ro_2/. - Look at recent tests under
src/tests/JIT/Regression_ro_2/for simple tests, orsrc/tests/JIT/Regression_2/Runtime_*for tests with custom projects.
When not to use it
- →For non-JIT compiler bugs
- →When the issue lacks a reproducible code block
- →For performance benchmarks
Prerequisites
Limitations
- →Requires the user to verify the correctness of the generated test code
- →Cannot generate tests for issues that are not reproducible
How it compares
It automates the boilerplate creation and path placement for regression tests instead of manual file scaffolding.
Compared to similar skills
jit-regression-test side by side with the closest alternatives in the catalog.
| Skill | Installs | Updated | Safety | Difficulty |
|---|---|---|---|---|
| jit-regression-test (this skill) | 1 | 7mo | No flags | Beginner |
| performance-benchmark | 3 | 6mo | No flags | Intermediate |
| bug-fix | 4 | 4mo | Review | Advanced |
| mutation-testing | 0 | — | Review | Advanced |
Try saying
Example prompts that trigger this skill in your AI assistant.
More by dotnet
View all by dotnet →You might also like
performance-benchmark
dotnet
Generate and run ad hoc performance benchmarks to validate code changes. Use this when asked to benchmark, profile, or validate the performance impact of a code change in dotnet/runtime.
bug-fix
mono
Fix bugs in SkiaSharp C# bindings. Structured workflow for investigating, fixing, and testing bug reports. Triggers: Crash, exception, AccessViolationException, incorrect output, wrong behavior, memory leak, disposal issues, "fails", "broken", "doesn't work", "investigate issue", "fix issue", "look at #NNNN", any GitHub issue number referencing a bug. For adding new APIs, use `add-api` skill instead.
mutation-testing
SebastienDegodez
Use when running mutation testing, killing mutants, verifying test quality, checking mutation score, or analyzing survivors after the test baseline is green
code-review
yuki7030
VBA・C# のコードレビュー、差分レビュー、PRレビュー依頼時に必ず使用。レビュー観点と報告書式を定義。
dotnet-testing-nsubstitute-mocking
rudironsoni
>
debug-with-valgrind
facet-rs
Debug crashes, segfaults, and memory errors using valgrind integration with nextest through pre-configured profiles