[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill-dotnet-microbenchmarking":3,"mdc-os8747-key":31,"related-repo-dotnet-microbenchmarking":1110,"related-org-dotnet-microbenchmarking":1219},{"slug":4,"name":4,"fn":5,"description":6,"org":7,"tags":11,"stars":19,"repoUrl":20,"updatedAt":21,"license":22,"forks":23,"topics":24,"repo":26,"sourceUrl":29,"mdContent":30},"microbenchmarking","run and configure .NET microbenchmarks","Activate this skill when BenchmarkDotNet (BDN) is involved in the task — creating, running, configuring, or reviewing BDN benchmarks. Also activate when microbenchmarking .NET code would be useful and BenchmarkDotNet is the likely tool. Consider activating when answering a .NET performance question requires measurement and BenchmarkDotNet may be needed. Covers microbenchmark design, BDN configuration and project setup, how to run BDN microbenchmarks efficiently and effectively, and using BDN for side-by-side performance comparisons. Do NOT use for profiling\u002Ftracing .NET code (dotnet-trace, PerfView), production telemetry, or load\u002Fstress testing (Crank, k6).\n",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},"dotnet",".NET (Microsoft)","https:\u002F\u002Fpexgzepcugksgbtrxkhf.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Forg-logos\u002Fdotnet.png",[12,16],{"name":13,"slug":14,"type":15},"Performance","performance","tag",{"name":17,"slug":18,"type":15},".NET","net",4576,"https:\u002F\u002Fgithub.com\u002Fdotnet\u002Fskills","2026-07-12T08:23:18.668484","MIT",332,[25],"agent-skills",{"repoUrl":20,"stars":19,"forks":23,"topics":27,"description":28},[25],"Repository for skills to assist AI coding agents with .NET and C#","https:\u002F\u002Fgithub.com\u002Fdotnet\u002Fskills\u002Ftree\u002FHEAD\u002Fplugins\u002Fdotnet-diag\u002Fskills\u002Fmicrobenchmarking","---\nname: microbenchmarking\ndescription: >\n  Activate this skill when BenchmarkDotNet (BDN) is involved in the task — creating,\n  running, configuring, or reviewing BDN benchmarks. Also activate when\n  microbenchmarking .NET code would be useful and BenchmarkDotNet is the likely\n  tool. Consider activating when answering a .NET performance question requires\n  measurement and BenchmarkDotNet may be needed.\n  Covers microbenchmark design, BDN configuration and project setup, how to run\n  BDN microbenchmarks efficiently and effectively, and using BDN for side-by-side\n  performance comparisons.\n  Do NOT use for profiling\u002Ftracing .NET code (dotnet-trace, PerfView), production\n  telemetry, or load\u002Fstress testing (Crank, k6).\nlicense: MIT\n---\n\n# Benchmark Authoring Guidelines\n\nBenchmarkDotNet (BDN) is a .NET library for writing and running microbenchmarks. Throughout this skill, \"BDN\" refers to BenchmarkDotNet.\n\n> **Note:** Evaluations of LLMs writing BenchmarkDotNet benchmarks have revealed common failure patterns caused by outdated assumptions about BDN's behavior — particularly around runtime comparison, job configuration, and execution defaults that have changed in recent versions. The reference files in this skill contain verified, current information. **You MUST read the reference files relevant to the task before writing any code** — your training data likely contains outdated or incorrect BDN patterns.\n\n## Key concepts\n\n- **Job** — describes how to run a benchmark: runtime, iteration counts, launch count, run strategy, and environment settings. Multiple jobs can be configured to run the same benchmarks under different conditions.\n- **Benchmark case** — one method × one parameter combination × one job. The atomic unit BDN measures.\n- **Operation** — the logical unit of work being measured. All BDN output columns (Mean, Error, etc.) report time per operation.\n- **Invocation** — a single call to the benchmark method. By default, 1 invocation = 1 operation. With `OperationsPerInvoke=N`, each invocation counts as N operations.\n- **Iteration** — a timed batch of invocations. BDN measures the total time for all invocations in an iteration, then divides by the total operation count to get per-operation time.\n\n## Benchmarks are comparative instruments\n\nA single benchmark number has limited value — it can confirm the order of magnitude of a measurement, but the exact value changes across machines, operating systems, and runtime configurations. Benchmarks produce the most useful information when compared against something. Before writing benchmarks, identify the **comparison axis** for the current task:\n\n- **Approaches (A vs B)**: comparing alternative implementations side-by-side in the same run.\n- **Runtimes**: comparing the same code across .NET versions (e.g., net8.0 vs net9.0).\n- **Package versions**: comparing different versions of a NuGet dependency.\n- **Builds (before\u002Fafter)**: comparing a saved DLL of the old code against the current source.\n- **Runtime configuration (GC mode, JIT settings)**: understanding how runtime settings affect performance — compared via multiple jobs in a single run.\n- **Scale (N=100 vs N=1000)**: understanding how performance changes as input size grows.\n- **Hardware\u002FOS**: comparing across different machines or operating systems — requires separate runs on each environment.\n- **Historical measurements**: comparing against measurements recorded at a previous point in time.\n\nBDN can compare the first six axes side-by-side in a single run, but each requires specific CLI flags or configuration that differ from what you might expect — read [references\u002Fcomparison-strategies.md](references\u002Fcomparison-strategies.md) for the correct approach for each strategy before configuring a comparison.\n\n## Use cases and benchmark lifecycle\n\nThere are four distinct reasons a developer writes a benchmark, and each one changes how the benchmark should be designed and where it should live:\n\n1. **Coverage suite**: Write benchmarks to maximize coverage of real-world usage patterns so that regressions affecting most users are caught. These benchmarks are permanent — they belong in the project's benchmark suite, follow its conventions (directory structure, base classes, naming), and are checked in.\n\n2. **Issue investigation**: Someone has reported a specific performance problem. Write benchmarks to reproduce and diagnose that specific issue. These benchmarks are task-scoped — they persist across the investigation (reproduce → isolate → verify fix) but are not part of the permanent suite.\n\n3. **Change validation**: A developer has a PR or change and wants to understand its performance characteristics before merging. These benchmarks are task-scoped — they persist across the review cycle but are not checked in.\n\n4. **Development feedback**: A developer is actively working on a task and wants to use benchmarks to evaluate approaches and get information early. These benchmarks are task-scoped and throwaway — they persist across the development session but are deleted when the decision is made.\n\nFor use case 1, add to the existing benchmark project following its conventions. For use cases 2–4, create a standalone project in a working directory that persists for the task but is clearly not part of the permanent codebase.\n\nFor **coverage suite** benchmarks, design from the perspective of real callers — what code patterns use this API, what inputs they pass, and what performance characteristics matter to them. Each permanent benchmark should justify its maintenance cost through real-world relevance. For **temporary benchmarks**, keep the case count intentional — each additional test case costs wall-clock time (read [Cost awareness](#cost-awareness)).\n\n## Cost awareness\n\nEach benchmark case (one method × one parameter combination × one job) takes **15–25 seconds** with default settings. `[Params]` creates a Cartesian product: two `[Params]` with 3 and 4 values across 5 methods = 60 cases ≈ 20 minutes. Multiple jobs multiply this further. Before running, estimate the total case count and match the job preset to the situation:\n\n| Preset | Per-case time | When to use |\n|--------|--------------|-------------|\n| `--job Dry` | \u003C1s | Validate correctness — confirms compilation and execution without measurement |\n| `--job Short` | 5–8s | Quick measurements during development or investigation |\n| *(default)* | 15–25s | Final measurements for a coverage suite |\n| `--job Medium` | 33–52s | Higher confidence when results matter |\n| `--job Long` | 3–12 min | High statistical confidence |\n\nIf benchmark runs take longer than expected, results seem unstable, or you need to tune iteration counts or execution settings, read [references\u002Fbdn-internals-and-tuning.md](references\u002Fbdn-internals-and-tuning.md) for detailed information about BDN's execution pipeline and configuration options.\n\n## Entry points and configuration\n\nBDN programs use either **`BenchmarkSwitcher`** (provides interactive benchmark selection for humans, parses CLI arguments) or **`BenchmarkRunner`** (runs specified benchmarks directly). Both support CLI flags like `--filter` and `--runtimes`, but only when `args` is passed through — without it, CLI flags are silently ignored. When using `BenchmarkSwitcher`, always pass `--filter` to avoid hanging on an interactive prompt.\n\nBDN behavior is customized through **attributes**, **config objects**, and **CLI flags**.\n\nRead [references\u002Fproject-setup-and-running.md](references\u002Fproject-setup-and-running.md) for entry point setup, config object patterns, and CLI flags. If you need to collect data beyond wall-clock time — such as memory allocations, hardware counters, or profiling traces — read [references\u002Fdiagnosers-and-exporters.md](references\u002Fdiagnosers-and-exporters.md).\n\n## Running benchmarks\n\nBenchmarkDotNet console output is extremely verbose — hundreds of lines per case showing internal calibration, warmup, and measurement details. Redirect all output to a file to avoid consuming context on verbose iteration output:\n\n```\ndotnet run -c Release -- --filter \"*MethodName\" --noOverwrite > benchmark.log 2>&1\n```\n\nEach benchmark method can take several minutes. Rather than running all benchmarks at once, use `--filter` to run a subset at a time (e.g. one or two methods per invocation), read the results, then run the next subset. This keeps each invocation short — avoiding session or terminal timeouts — and lets you verify results incrementally. Read [references\u002Fproject-setup-and-running.md](references\u002Fproject-setup-and-running.md) for filter syntax, CLI flags, and project setup.\n\nAfter each run, read the Markdown report (`*-report-github.md`) from the results directory for the summary table. Only read `benchmark.log` if you need to investigate errors or unexpected results.\n\n## Writing new benchmarks\n\n### Step 1: Plan the test cases\n\nBefore writing any code, determine:\n- Which use case this benchmark serves (coverage, investigation, change validation, or development feedback).\n- Which comparison axis applies (what will the number be compared against?).\n- What real-world scenarios to benchmark, based on how callers actually use the API.\n\nEach benchmark case should justify its cost. An uncovered scenario is usually more valuable than another parameter combination for one already covered, but when a specific parameter dimension genuinely affects performance characteristics, the depth is warranted.\n\nDecide on the list of test cases. For each test case, think through:\n\n- **How to express variation**: BenchmarkDotNet provides several mechanisms for parameterizing benchmarks — `[Params]` and `[ParamsSource]` for property-level parameters, `[Arguments]` and `[ArgumentsSource]` for method-level arguments, `[ParamsAllValues]` to enumerate all values of a `bool` or enum, and `[GenericTypeArguments]` for varying type parameters on generic benchmark classes. Choose the mechanism that best fits the dimension being varied. Read [references\u002Fwriting-benchmarks.md](references\u002Fwriting-benchmarks.md) for the full set of options and correctness patterns.\n- **Where input data comes from** — consider which sources are appropriate (these can be combined):\n  - Hard-coded values — small, fixed values where the exact input matters (e.g., specific strings, known edge-case sizes). Store in fields or `[Params]` to avoid constant folding.\n  - Asset files — static data that is too large or impractical to embed in source code such as binary blobs.\n  - Programmatically generated via `[ParamsSource]`\u002F`[ArgumentsSource]`\u002F`[GlobalSetup]` — when data shape matters more than specific content, or when input must be parameterized by size.\n- **Whether randomness is appropriate**: If using generated data, use seeded randomness for reproducibility. When generating random data, use a large enough sample that the generated distribution is representative (e.g., 4 random values may cluster in a narrow range, while 1000 will better exercise the full distribution).\n\n### Step 2: Implement the benchmarks\n\nFor **coverage suite** benchmarks, add to the existing benchmark project and follow its conventions. For **temporary benchmarks** (investigation, change validation, development feedback), create a standalone project — read [references\u002Fproject-setup-and-running.md](references\u002Fproject-setup-and-running.md) for project setup and entry point configuration.\n\n**Adding the BenchmarkDotNet package**: Always use `dotnet add package BenchmarkDotNet` (no version) — this lets NuGet resolve the latest compatible version. Do NOT manually write a `\u003CPackageReference>` with a version number into the `.csproj`; BDN versions in training data are outdated and may lack support for current .NET runtimes.\n\nWrite the benchmark code. Follow the patterns in [references\u002Fwriting-benchmarks.md](references\u002Fwriting-benchmarks.md) to avoid common measurement errors — in particular:\n- **Return results** from benchmark methods to prevent dead code elimination\n- **Move initialization to `[GlobalSetup]`** — setup inside the benchmark method is measured; use `[IterationSetup]` only when the benchmark mutates state that must be reset between iterations\n- **Do not add manual loops** — BDN controls invocation count automatically\n- **Mark a baseline** when comparing alternatives — use `[Benchmark(Baseline = true)]` for method-level comparisons or `.AsBaseline()` on a job for multi-job comparisons so results show relative ratios\n- **Store inputs in fields or `[Params]`**, not as literals or `const` values — the JIT can fold constant expressions at compile time, making the benchmark measure a precomputed result instead of the actual computation\n\n### Step 3: Validate and run\n\nValidate before committing to a long run:\n\n1. Run with `--job Dry` first to catch compilation errors and runtime exceptions without spending time on measurement.\n2. Run a single representative case with default settings to verify the output looks correct and the numbers are in the expected range.\n3. Only run the full suite after validation passes.\n\nWhen iterating on benchmark design, use `--job Short` until confident, then switch to default for final numbers.\n",{"data":32,"body":33},{"name":4,"description":6,"license":22},{"type":34,"children":35},"root",[36,45,51,73,80,144,150,162,245,258,264,269,313,318,345,350,377,520,532,538,603,629,647,653,658,670,688,709,715,722,727,745,750,755,894,900,922,956,967,1062,1068,1073,1098],{"type":37,"tag":38,"props":39,"children":41},"element","h1",{"id":40},"benchmark-authoring-guidelines",[42],{"type":43,"value":44},"text","Benchmark Authoring Guidelines",{"type":37,"tag":46,"props":47,"children":48},"p",{},[49],{"type":43,"value":50},"BenchmarkDotNet (BDN) is a .NET library for writing and running microbenchmarks. Throughout this skill, \"BDN\" refers to BenchmarkDotNet.",{"type":37,"tag":52,"props":53,"children":54},"blockquote",{},[55],{"type":37,"tag":46,"props":56,"children":57},{},[58,64,66,71],{"type":37,"tag":59,"props":60,"children":61},"strong",{},[62],{"type":43,"value":63},"Note:",{"type":43,"value":65}," Evaluations of LLMs writing BenchmarkDotNet benchmarks have revealed common failure patterns caused by outdated assumptions about BDN's behavior — particularly around runtime comparison, job configuration, and execution defaults that have changed in recent versions. The reference files in this skill contain verified, current information. ",{"type":37,"tag":59,"props":67,"children":68},{},[69],{"type":43,"value":70},"You MUST read the reference files relevant to the task before writing any code",{"type":43,"value":72}," — your training data likely contains outdated or incorrect BDN patterns.",{"type":37,"tag":74,"props":75,"children":77},"h2",{"id":76},"key-concepts",[78],{"type":43,"value":79},"Key concepts",{"type":37,"tag":81,"props":82,"children":83},"ul",{},[84,95,105,115,134],{"type":37,"tag":85,"props":86,"children":87},"li",{},[88,93],{"type":37,"tag":59,"props":89,"children":90},{},[91],{"type":43,"value":92},"Job",{"type":43,"value":94}," — describes how to run a benchmark: runtime, iteration counts, launch count, run strategy, and environment settings. Multiple jobs can be configured to run the same benchmarks under different conditions.",{"type":37,"tag":85,"props":96,"children":97},{},[98,103],{"type":37,"tag":59,"props":99,"children":100},{},[101],{"type":43,"value":102},"Benchmark case",{"type":43,"value":104}," — one method × one parameter combination × one job. The atomic unit BDN measures.",{"type":37,"tag":85,"props":106,"children":107},{},[108,113],{"type":37,"tag":59,"props":109,"children":110},{},[111],{"type":43,"value":112},"Operation",{"type":43,"value":114}," — the logical unit of work being measured. All BDN output columns (Mean, Error, etc.) report time per operation.",{"type":37,"tag":85,"props":116,"children":117},{},[118,123,125,132],{"type":37,"tag":59,"props":119,"children":120},{},[121],{"type":43,"value":122},"Invocation",{"type":43,"value":124}," — a single call to the benchmark method. By default, 1 invocation = 1 operation. With ",{"type":37,"tag":126,"props":127,"children":129},"code",{"className":128},[],[130],{"type":43,"value":131},"OperationsPerInvoke=N",{"type":43,"value":133},", each invocation counts as N operations.",{"type":37,"tag":85,"props":135,"children":136},{},[137,142],{"type":37,"tag":59,"props":138,"children":139},{},[140],{"type":43,"value":141},"Iteration",{"type":43,"value":143}," — a timed batch of invocations. BDN measures the total time for all invocations in an iteration, then divides by the total operation count to get per-operation time.",{"type":37,"tag":74,"props":145,"children":147},{"id":146},"benchmarks-are-comparative-instruments",[148],{"type":43,"value":149},"Benchmarks are comparative instruments",{"type":37,"tag":46,"props":151,"children":152},{},[153,155,160],{"type":43,"value":154},"A single benchmark number has limited value — it can confirm the order of magnitude of a measurement, but the exact value changes across machines, operating systems, and runtime configurations. Benchmarks produce the most useful information when compared against something. Before writing benchmarks, identify the ",{"type":37,"tag":59,"props":156,"children":157},{},[158],{"type":43,"value":159},"comparison axis",{"type":43,"value":161}," for the current task:",{"type":37,"tag":81,"props":163,"children":164},{},[165,175,185,195,205,215,225,235],{"type":37,"tag":85,"props":166,"children":167},{},[168,173],{"type":37,"tag":59,"props":169,"children":170},{},[171],{"type":43,"value":172},"Approaches (A vs B)",{"type":43,"value":174},": comparing alternative implementations side-by-side in the same run.",{"type":37,"tag":85,"props":176,"children":177},{},[178,183],{"type":37,"tag":59,"props":179,"children":180},{},[181],{"type":43,"value":182},"Runtimes",{"type":43,"value":184},": comparing the same code across .NET versions (e.g., net8.0 vs net9.0).",{"type":37,"tag":85,"props":186,"children":187},{},[188,193],{"type":37,"tag":59,"props":189,"children":190},{},[191],{"type":43,"value":192},"Package versions",{"type":43,"value":194},": comparing different versions of a NuGet dependency.",{"type":37,"tag":85,"props":196,"children":197},{},[198,203],{"type":37,"tag":59,"props":199,"children":200},{},[201],{"type":43,"value":202},"Builds (before\u002Fafter)",{"type":43,"value":204},": comparing a saved DLL of the old code against the current source.",{"type":37,"tag":85,"props":206,"children":207},{},[208,213],{"type":37,"tag":59,"props":209,"children":210},{},[211],{"type":43,"value":212},"Runtime configuration (GC mode, JIT settings)",{"type":43,"value":214},": understanding how runtime settings affect performance — compared via multiple jobs in a single run.",{"type":37,"tag":85,"props":216,"children":217},{},[218,223],{"type":37,"tag":59,"props":219,"children":220},{},[221],{"type":43,"value":222},"Scale (N=100 vs N=1000)",{"type":43,"value":224},": understanding how performance changes as input size grows.",{"type":37,"tag":85,"props":226,"children":227},{},[228,233],{"type":37,"tag":59,"props":229,"children":230},{},[231],{"type":43,"value":232},"Hardware\u002FOS",{"type":43,"value":234},": comparing across different machines or operating systems — requires separate runs on each environment.",{"type":37,"tag":85,"props":236,"children":237},{},[238,243],{"type":37,"tag":59,"props":239,"children":240},{},[241],{"type":43,"value":242},"Historical measurements",{"type":43,"value":244},": comparing against measurements recorded at a previous point in time.",{"type":37,"tag":46,"props":246,"children":247},{},[248,250,256],{"type":43,"value":249},"BDN can compare the first six axes side-by-side in a single run, but each requires specific CLI flags or configuration that differ from what you might expect — read ",{"type":37,"tag":251,"props":252,"children":254},"a",{"href":253},"references\u002Fcomparison-strategies.md",[255],{"type":43,"value":253},{"type":43,"value":257}," for the correct approach for each strategy before configuring a comparison.",{"type":37,"tag":74,"props":259,"children":261},{"id":260},"use-cases-and-benchmark-lifecycle",[262],{"type":43,"value":263},"Use cases and benchmark lifecycle",{"type":37,"tag":46,"props":265,"children":266},{},[267],{"type":43,"value":268},"There are four distinct reasons a developer writes a benchmark, and each one changes how the benchmark should be designed and where it should live:",{"type":37,"tag":270,"props":271,"children":272},"ol",{},[273,283,293,303],{"type":37,"tag":85,"props":274,"children":275},{},[276,281],{"type":37,"tag":59,"props":277,"children":278},{},[279],{"type":43,"value":280},"Coverage suite",{"type":43,"value":282},": Write benchmarks to maximize coverage of real-world usage patterns so that regressions affecting most users are caught. These benchmarks are permanent — they belong in the project's benchmark suite, follow its conventions (directory structure, base classes, naming), and are checked in.",{"type":37,"tag":85,"props":284,"children":285},{},[286,291],{"type":37,"tag":59,"props":287,"children":288},{},[289],{"type":43,"value":290},"Issue investigation",{"type":43,"value":292},": Someone has reported a specific performance problem. Write benchmarks to reproduce and diagnose that specific issue. These benchmarks are task-scoped — they persist across the investigation (reproduce → isolate → verify fix) but are not part of the permanent suite.",{"type":37,"tag":85,"props":294,"children":295},{},[296,301],{"type":37,"tag":59,"props":297,"children":298},{},[299],{"type":43,"value":300},"Change validation",{"type":43,"value":302},": A developer has a PR or change and wants to understand its performance characteristics before merging. These benchmarks are task-scoped — they persist across the review cycle but are not checked in.",{"type":37,"tag":85,"props":304,"children":305},{},[306,311],{"type":37,"tag":59,"props":307,"children":308},{},[309],{"type":43,"value":310},"Development feedback",{"type":43,"value":312},": A developer is actively working on a task and wants to use benchmarks to evaluate approaches and get information early. These benchmarks are task-scoped and throwaway — they persist across the development session but are deleted when the decision is made.",{"type":37,"tag":46,"props":314,"children":315},{},[316],{"type":43,"value":317},"For use case 1, add to the existing benchmark project following its conventions. For use cases 2–4, create a standalone project in a working directory that persists for the task but is clearly not part of the permanent codebase.",{"type":37,"tag":46,"props":319,"children":320},{},[321,323,328,330,335,337,343],{"type":43,"value":322},"For ",{"type":37,"tag":59,"props":324,"children":325},{},[326],{"type":43,"value":327},"coverage suite",{"type":43,"value":329}," benchmarks, design from the perspective of real callers — what code patterns use this API, what inputs they pass, and what performance characteristics matter to them. Each permanent benchmark should justify its maintenance cost through real-world relevance. For ",{"type":37,"tag":59,"props":331,"children":332},{},[333],{"type":43,"value":334},"temporary benchmarks",{"type":43,"value":336},", keep the case count intentional — each additional test case costs wall-clock time (read ",{"type":37,"tag":251,"props":338,"children":340},{"href":339},"#cost-awareness",[341],{"type":43,"value":342},"Cost awareness",{"type":43,"value":344},").",{"type":37,"tag":74,"props":346,"children":348},{"id":347},"cost-awareness",[349],{"type":43,"value":342},{"type":37,"tag":46,"props":351,"children":352},{},[353,355,360,362,368,370,375],{"type":43,"value":354},"Each benchmark case (one method × one parameter combination × one job) takes ",{"type":37,"tag":59,"props":356,"children":357},{},[358],{"type":43,"value":359},"15–25 seconds",{"type":43,"value":361}," with default settings. ",{"type":37,"tag":126,"props":363,"children":365},{"className":364},[],[366],{"type":43,"value":367},"[Params]",{"type":43,"value":369}," creates a Cartesian product: two ",{"type":37,"tag":126,"props":371,"children":373},{"className":372},[],[374],{"type":43,"value":367},{"type":43,"value":376}," with 3 and 4 values across 5 methods = 60 cases ≈ 20 minutes. Multiple jobs multiply this further. Before running, estimate the total case count and match the job preset to the situation:",{"type":37,"tag":378,"props":379,"children":380},"table",{},[381,405],{"type":37,"tag":382,"props":383,"children":384},"thead",{},[385],{"type":37,"tag":386,"props":387,"children":388},"tr",{},[389,395,400],{"type":37,"tag":390,"props":391,"children":392},"th",{},[393],{"type":43,"value":394},"Preset",{"type":37,"tag":390,"props":396,"children":397},{},[398],{"type":43,"value":399},"Per-case time",{"type":37,"tag":390,"props":401,"children":402},{},[403],{"type":43,"value":404},"When to use",{"type":37,"tag":406,"props":407,"children":408},"tbody",{},[409,432,454,476,498],{"type":37,"tag":386,"props":410,"children":411},{},[412,422,427],{"type":37,"tag":413,"props":414,"children":415},"td",{},[416],{"type":37,"tag":126,"props":417,"children":419},{"className":418},[],[420],{"type":43,"value":421},"--job Dry",{"type":37,"tag":413,"props":423,"children":424},{},[425],{"type":43,"value":426},"\u003C1s",{"type":37,"tag":413,"props":428,"children":429},{},[430],{"type":43,"value":431},"Validate correctness — confirms compilation and execution without measurement",{"type":37,"tag":386,"props":433,"children":434},{},[435,444,449],{"type":37,"tag":413,"props":436,"children":437},{},[438],{"type":37,"tag":126,"props":439,"children":441},{"className":440},[],[442],{"type":43,"value":443},"--job Short",{"type":37,"tag":413,"props":445,"children":446},{},[447],{"type":43,"value":448},"5–8s",{"type":37,"tag":413,"props":450,"children":451},{},[452],{"type":43,"value":453},"Quick measurements during development or investigation",{"type":37,"tag":386,"props":455,"children":456},{},[457,466,471],{"type":37,"tag":413,"props":458,"children":459},{},[460],{"type":37,"tag":461,"props":462,"children":463},"em",{},[464],{"type":43,"value":465},"(default)",{"type":37,"tag":413,"props":467,"children":468},{},[469],{"type":43,"value":470},"15–25s",{"type":37,"tag":413,"props":472,"children":473},{},[474],{"type":43,"value":475},"Final measurements for a coverage suite",{"type":37,"tag":386,"props":477,"children":478},{},[479,488,493],{"type":37,"tag":413,"props":480,"children":481},{},[482],{"type":37,"tag":126,"props":483,"children":485},{"className":484},[],[486],{"type":43,"value":487},"--job Medium",{"type":37,"tag":413,"props":489,"children":490},{},[491],{"type":43,"value":492},"33–52s",{"type":37,"tag":413,"props":494,"children":495},{},[496],{"type":43,"value":497},"Higher confidence when results matter",{"type":37,"tag":386,"props":499,"children":500},{},[501,510,515],{"type":37,"tag":413,"props":502,"children":503},{},[504],{"type":37,"tag":126,"props":505,"children":507},{"className":506},[],[508],{"type":43,"value":509},"--job Long",{"type":37,"tag":413,"props":511,"children":512},{},[513],{"type":43,"value":514},"3–12 min",{"type":37,"tag":413,"props":516,"children":517},{},[518],{"type":43,"value":519},"High statistical confidence",{"type":37,"tag":46,"props":521,"children":522},{},[523,525,530],{"type":43,"value":524},"If benchmark runs take longer than expected, results seem unstable, or you need to tune iteration counts or execution settings, read ",{"type":37,"tag":251,"props":526,"children":528},{"href":527},"references\u002Fbdn-internals-and-tuning.md",[529],{"type":43,"value":527},{"type":43,"value":531}," for detailed information about BDN's execution pipeline and configuration options.",{"type":37,"tag":74,"props":533,"children":535},{"id":534},"entry-points-and-configuration",[536],{"type":43,"value":537},"Entry points and configuration",{"type":37,"tag":46,"props":539,"children":540},{},[541,543,552,554,563,565,571,573,579,581,587,589,594,596,601],{"type":43,"value":542},"BDN programs use either ",{"type":37,"tag":59,"props":544,"children":545},{},[546],{"type":37,"tag":126,"props":547,"children":549},{"className":548},[],[550],{"type":43,"value":551},"BenchmarkSwitcher",{"type":43,"value":553}," (provides interactive benchmark selection for humans, parses CLI arguments) or ",{"type":37,"tag":59,"props":555,"children":556},{},[557],{"type":37,"tag":126,"props":558,"children":560},{"className":559},[],[561],{"type":43,"value":562},"BenchmarkRunner",{"type":43,"value":564}," (runs specified benchmarks directly). Both support CLI flags like ",{"type":37,"tag":126,"props":566,"children":568},{"className":567},[],[569],{"type":43,"value":570},"--filter",{"type":43,"value":572}," and ",{"type":37,"tag":126,"props":574,"children":576},{"className":575},[],[577],{"type":43,"value":578},"--runtimes",{"type":43,"value":580},", but only when ",{"type":37,"tag":126,"props":582,"children":584},{"className":583},[],[585],{"type":43,"value":586},"args",{"type":43,"value":588}," is passed through — without it, CLI flags are silently ignored. When using ",{"type":37,"tag":126,"props":590,"children":592},{"className":591},[],[593],{"type":43,"value":551},{"type":43,"value":595},", always pass ",{"type":37,"tag":126,"props":597,"children":599},{"className":598},[],[600],{"type":43,"value":570},{"type":43,"value":602}," to avoid hanging on an interactive prompt.",{"type":37,"tag":46,"props":604,"children":605},{},[606,608,613,615,620,622,627],{"type":43,"value":607},"BDN behavior is customized through ",{"type":37,"tag":59,"props":609,"children":610},{},[611],{"type":43,"value":612},"attributes",{"type":43,"value":614},", ",{"type":37,"tag":59,"props":616,"children":617},{},[618],{"type":43,"value":619},"config objects",{"type":43,"value":621},", and ",{"type":37,"tag":59,"props":623,"children":624},{},[625],{"type":43,"value":626},"CLI flags",{"type":43,"value":628},".",{"type":37,"tag":46,"props":630,"children":631},{},[632,634,639,641,646],{"type":43,"value":633},"Read ",{"type":37,"tag":251,"props":635,"children":637},{"href":636},"references\u002Fproject-setup-and-running.md",[638],{"type":43,"value":636},{"type":43,"value":640}," for entry point setup, config object patterns, and CLI flags. If you need to collect data beyond wall-clock time — such as memory allocations, hardware counters, or profiling traces — read ",{"type":37,"tag":251,"props":642,"children":644},{"href":643},"references\u002Fdiagnosers-and-exporters.md",[645],{"type":43,"value":643},{"type":43,"value":628},{"type":37,"tag":74,"props":648,"children":650},{"id":649},"running-benchmarks",[651],{"type":43,"value":652},"Running benchmarks",{"type":37,"tag":46,"props":654,"children":655},{},[656],{"type":43,"value":657},"BenchmarkDotNet console output is extremely verbose — hundreds of lines per case showing internal calibration, warmup, and measurement details. Redirect all output to a file to avoid consuming context on verbose iteration output:",{"type":37,"tag":659,"props":660,"children":664},"pre",{"className":661,"code":663,"language":43},[662],"language-text","dotnet run -c Release -- --filter \"*MethodName\" --noOverwrite > benchmark.log 2>&1\n",[665],{"type":37,"tag":126,"props":666,"children":668},{"__ignoreMap":667},"",[669],{"type":43,"value":663},{"type":37,"tag":46,"props":671,"children":672},{},[673,675,680,682,686],{"type":43,"value":674},"Each benchmark method can take several minutes. Rather than running all benchmarks at once, use ",{"type":37,"tag":126,"props":676,"children":678},{"className":677},[],[679],{"type":43,"value":570},{"type":43,"value":681}," to run a subset at a time (e.g. one or two methods per invocation), read the results, then run the next subset. This keeps each invocation short — avoiding session or terminal timeouts — and lets you verify results incrementally. Read ",{"type":37,"tag":251,"props":683,"children":684},{"href":636},[685],{"type":43,"value":636},{"type":43,"value":687}," for filter syntax, CLI flags, and project setup.",{"type":37,"tag":46,"props":689,"children":690},{},[691,693,699,701,707],{"type":43,"value":692},"After each run, read the Markdown report (",{"type":37,"tag":126,"props":694,"children":696},{"className":695},[],[697],{"type":43,"value":698},"*-report-github.md",{"type":43,"value":700},") from the results directory for the summary table. Only read ",{"type":37,"tag":126,"props":702,"children":704},{"className":703},[],[705],{"type":43,"value":706},"benchmark.log",{"type":43,"value":708}," if you need to investigate errors or unexpected results.",{"type":37,"tag":74,"props":710,"children":712},{"id":711},"writing-new-benchmarks",[713],{"type":43,"value":714},"Writing new benchmarks",{"type":37,"tag":716,"props":717,"children":719},"h3",{"id":718},"step-1-plan-the-test-cases",[720],{"type":43,"value":721},"Step 1: Plan the test cases",{"type":37,"tag":46,"props":723,"children":724},{},[725],{"type":43,"value":726},"Before writing any code, determine:",{"type":37,"tag":81,"props":728,"children":729},{},[730,735,740],{"type":37,"tag":85,"props":731,"children":732},{},[733],{"type":43,"value":734},"Which use case this benchmark serves (coverage, investigation, change validation, or development feedback).",{"type":37,"tag":85,"props":736,"children":737},{},[738],{"type":43,"value":739},"Which comparison axis applies (what will the number be compared against?).",{"type":37,"tag":85,"props":741,"children":742},{},[743],{"type":43,"value":744},"What real-world scenarios to benchmark, based on how callers actually use the API.",{"type":37,"tag":46,"props":746,"children":747},{},[748],{"type":43,"value":749},"Each benchmark case should justify its cost. An uncovered scenario is usually more valuable than another parameter combination for one already covered, but when a specific parameter dimension genuinely affects performance characteristics, the depth is warranted.",{"type":37,"tag":46,"props":751,"children":752},{},[753],{"type":43,"value":754},"Decide on the list of test cases. For each test case, think through:",{"type":37,"tag":81,"props":756,"children":757},{},[758,828,884],{"type":37,"tag":85,"props":759,"children":760},{},[761,766,768,773,774,780,782,788,789,795,797,803,805,811,813,819,821,826],{"type":37,"tag":59,"props":762,"children":763},{},[764],{"type":43,"value":765},"How to express variation",{"type":43,"value":767},": BenchmarkDotNet provides several mechanisms for parameterizing benchmarks — ",{"type":37,"tag":126,"props":769,"children":771},{"className":770},[],[772],{"type":43,"value":367},{"type":43,"value":572},{"type":37,"tag":126,"props":775,"children":777},{"className":776},[],[778],{"type":43,"value":779},"[ParamsSource]",{"type":43,"value":781}," for property-level parameters, ",{"type":37,"tag":126,"props":783,"children":785},{"className":784},[],[786],{"type":43,"value":787},"[Arguments]",{"type":43,"value":572},{"type":37,"tag":126,"props":790,"children":792},{"className":791},[],[793],{"type":43,"value":794},"[ArgumentsSource]",{"type":43,"value":796}," for method-level arguments, ",{"type":37,"tag":126,"props":798,"children":800},{"className":799},[],[801],{"type":43,"value":802},"[ParamsAllValues]",{"type":43,"value":804}," to enumerate all values of a ",{"type":37,"tag":126,"props":806,"children":808},{"className":807},[],[809],{"type":43,"value":810},"bool",{"type":43,"value":812}," or enum, and ",{"type":37,"tag":126,"props":814,"children":816},{"className":815},[],[817],{"type":43,"value":818},"[GenericTypeArguments]",{"type":43,"value":820}," for varying type parameters on generic benchmark classes. Choose the mechanism that best fits the dimension being varied. Read ",{"type":37,"tag":251,"props":822,"children":824},{"href":823},"references\u002Fwriting-benchmarks.md",[825],{"type":43,"value":823},{"type":43,"value":827}," for the full set of options and correctness patterns.",{"type":37,"tag":85,"props":829,"children":830},{},[831,836,838],{"type":37,"tag":59,"props":832,"children":833},{},[834],{"type":43,"value":835},"Where input data comes from",{"type":43,"value":837}," — consider which sources are appropriate (these can be combined):\n",{"type":37,"tag":81,"props":839,"children":840},{},[841,853,858],{"type":37,"tag":85,"props":842,"children":843},{},[844,846,851],{"type":43,"value":845},"Hard-coded values — small, fixed values where the exact input matters (e.g., specific strings, known edge-case sizes). Store in fields or ",{"type":37,"tag":126,"props":847,"children":849},{"className":848},[],[850],{"type":43,"value":367},{"type":43,"value":852}," to avoid constant folding.",{"type":37,"tag":85,"props":854,"children":855},{},[856],{"type":43,"value":857},"Asset files — static data that is too large or impractical to embed in source code such as binary blobs.",{"type":37,"tag":85,"props":859,"children":860},{},[861,863,868,870,875,876,882],{"type":43,"value":862},"Programmatically generated via ",{"type":37,"tag":126,"props":864,"children":866},{"className":865},[],[867],{"type":43,"value":779},{"type":43,"value":869},"\u002F",{"type":37,"tag":126,"props":871,"children":873},{"className":872},[],[874],{"type":43,"value":794},{"type":43,"value":869},{"type":37,"tag":126,"props":877,"children":879},{"className":878},[],[880],{"type":43,"value":881},"[GlobalSetup]",{"type":43,"value":883}," — when data shape matters more than specific content, or when input must be parameterized by size.",{"type":37,"tag":85,"props":885,"children":886},{},[887,892],{"type":37,"tag":59,"props":888,"children":889},{},[890],{"type":43,"value":891},"Whether randomness is appropriate",{"type":43,"value":893},": If using generated data, use seeded randomness for reproducibility. When generating random data, use a large enough sample that the generated distribution is representative (e.g., 4 random values may cluster in a narrow range, while 1000 will better exercise the full distribution).",{"type":37,"tag":716,"props":895,"children":897},{"id":896},"step-2-implement-the-benchmarks",[898],{"type":43,"value":899},"Step 2: Implement the benchmarks",{"type":37,"tag":46,"props":901,"children":902},{},[903,904,908,910,914,916,920],{"type":43,"value":322},{"type":37,"tag":59,"props":905,"children":906},{},[907],{"type":43,"value":327},{"type":43,"value":909}," benchmarks, add to the existing benchmark project and follow its conventions. For ",{"type":37,"tag":59,"props":911,"children":912},{},[913],{"type":43,"value":334},{"type":43,"value":915}," (investigation, change validation, development feedback), create a standalone project — read ",{"type":37,"tag":251,"props":917,"children":918},{"href":636},[919],{"type":43,"value":636},{"type":43,"value":921}," for project setup and entry point configuration.",{"type":37,"tag":46,"props":923,"children":924},{},[925,930,932,938,940,946,948,954],{"type":37,"tag":59,"props":926,"children":927},{},[928],{"type":43,"value":929},"Adding the BenchmarkDotNet package",{"type":43,"value":931},": Always use ",{"type":37,"tag":126,"props":933,"children":935},{"className":934},[],[936],{"type":43,"value":937},"dotnet add package BenchmarkDotNet",{"type":43,"value":939}," (no version) — this lets NuGet resolve the latest compatible version. Do NOT manually write a ",{"type":37,"tag":126,"props":941,"children":943},{"className":942},[],[944],{"type":43,"value":945},"\u003CPackageReference>",{"type":43,"value":947}," with a version number into the ",{"type":37,"tag":126,"props":949,"children":951},{"className":950},[],[952],{"type":43,"value":953},".csproj",{"type":43,"value":955},"; BDN versions in training data are outdated and may lack support for current .NET runtimes.",{"type":37,"tag":46,"props":957,"children":958},{},[959,961,965],{"type":43,"value":960},"Write the benchmark code. Follow the patterns in ",{"type":37,"tag":251,"props":962,"children":963},{"href":823},[964],{"type":43,"value":823},{"type":43,"value":966}," to avoid common measurement errors — in particular:",{"type":37,"tag":81,"props":968,"children":969},{},[970,980,1003,1013,1039],{"type":37,"tag":85,"props":971,"children":972},{},[973,978],{"type":37,"tag":59,"props":974,"children":975},{},[976],{"type":43,"value":977},"Return results",{"type":43,"value":979}," from benchmark methods to prevent dead code elimination",{"type":37,"tag":85,"props":981,"children":982},{},[983,993,995,1001],{"type":37,"tag":59,"props":984,"children":985},{},[986,988],{"type":43,"value":987},"Move initialization to ",{"type":37,"tag":126,"props":989,"children":991},{"className":990},[],[992],{"type":43,"value":881},{"type":43,"value":994}," — setup inside the benchmark method is measured; use ",{"type":37,"tag":126,"props":996,"children":998},{"className":997},[],[999],{"type":43,"value":1000},"[IterationSetup]",{"type":43,"value":1002}," only when the benchmark mutates state that must be reset between iterations",{"type":37,"tag":85,"props":1004,"children":1005},{},[1006,1011],{"type":37,"tag":59,"props":1007,"children":1008},{},[1009],{"type":43,"value":1010},"Do not add manual loops",{"type":43,"value":1012}," — BDN controls invocation count automatically",{"type":37,"tag":85,"props":1014,"children":1015},{},[1016,1021,1023,1029,1031,1037],{"type":37,"tag":59,"props":1017,"children":1018},{},[1019],{"type":43,"value":1020},"Mark a baseline",{"type":43,"value":1022}," when comparing alternatives — use ",{"type":37,"tag":126,"props":1024,"children":1026},{"className":1025},[],[1027],{"type":43,"value":1028},"[Benchmark(Baseline = true)]",{"type":43,"value":1030}," for method-level comparisons or ",{"type":37,"tag":126,"props":1032,"children":1034},{"className":1033},[],[1035],{"type":43,"value":1036},".AsBaseline()",{"type":43,"value":1038}," on a job for multi-job comparisons so results show relative ratios",{"type":37,"tag":85,"props":1040,"children":1041},{},[1042,1052,1054,1060],{"type":37,"tag":59,"props":1043,"children":1044},{},[1045,1047],{"type":43,"value":1046},"Store inputs in fields or ",{"type":37,"tag":126,"props":1048,"children":1050},{"className":1049},[],[1051],{"type":43,"value":367},{"type":43,"value":1053},", not as literals or ",{"type":37,"tag":126,"props":1055,"children":1057},{"className":1056},[],[1058],{"type":43,"value":1059},"const",{"type":43,"value":1061}," values — the JIT can fold constant expressions at compile time, making the benchmark measure a precomputed result instead of the actual computation",{"type":37,"tag":716,"props":1063,"children":1065},{"id":1064},"step-3-validate-and-run",[1066],{"type":43,"value":1067},"Step 3: Validate and run",{"type":37,"tag":46,"props":1069,"children":1070},{},[1071],{"type":43,"value":1072},"Validate before committing to a long run:",{"type":37,"tag":270,"props":1074,"children":1075},{},[1076,1088,1093],{"type":37,"tag":85,"props":1077,"children":1078},{},[1079,1081,1086],{"type":43,"value":1080},"Run with ",{"type":37,"tag":126,"props":1082,"children":1084},{"className":1083},[],[1085],{"type":43,"value":421},{"type":43,"value":1087}," first to catch compilation errors and runtime exceptions without spending time on measurement.",{"type":37,"tag":85,"props":1089,"children":1090},{},[1091],{"type":43,"value":1092},"Run a single representative case with default settings to verify the output looks correct and the numbers are in the expected range.",{"type":37,"tag":85,"props":1094,"children":1095},{},[1096],{"type":43,"value":1097},"Only run the full suite after validation passes.",{"type":37,"tag":46,"props":1099,"children":1100},{},[1101,1103,1108],{"type":43,"value":1102},"When iterating on benchmark design, use ",{"type":37,"tag":126,"props":1104,"children":1106},{"className":1105},[],[1107],{"type":43,"value":443},{"type":43,"value":1109}," until confident, then switch to default for final numbers.",{"items":1111,"total":1218},[1112,1127,1142,1160,1174,1194,1204],{"slug":1113,"name":1113,"fn":1114,"description":1115,"org":1116,"tags":1117,"stars":19,"repoUrl":20,"updatedAt":1126},"analyzing-dotnet-performance","analyze .NET code for performance anti-patterns","Scans .NET code for ~50 performance anti-patterns across async, memory, strings, collections, LINQ, regex, serialization, and I\u002FO with tiered severity classification. Use when analyzing .NET code for optimization opportunities, reviewing hot paths, or auditing allocation-heavy patterns.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[1118,1119,1122,1125],{"name":17,"slug":18,"type":15},{"name":1120,"slug":1121,"type":15},"Code Analysis","code-analysis",{"name":1123,"slug":1124,"type":15},"Debugging","debugging",{"name":13,"slug":14,"type":15},"2026-07-12T08:23:25.400375",{"slug":1128,"name":1128,"fn":1129,"description":1130,"org":1131,"tags":1132,"stars":19,"repoUrl":20,"updatedAt":1141},"android-tombstone-symbolication","symbolicate .NET runtime frames in Android tombstones","Symbolicate the .NET runtime frames in an Android tombstone file. Extracts BuildIds and PC offsets from the native backtrace, downloads debug symbols from the Microsoft symbol server, and runs llvm-symbolizer to produce function names with source file and line numbers. USE FOR triaging a .NET MAUI or Mono Android app crash from a tombstone, resolving native backtrace frames in libmonosgen-2.0.so or libcoreclr.so to .NET runtime source code, or investigating SIGABRT, SIGSEGV, or other native signals originating from the .NET runtime on Android. DO NOT USE FOR pure Java\u002FKotlin crashes, managed .NET exceptions that are already captured in logcat, or iOS crash logs. INVOKES Symbolicate-Tombstone.ps1 script, llvm-symbolizer, Microsoft symbol server.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[1133,1134,1137,1138],{"name":17,"slug":18,"type":15},{"name":1135,"slug":1136,"type":15},"Android","android",{"name":1123,"slug":1124,"type":15},{"name":1139,"slug":1140,"type":15},"Microsoft","microsoft","2026-07-12T08:23:21.595572",{"slug":1143,"name":1143,"fn":1144,"description":1145,"org":1146,"tags":1147,"stars":19,"repoUrl":20,"updatedAt":1159},"apple-crash-symbolication","symbolicate .NET runtime frames in crash logs","Symbolicate .NET runtime frames in Apple platform .ips crash logs (iOS, tvOS, Mac Catalyst, macOS). Extracts UUIDs and addresses from the native backtrace, locates dSYM debug symbols, and runs atos to produce function names with source file and line numbers. Automatically downloads .dwarf symbols from the Microsoft symbol server using Mach-O UUIDs. USE FOR triaging a .NET MAUI or Mono app crash from an .ips file on any Apple platform, resolving native backtrace frames in libcoreclr or libmonosgen-2.0 to .NET runtime source code, retrieving .ips crash logs from a connected iOS device or iPhone, or investigating EXC_CRASH, EXC_BAD_ACCESS, SIGABRT, or SIGSEGV originating from the .NET runtime. DO NOT USE FOR pure Swift\u002FObjective-C crashes with no .NET components, or Android tombstone files. INVOKES Symbolicate-Crash.ps1 script, atos, dwarfdump, idevicecrashreport.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[1148,1149,1150,1153,1156],{"name":17,"slug":18,"type":15},{"name":1123,"slug":1124,"type":15},{"name":1151,"slug":1152,"type":15},"iOS","ios",{"name":1154,"slug":1155,"type":15},"macOS","macos",{"name":1157,"slug":1158,"type":15},"Observability","observability","2026-07-12T08:23:20.369986",{"slug":1161,"name":1161,"fn":1162,"description":1163,"org":1164,"tags":1165,"stars":19,"repoUrl":20,"updatedAt":1173},"assertion-quality","evaluate assertion quality in test suites","Analyzes the variety and depth of assertions across test suites in any language. Use when the user asks to evaluate assertion quality, find shallow tests, identify assertion-free tests (no assertions or only trivial ones like Assert.IsNotNull \u002F toBeTruthy()), flag self-referential or tautological assertions, measure assertion diversity, or audit whether tests verify different facets of behavior. Polyglot: .NET, Python, TS\u002FJS, Java, Go, Ruby, Rust, Swift, Kotlin, PowerShell, C++. DO NOT USE FOR: writing new tests (use code-testing-agent \u002F writing-mstest-tests), mutation reasoning about whether tests would catch a bug (use test-gap-analysis), or a general severity-ranked anti-pattern audit (use test-anti-patterns), fixing or rewriting assertions, or writing, fixing, or modernizing MSTest tests, assertions, or attributes (use writing-mstest-tests).",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[1166,1167,1170],{"name":1120,"slug":1121,"type":15},{"name":1168,"slug":1169,"type":15},"QA","qa",{"name":1171,"slug":1172,"type":15},"Testing","testing","2026-07-12T08:23:51.277743",{"slug":1175,"name":1175,"fn":1176,"description":1177,"org":1178,"tags":1179,"stars":19,"repoUrl":20,"updatedAt":1193},"author-component","create and review Blazor components","Create or review Blazor components (.razor files) with correct architecture. USE FOR: writing new Blazor components that do NOT involve JavaScript interop, implementing parameters and EventCallback, RenderFragment slots, component lifecycle (OnInitializedAsync, OnParametersSet), async patterns, IAsyncDisposable, CancellationToken, CSS isolation, code-behind. DO NOT USE FOR: creating new projects (use create-blazor-project), JavaScript interop or calling browser APIs from Blazor (use use-js-interop), forms and validation (use collect-user-input), prerendering issues (use support-prerendering), HTTP data fetching patterns (use fetch-and-send-data), coordinating state between unrelated components (use coordinate-components).\n",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[1180,1181,1184,1187,1190],{"name":17,"slug":18,"type":15},{"name":1182,"slug":1183,"type":15},"Blazor","blazor",{"name":1185,"slug":1186,"type":15},"C#","csharp",{"name":1188,"slug":1189,"type":15},"UI Components","ui-components",{"name":1191,"slug":1192,"type":15},"Web Development","web-development","2026-07-15T06:03:29.216359",{"slug":1195,"name":1195,"fn":1196,"description":1197,"org":1198,"tags":1199,"stars":19,"repoUrl":20,"updatedAt":1203},"binlog-failure-analysis","analyze MSBuild binary logs","Analyze MSBuild binary logs to diagnose build failures. USE FOR: build errors that are unclear from console output, diagnosing cascading failures across multi-project builds, tracing MSBuild target execution order, and generally any MSBuild build issues. Requires an existing .binlog file. DO NOT USE FOR: generating binlogs (use binlog-generation), non-MSBuild build systems.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[1200,1201,1202],{"name":1120,"slug":1121,"type":15},{"name":1123,"slug":1124,"type":15},{"name":1139,"slug":1140,"type":15},"2026-07-12T08:21:34.637923",{"slug":1205,"name":1205,"fn":1206,"description":1207,"org":1208,"tags":1209,"stars":19,"repoUrl":20,"updatedAt":1217},"binlog-generation","generate MSBuild binary logs for diagnostics","Generate MSBuild binary logs (binlogs) for build diagnostics and analysis. USE FOR: adding \u002Fbl:{} to any dotnet build, test, pack, publish, or restore command to capture a full build execution trace, prerequisite for binlog-failure-analysis and build-perf-diagnostics skills, enabling post-build investigation of errors or performance. Requires MSBuild 17.8+ \u002F .NET 8 SDK+ for {} placeholder; PowerShell needs -bl:{{}}. DO NOT USE FOR: non-MSBuild build systems (npm, Maven, CMake), analyzing an existing binlog (use binlog-failure-analysis instead).",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[1210,1213,1214],{"name":1211,"slug":1212,"type":15},"Build","build",{"name":1123,"slug":1124,"type":15},{"name":1215,"slug":1216,"type":15},"Engineering","engineering","2026-07-19T05:38:19.340791",96,{"items":1220,"total":1325},[1221,1233,1240,1247,1255,1261,1269,1275,1281,1291,1304,1315],{"slug":1222,"name":1222,"fn":1223,"description":1224,"org":1225,"tags":1226,"stars":1230,"repoUrl":1231,"updatedAt":1232},"multithreaded-task-migration","migrate MSBuild tasks to multithreaded mode","Guide for migrating MSBuild tasks to multithreaded mode support, including compatibility red-team review. Use this when converting tasks to thread-safe versions, implementing IMultiThreadableTask, adding TaskEnvironment support, or auditing migrations for behavioral compatibility.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[1227,1228,1229],{"name":17,"slug":18,"type":15},{"name":1215,"slug":1216,"type":15},{"name":13,"slug":14,"type":15},5535,"https:\u002F\u002Fgithub.com\u002Fdotnet\u002Fmsbuild","2026-07-22T05:37:33.965588",{"slug":1113,"name":1113,"fn":1114,"description":1115,"org":1234,"tags":1235,"stars":19,"repoUrl":20,"updatedAt":1126},{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[1236,1237,1238,1239],{"name":17,"slug":18,"type":15},{"name":1120,"slug":1121,"type":15},{"name":1123,"slug":1124,"type":15},{"name":13,"slug":14,"type":15},{"slug":1128,"name":1128,"fn":1129,"description":1130,"org":1241,"tags":1242,"stars":19,"repoUrl":20,"updatedAt":1141},{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[1243,1244,1245,1246],{"name":17,"slug":18,"type":15},{"name":1135,"slug":1136,"type":15},{"name":1123,"slug":1124,"type":15},{"name":1139,"slug":1140,"type":15},{"slug":1143,"name":1143,"fn":1144,"description":1145,"org":1248,"tags":1249,"stars":19,"repoUrl":20,"updatedAt":1159},{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[1250,1251,1252,1253,1254],{"name":17,"slug":18,"type":15},{"name":1123,"slug":1124,"type":15},{"name":1151,"slug":1152,"type":15},{"name":1154,"slug":1155,"type":15},{"name":1157,"slug":1158,"type":15},{"slug":1161,"name":1161,"fn":1162,"description":1163,"org":1256,"tags":1257,"stars":19,"repoUrl":20,"updatedAt":1173},{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[1258,1259,1260],{"name":1120,"slug":1121,"type":15},{"name":1168,"slug":1169,"type":15},{"name":1171,"slug":1172,"type":15},{"slug":1175,"name":1175,"fn":1176,"description":1177,"org":1262,"tags":1263,"stars":19,"repoUrl":20,"updatedAt":1193},{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[1264,1265,1266,1267,1268],{"name":17,"slug":18,"type":15},{"name":1182,"slug":1183,"type":15},{"name":1185,"slug":1186,"type":15},{"name":1188,"slug":1189,"type":15},{"name":1191,"slug":1192,"type":15},{"slug":1195,"name":1195,"fn":1196,"description":1197,"org":1270,"tags":1271,"stars":19,"repoUrl":20,"updatedAt":1203},{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[1272,1273,1274],{"name":1120,"slug":1121,"type":15},{"name":1123,"slug":1124,"type":15},{"name":1139,"slug":1140,"type":15},{"slug":1205,"name":1205,"fn":1206,"description":1207,"org":1276,"tags":1277,"stars":19,"repoUrl":20,"updatedAt":1217},{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[1278,1279,1280],{"name":1211,"slug":1212,"type":15},{"name":1123,"slug":1124,"type":15},{"name":1215,"slug":1216,"type":15},{"slug":1282,"name":1282,"fn":1283,"description":1284,"org":1285,"tags":1286,"stars":19,"repoUrl":20,"updatedAt":1290},"build-parallelism","optimize MSBuild build parallelism","Diagnose and fix under-parallelized MSBuild builds. USE WHEN a multi-project solution build is slower than expected, doesn't speed up when you add cores, pegs a single core while others idle, or you want to know why `-m` isn't helping. Note: `\u002Fmaxcpucount` default is 1 (sequential) — always pass `-m` for parallel builds. Covers finding the critical path (longest serial ProjectReference chain), graph build (`\u002Fgraph`), BuildInParallel, and solution filters (`.slnf`). DO NOT USE FOR: single-project builds, incremental issues (use incremental-build), compilation slowness inside one project (use build-perf-diagnostics), non-MSBuild build systems.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[1287,1288,1289],{"name":17,"slug":18,"type":15},{"name":1215,"slug":1216,"type":15},{"name":13,"slug":14,"type":15},"2026-07-19T05:38:18.364937",{"slug":1292,"name":1292,"fn":1293,"description":1294,"org":1295,"tags":1296,"stars":19,"repoUrl":20,"updatedAt":1303},"build-perf-baseline","establish and optimize build performance baselines","Establish build performance baselines and apply systematic optimization techniques. USE FOR: diagnosing slow builds, establishing before\u002Fafter measurements (cold, warm, no-op scenarios), applying optimization strategies like MSBuild Server, static graph builds, artifacts output, and dependency graph trimming. Start here before diving into build-perf-diagnostics, incremental-build, or build-parallelism. DO NOT USE FOR: non-MSBuild build systems, detailed bottleneck analysis (use build-perf-diagnostics after baselining).",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[1297,1298,1301,1302],{"name":1215,"slug":1216,"type":15},{"name":1299,"slug":1300,"type":15},"Monitoring","monitoring",{"name":13,"slug":14,"type":15},{"name":1171,"slug":1172,"type":15},"2026-07-12T08:21:35.865649",{"slug":1305,"name":1305,"fn":1306,"description":1307,"org":1308,"tags":1309,"stars":19,"repoUrl":20,"updatedAt":1314},"build-perf-diagnostics","diagnose MSBuild build performance bottlenecks","Diagnose MSBuild build performance bottlenecks using binary log analysis. USE FOR: identifying why builds are slow by analyzing binlog performance summaries, detecting ResolveAssemblyReference (RAR) taking >5s, Roslyn analyzers consuming >30% of Csc time, single targets dominating >50% of build time, node utilization below 80%, excessive Copy tasks, NuGet restore running every build. Covers timeline analysis, Target\u002FTask Performance Summary interpretation, and 7 common bottleneck categories. Use after build-perf-baseline has established measurements. DO NOT USE FOR: establishing initial baselines (use build-perf-baseline first), fixing incremental build issues (use incremental-build), parallelism tuning (use build-parallelism), non-MSBuild build systems.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[1310,1311,1312,1313],{"name":17,"slug":18,"type":15},{"name":1123,"slug":1124,"type":15},{"name":1215,"slug":1216,"type":15},{"name":13,"slug":14,"type":15},"2026-07-12T08:21:40.961722",{"slug":1316,"name":1316,"fn":1317,"description":1318,"org":1319,"tags":1320,"stars":19,"repoUrl":20,"updatedAt":1324},"check-bin-obj-clash","detect MSBuild output path conflicts","Detects MSBuild projects with conflicting OutputPath or IntermediateOutputPath. USE FOR: builds failing with 'Cannot create a file when that file already exists', 'The process cannot access the file because it is being used by another process', intermittent build failures that succeed on retry, or missing\u002Foverwritten outputs in multi-project or multi-targeting builds where bin\u002Fobj (or project.assets.json) collide. Common causes: shared OutputPath, missing AppendTargetFrameworkToOutputPath, extra global properties (e.g. PublishReadyToRun), or SetTargetFramework on a ProjectReference to a single-targeting project. DO NOT USE FOR: file access errors unrelated to MSBuild (OS-level locking), single-project single-TFM builds, non-MSBuild build systems.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[1321,1322,1323],{"name":1123,"slug":1124,"type":15},{"name":1215,"slug":1216,"type":15},{"name":1168,"slug":1169,"type":15},"2026-07-19T05:38:14.336279",144]