Add ASP.NET end-to-end benchmarking skill and clarify microbenchmark scope

.github/copilot-instructions.md

@@ -16,7 +16,7 @@ Use the `code-review` skill when reviewing pull requests, and — when running u
 
 When starting work in an unfamiliar directory, search for `README.md` files in it and its parents up to the repository root. Read any you find — they contain conventions, patterns, and architectural context relevant to your work.
 
-If the changes are intended to improve performance, or if they could negatively impact performance, use the `performance-benchmark` skill to validate the impact before completing.
+If the changes are intended to improve performance, or if they could negatively impact performance, use the `microbenchmark` skill for method/API-level measurements or the `aspnet-benchmark` skill for end-to-end ASP.NET Core/HTTP server load testing.
 
 When writing or reviewing SIMD / hardware-intrinsics code (anything using `Vector128`/`Vector256`/`Vector512`, `Vector<T>`, or the platform intrinsics in `System.Runtime.Intrinsics.*`), use the `vectorization` skill.
 

.github/skills/api-proposal/SKILL.md

@@ -177,7 +177,7 @@ This:
 
 2. **All errors and warnings must be fixed** before proceeding to the draft phase.
 
-3. If the API change could affect performance (hot paths, allocations, new collection types), suggest running the **performance-benchmark** skill.
+3. If the API change could affect performance (hot paths, allocations, new collection types), suggest running the **microbenchmark** skill.
 
 4. Re-run tests after any review-driven changes to confirm nothing regressed.
 

.github/skills/build-and-test/SKILL.md

@@ -5,7 +5,7 @@ description: >
   per-component build and test commands, Windows/PowerShell equivalents, running
   individual tests, and troubleshooting. USE FOR: any build or test invocation in
   this repo, and before making code changes under CCA. DO NOT USE FOR: CI pipeline
-  triage (use ci-pipeline-monitor) or benchmarking (use performance-benchmark).
+  triage (use ci-pipeline-monitor) or benchmarking (use microbenchmark for method/API-level measurements or aspnet-benchmark for end-to-end ASP.NET Core/HTTP load testing).
 ---
 
 # Building & Testing in dotnet/runtime

.github/skills/issue-triage/SKILL.md

@@ -483,5 +483,5 @@ After triage, these skills can help with next steps:
 
 - **api-proposal** -- if an API proposal is recommended as KEEP, offer to draft a formal proposal with working prototype.
 - **jit-regression-test** -- if a bug with root cause is JIT-related, offer to create a regression test.
-- **performance-benchmark** -- if a performance regression is confirmed, offer to validate with ad hoc benchmarks.
+- **microbenchmark** -- if a performance regression is confirmed, offer to validate with ad hoc benchmarks.
 - **code-review** -- if a fix PR is linked, offer to review for correctness and consistency.

.github/skills/jit-regression-test/SKILL.md

@@ -7,7 +7,7 @@ description: >
   bug", "create a regression test for issue #NNNNN", converting issue repro to
   xunit test. DO NOT USE FOR: non-JIT tests (use standard test patterns),
   debugging JIT issues without a known repro, performance benchmarks (use
-  performance-benchmark skill).
+  microbenchmark skill).
 ---
 
 # JIT Regression Test Extraction

.github/skills/performance-benchmark/SKILL.md → .github/skills/microbenchmark/SKILL.md

@@ -1,9 +1,9 @@
 ---
-name: performance-benchmark
-description: 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.
+name: microbenchmark
+description: Generate and run ad hoc BenchmarkDotNet microbenchmarks to validate the performance impact of a code change. Use this when asked to benchmark, profile, or validate the performance impact of a code change in dotnet/runtime at the method/API level. For end-to-end ASP.NET Core / HTTP server load testing, use the aspnet-benchmark skill instead.
 ---
 
-# Ad Hoc Performance Benchmarking Locally (or with @EgorBot)
+# Ad Hoc Microbenchmarking Locally (or with @EgorBot)
 
 When you need to validate the performance impact of a code change, follow this process to write a BenchmarkDotNet benchmark and compare local baseline and changed builds.
 

.github/skills/vectorization/SKILL.md

@@ -6,7 +6,7 @@ description: >
   code that uses Vector128/Vector256/Vector512, Vector<T>, or the platform
   intrinsics in System.Runtime.Intrinsics.X86/Arm/Wasm, and validating remainder
   handling, load/store safety, and hardware-acceleration fallbacks. DO NOT USE
-  FOR: general performance work unrelated to SIMD (use performance-benchmark),
+  FOR: general performance work unrelated to SIMD (use microbenchmark),
   or non-vectorized code review (use code-review).
 ---
 
@@ -93,7 +93,7 @@ and the same `DOTNET_Enable*` variables to compare scalar / `Vector128` / `Vecto
 in mind: larger inputs benefit more (small buffers can be *slower* due to setup), speedups are rarely
 the theoretical multiple (memory throughput, alignment, and latency all factor in), and randomized
 allocation alignment adds noise — allocate aligned memory or enable BenchmarkDotNet's randomization for
-stable/observable results. For non-trivial changes, use the `performance-benchmark` skill.
+stable/observable results. For non-trivial changes, use the `microbenchmark` skill.
 
 ## Review checklist