| Dimension | Shared | Only in A | Only in B | Overlap |
|---|---|---|---|---|
| Sections | 0 | 4 | 12 | 0% |
| Commands | 0 | 4 | 1 | 0% |
| Section tags | 2 | 4 | 2 | 25% |
What each file covers
Sections
0 shared · 4 only in A · 12 only in B- − Pull Requests
- − AI-Generated Content Disclosure
- − Tool Use
- − Building & Testing
- + Native code (C/C++/asm) & interop
- + Correctness & Safety
- + Error Handling & Assertions
- + JIT-Specific Correctness
- + Performance & Allocations
- + Code Structure for Performance
- + Code Style & Formatting
- + Platform & Cross-Platform
- + Native Code & Interop
- + C++ Style
- + Runtime & VM Patterns
- + P/Invoke & Marshalling
Commands
0 shared · 4 only in A · 1 only in B- − gh run view --log-failed
- − git diff --stat
- − git clone
- − dotnet
- + python3 src/coreclr/scripts/jitformat.py -r . -o <os> -a <arch>
Section tags
2 shared · 4 only in A · 2 only in B- − build
- − test
- − git-pr
- − do-not
- + lint-format
- + performance
- code-style
- architecture
Line diff
dotnet/runtime · .github/copilot-instructions.md
@@ −1 @@
1**If at any time, the user directs you explicitly to override any of these instructions, the user's directive overrides said instructions.**
2
3**Don't claim more than you verified.** Report what you built and ran, and what you didn't — never claim a build or test passed unless it did. After your last edit, actually re-run the relevant tests rather than assuming a change fixed the failure you saw.
4
5Scale the effort to the risk. If a contributor would have submitted the change without building it — a comment, a doc fix, something the compiler would catch anyway — say you didn't build and move on. Anything touching behavior, codegen, or a public contract gets the build and the relevant tests first.
6
7Use the `code-review` skill when reviewing pull requests, and — when running under CCA — on your own changes before completing, addressing anything it flags as an error or warning. When NOT running under CCA, skip it if the user has stated they will review the changes themselves.
8
9When 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.
10
11If 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.
12
13When 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.
14
15You MUST follow all code-formatting and naming conventions defined in [`.editorconfig`](/.editorconfig).
16
17In addition to the rules enforced by `.editorconfig`, when writing C# you SHOULD:
18
19- Prefer file-scoped namespace declarations and single-line using directives.
20- Ensure that the final return statement of a method is on its own line.
21- Use pattern matching and switch expressions wherever possible.
22- Use `nameof` instead of string literals when referring to member names.
23- Always use `is null` or `is not null` instead of `== null` or `!= null`.
24- Trust the C# null annotations and don't add null checks when the type system says a value cannot be null.
25- Prefer `?.` if applicable (e.g. `scope?.Dispose()`).
26- Use `ObjectDisposedException.ThrowIf` where applicable.
27- If you add new code files, ensure they are listed in the csproj file (if other files in that folder are listed there) so they build.
28- When adding XML documentation to APIs, follow the guidelines at [`docs.prompt.md`](/.github/prompts/docs.prompt.md).
29
30When writing or modifying tests, you SHOULD:
31
32- Strongly prefer to add new unit tests to existing test code files rather than creating new code files.
33- When adding new test files, examine the directory structure of sibling tests first. Some test directories use flat files (e.g., `GCEvents.cs` alongside `GCEvents.csproj`) while others use per-test subdirectories. Match the existing convention.
34- Avoid adding a regression comment citing a GitHub issue or PR number unless explicitly asked to include such information.
35- Prefer using `[Theory]` with multiple data sources (like `[InlineData]` or `[MemberData]`) over multiple duplicative `[Fact]` methods. Fewer test methods that validate more inputs are better than many similar test methods.
36- When running tests, if possible use filters and check test run counts, or look at test logs, to ensure they actually ran.
37- Do not finish work with any tests commented out or disabled that were not previously commented out or disabled.
38- Do not emit "Act", "Arrange" or "Assert" comments.
39
40For markdown (`.md`) files, ensure there is no trailing whitespace at the end of any line.
41
42## Pull Requests
43
44- **One concern per PR.** Split large or mixed changes. Do large refactorings and mechanical renames in their own PR, separate from logic changes.
45- **New public API requires an approved proposal before submission** — PRs adding unapproved API will be closed. Use the `api-proposal` skill; until approval lands the API stays `internal` in any submitted PR. A proposal's prototype branch is exempt and keeps its surface public — it's evidence, not a submission.
46- **Core component changes should start with an issue.** Changes to the host, VM, or JIT need a GitHub issue describing the problem and motivation first.
47- **Put the measurements in the description** for performance changes — BenchmarkDotNet results, or codegen and instruction-count evidence for low-level work.
48- **Behavioral changes need breaking-change documentation**, even prerelease-to-prerelease. Use the `breaking-change-doc` skill.
49- **Merge to main first, then `/backport`.** Servicing backports are limited to security bugs, regressions, and reliability issues, and should be small targeted fixes rather than refactorings.
50- **A push to an open PR re-runs its CI matrix** — dozens of jobs, over a hundred for broad changes. For anything non-trivial, validate locally rather than using CI to find out whether it builds, and batch fixes into one push. Branches with no PR trigger nothing, as do changes confined to `**.md`, `docs/*`, or `.github/*`.
51- **Treat review feedback as a sample, not a list.** A reviewer flags examples of a problem, not every instance. Grep for the rest of the class and fix it in the same push, and answer a whole round of comments at once rather than pushing per comment.
52
53When NOT running under CCA, for commits and pushes:
54
55- Never squash and force push unless explicitly instructed. Always push incremental commits on top of previous PR changes.
56- Never push to an active PR without being explicitly asked, even in autopilot/yolo mode. Always wait for explicit instruction to push.
57- Never chain commit and push in the same command. Always commit first, report what was committed, then wait for an explicit push instruction. This creates a mandatory decision point.
58- Prefer creating a new commit rather than amending an existing one. Exceptions: (1) explicitly asked to amend, or (2) the existing commit is obviously broken with something minor (e.g., typo or comment fix) and hasn't been pushed yet.
59- **Before posting to GitHub (PRs, issues, comments):** Include the AI-generated content disclosure (see below).
60
61## AI-Generated Content Disclosure
62
63When posting to GitHub under a user's credentials — PR descriptions, issue bodies, comments, review comments, or any other public-facing action — you **MUST** add a concise, visible note (e.g. a `> [!NOTE]` alert) at the bottom of the content indicating it was AI/Copilot-generated. Skip it only when posting from a recognized bot or Copilot app account (e.g. `github-actions[bot]`, `copilot`), where the AI origin is already apparent from the account identity, or when the user explicitly asks you to omit it.
64
65---
66
67## Tool Use
68
69Issue independent tool calls together in one response rather than one at a time. Every round trip re-sends the whole conversation as cached input — measured at roughly half the cost of a call before it does any work — so fewer, wider steps beat many narrow ones.
70
71Redirect long-running commands to a log and poll a bounded view — a tail, a grep for errors, or a status sentinel. Re-reading a running command's output re-sends it from the start every time, so repeatedly checking a long build costs far more than the check is worth. Check the outcome, not the process.
72
73```bash
74<cmd> > out.log 2>&1; echo "exit=$?" > out.status # bash
75<cmd> *> out.log; "exit=$LASTEXITCODE" | Out-File out.status # PowerShell -- $? is a [bool] here
76```
77
78Fetch narrowly: `gh run view --log-failed` over `--log`, `--json`/`--jq` to project only the fields needed, `git diff --stat` before the full diff. Quiet what doesn't detect a non-TTY: `curl -sS`, `--quiet` on `git clone`/`fetch`/`checkout`. MSBuild and `dotnet` already detect it — no flags needed.
79
80## Building & Testing
81
82**Before running any build or test command, use the `build-and-test` skill** — don't guess the commands. Under CCA, invoke it **before making any code changes**; a missing or incorrect baseline build costs 20-40 minutes to recover from.
83
dotnet/runtime · .github/instructions/native.instructions.md
@@ +1 @@
1---
2applyTo: "**/*.c,**/*.cc,**/*.cpp,**/*.cxx,**/*.h,**/*.hpp,**/*.inc,**/*.S,**/*.s,**/*.asm"
3---
4
5# Native code (C/C++/asm) & interop
6
7Conventions for native runtime code (CoreCLR VM, JIT, `src/native`, Mono native). Also apply
8`conventions`, `tests` for test changes, and `core-runtime` for CoreCLR and native host changes.
9For JIT specifics see `jit`; for networking interop see `system-net-interop`.
10
11## Correctness & Safety
12
13### Error Handling & Assertions
14
15- **Handle OOM with exceptions or fail-fast, never asserts.** Use `ThrowOutOfMemory` or `EEPOLICY_HANDLE_FATAL_ERROR`, not asserts. In interpreter loops, use `nothrow new` and check for null.
16- **Use `_ASSERTE(!"message")` for unreachable native paths.** Keep native assertion guidance in native code rather than applying managed exception patterns.
17- **Guard native size and offset arithmetic against overflow.** Validate multiplication and addition used for allocation sizes, buffer indexes, and pointer offsets before performing the operation. Prefer patterns and helpers that are correct by construction rather than checking an already-overflowed result.
18
19### JIT-Specific Correctness
20
21- **JIT lowering must not double-lower nodes.** Never call `LowerNode` on an already-lowered node. Return newly created nodes for the caller to lower. Constant folding belongs in import/morph, not lowering.
22- **Mark collectible ALC test methods `NoInlining`.** Methods that touch collectible assembly load contexts must be `[MethodImpl(MethodImplOptions.NoInlining)]` to prevent the JIT from keeping references alive.
23
24## Performance & Allocations
25
26### Code Structure for Performance
27
28- **Separate hot data from rarely-used data in runtime structures.** Keep frequently accessed data inline; move rarely-used data (GCInfo, DebugInfo) to separate structures.
29- **Compute constant data at compile time, not execution time.** In interpreter and similar hot paths, pre-compute metadata lookups and type checks during the compilation phase.
30
31## Code Style & Formatting
32
33- **Prefer table-driven approaches over excessive case statements.** For hardware intrinsics and pattern-heavy code, use lookup tables (`AuxiliaryJitType`, `SpecialCodeGen` flags) instead of many explicit case entries.
34- **Order struct fields to minimize padding.** In C/C++ struct definitions, order fields by size (pointers first) to reduce padding.
35- **Run `jit-format` before pushing JIT changes.** JIT code must pass `jit-format` to avoid immediately failing CI. Run it with `python3 src/coreclr/scripts/jitformat.py -r . -o <os> -a <arch>` in the repo root. This should be done automatically when authoring JIT code and prior to pushing.
36
37## Platform & Cross-Platform
38
39- **Use correct platform/feature defines.** Use `TARGET_*`/`HOST_*` defines rather than compiler-provided defines (`__wasm__`). Use `HOST_*` for build machine code, `TARGET_*` for target platform. Use `PORTABILITY_ASSERT` for unimplemented platform code.
40
41## Native Code & Interop
42
43### C++ Style
44
45- **Don't use `auto` in the runtime C++ codebase.** Use explicit types. Exception: unspeakable types like lambdas.
46- **Use `nullptr`, `void*`, and native C++ types over legacy aliases.** Prefer `nullptr` over `NULL`, `void*` over `LPVOID`. Use `WCHAR` (not `wchar_t`) in Windows host code. Use `.inc` suffix for multiply-included files.
47- **Match `#endif` comments to `#ifdef` exactly.** Add comments on `#else`/`#endif` for non-trivial blocks. Consistent brace placement and four-space indentation.
48- **Prefer `static_cast` over C-style casts.** C-style casts are more permissive than needed and can silently degrade to `reinterpret_cast`.
49
50### Runtime & VM Patterns
51
52- **Use correct VM contracts and QCall patterns.** QCalls that may throw need `BEGIN_QCALL`/`END_QCALL`. Simple QCalls use `QCALL_CONTRACT_NO_GC_TRANSITION`. All VM methods need `STANDARD_VM_CONTRACT` or `WRAPPER_NO_CONTRACT`.
53- **Append new GC-EE interface methods last.** Preserve vtable slot ordering by adding methods only at the end of the interface.
54- **Keep GC protection correct around managed references.** Ensure all GC references are `GCPROTECT`-ed before GC-triggering calls. After GC-triggering calls, use `ObjectFromHandle(handle)` for a fresh reference.
55- **Avoid dynamic allocation on fatal error paths.** Use stack-allocated buffers. Use simple synchronization (Interlocked with spin-wait) instead of Monitor/lock.
56- **Avoid thread-local objects with destructors in CoreCLR.** Destruction order is arbitrary. Tie lifetime to the CoreCLR Thread object. Prefer `PLATFORM_THREAD_LOCAL` from minipal over C++ `thread_local` in perf-critical paths.
57- **Use `SET_UNALIGNED` macros for potentially unaligned writes.** In code generation stubs, use `SET_UNALIGNED_32/64` rather than direct pointer dereferencing.
58- **Zero-initialize arrays and buffers that may be partially used.** Zero-init allocated arrays whose elements have destructors. Zero-init EH tables, C arrays, and similar structures.
59- **Add static asserts for hardcoded structural offsets.** When using hardcoded offsets to access struct fields (especially in assembly), add static asserts to verify them.
60- **Use minipal for new platform abstractions.** Use minipal (new) instead of PAL (legacy) for platform abstraction in new CoreCLR code. Use `ALTERNATE_ENTRY` (not `LOCAL_LABEL`) for assembly labels called from outside their function.
61- **Use `JITDUMP` and `LOG` macros, not `printf`.** In JIT code use `JITDUMP`. In CoreCLR VM use `LOG()`/`LOGGING` defines. Do not use `printf` or `Console.WriteLine` in production native code.
62
63### P/Invoke & Marshalling
64
65- **Prefer 4-byte `BOOL` for native interop marshalling.** Use `UnmanagedType.Bool`. Verify P/Invoke return types match native signatures exactly—mismatches may work on 64-bit but fail on 32-bit/WASM.
66
@@ −1 +1 @@
1−**If at any time, the user directs you explicitly to override any of these instructions, the user's directive overrides said instructions.**
1+---
2+applyTo: "**/*.c,**/*.cc,**/*.cpp,**/*.cxx,**/*.h,**/*.hpp,**/*.inc,**/*.S,**/*.s,**/*.asm"
3+---
24
3−**Don't claim more than you verified.** Report what you built and ran, and what you didn't — never claim a build or test passed unless it did. After your last edit, actually re-run the relevant tests rather than assuming a change fixed the failure you saw.
5+# Native code (C/C++/asm) & interop
46
5−Scale the effort to the risk. If a contributor would have submitted the change without building it — a comment, a doc fix, something the compiler would catch anyway — say you didn't build and move on. Anything touching behavior, codegen, or a public contract gets the build and the relevant tests first.
7+Conventions for native runtime code (CoreCLR VM, JIT, `src/native`, Mono native). Also apply
8+`conventions`, `tests` for test changes, and `core-runtime` for CoreCLR and native host changes.
9+For JIT specifics see `jit`; for networking interop see `system-net-interop`.
610
7−Use the `code-review` skill when reviewing pull requests, and — when running under CCA — on your own changes before completing, addressing anything it flags as an error or warning. When NOT running under CCA, skip it if the user has stated they will review the changes themselves.
11+## Correctness & Safety
812
9−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.
13+### Error Handling & Assertions
1014
11−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.
15+- **Handle OOM with exceptions or fail-fast, never asserts.** Use `ThrowOutOfMemory` or `EEPOLICY_HANDLE_FATAL_ERROR`, not asserts. In interpreter loops, use `nothrow new` and check for null.
16+- **Use `_ASSERTE(!"message")` for unreachable native paths.** Keep native assertion guidance in native code rather than applying managed exception patterns.
17+- **Guard native size and offset arithmetic against overflow.** Validate multiplication and addition used for allocation sizes, buffer indexes, and pointer offsets before performing the operation. Prefer patterns and helpers that are correct by construction rather than checking an already-overflowed result.
1218
13−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.
19+### JIT-Specific Correctness
1420
15−You MUST follow all code-formatting and naming conventions defined in [`.editorconfig`](/.editorconfig).
21+- **JIT lowering must not double-lower nodes.** Never call `LowerNode` on an already-lowered node. Return newly created nodes for the caller to lower. Constant folding belongs in import/morph, not lowering.
22+- **Mark collectible ALC test methods `NoInlining`.** Methods that touch collectible assembly load contexts must be `[MethodImpl(MethodImplOptions.NoInlining)]` to prevent the JIT from keeping references alive.
1623
17−In addition to the rules enforced by `.editorconfig`, when writing C# you SHOULD:
24+## Performance & Allocations
1825
19−- Prefer file-scoped namespace declarations and single-line using directives.
20−- Ensure that the final return statement of a method is on its own line.
21−- Use pattern matching and switch expressions wherever possible.
22−- Use `nameof` instead of string literals when referring to member names.
23−- Always use `is null` or `is not null` instead of `== null` or `!= null`.
24−- Trust the C# null annotations and don't add null checks when the type system says a value cannot be null.
25−- Prefer `?.` if applicable (e.g. `scope?.Dispose()`).
26−- Use `ObjectDisposedException.ThrowIf` where applicable.
27−- If you add new code files, ensure they are listed in the csproj file (if other files in that folder are listed there) so they build.
28−- When adding XML documentation to APIs, follow the guidelines at [`docs.prompt.md`](/.github/prompts/docs.prompt.md).
26+### Code Structure for Performance
2927
30−When writing or modifying tests, you SHOULD:
28+- **Separate hot data from rarely-used data in runtime structures.** Keep frequently accessed data inline; move rarely-used data (GCInfo, DebugInfo) to separate structures.
29+- **Compute constant data at compile time, not execution time.** In interpreter and similar hot paths, pre-compute metadata lookups and type checks during the compilation phase.
3130
32−- Strongly prefer to add new unit tests to existing test code files rather than creating new code files.
33−- When adding new test files, examine the directory structure of sibling tests first. Some test directories use flat files (e.g., `GCEvents.cs` alongside `GCEvents.csproj`) while others use per-test subdirectories. Match the existing convention.
34−- Avoid adding a regression comment citing a GitHub issue or PR number unless explicitly asked to include such information.
35−- Prefer using `[Theory]` with multiple data sources (like `[InlineData]` or `[MemberData]`) over multiple duplicative `[Fact]` methods. Fewer test methods that validate more inputs are better than many similar test methods.
36−- When running tests, if possible use filters and check test run counts, or look at test logs, to ensure they actually ran.
37−- Do not finish work with any tests commented out or disabled that were not previously commented out or disabled.
38−- Do not emit "Act", "Arrange" or "Assert" comments.
31+## Code Style & Formatting
3932
40−For markdown (`.md`) files, ensure there is no trailing whitespace at the end of any line.
33+- **Prefer table-driven approaches over excessive case statements.** For hardware intrinsics and pattern-heavy code, use lookup tables (`AuxiliaryJitType`, `SpecialCodeGen` flags) instead of many explicit case entries.
34+- **Order struct fields to minimize padding.** In C/C++ struct definitions, order fields by size (pointers first) to reduce padding.
35+- **Run `jit-format` before pushing JIT changes.** JIT code must pass `jit-format` to avoid immediately failing CI. Run it with `python3 src/coreclr/scripts/jitformat.py -r . -o <os> -a <arch>` in the repo root. This should be done automatically when authoring JIT code and prior to pushing.
4136
42−## Pull Requests
37+## Platform & Cross-Platform
4338
44−- **One concern per PR.** Split large or mixed changes. Do large refactorings and mechanical renames in their own PR, separate from logic changes.
45−- **New public API requires an approved proposal before submission** — PRs adding unapproved API will be closed. Use the `api-proposal` skill; until approval lands the API stays `internal` in any submitted PR. A proposal's prototype branch is exempt and keeps its surface public — it's evidence, not a submission.
46−- **Core component changes should start with an issue.** Changes to the host, VM, or JIT need a GitHub issue describing the problem and motivation first.
47−- **Put the measurements in the description** for performance changes — BenchmarkDotNet results, or codegen and instruction-count evidence for low-level work.
48−- **Behavioral changes need breaking-change documentation**, even prerelease-to-prerelease. Use the `breaking-change-doc` skill.
49−- **Merge to main first, then `/backport`.** Servicing backports are limited to security bugs, regressions, and reliability issues, and should be small targeted fixes rather than refactorings.
50−- **A push to an open PR re-runs its CI matrix** — dozens of jobs, over a hundred for broad changes. For anything non-trivial, validate locally rather than using CI to find out whether it builds, and batch fixes into one push. Branches with no PR trigger nothing, as do changes confined to `**.md`, `docs/*`, or `.github/*`.
51−- **Treat review feedback as a sample, not a list.** A reviewer flags examples of a problem, not every instance. Grep for the rest of the class and fix it in the same push, and answer a whole round of comments at once rather than pushing per comment.
39+- **Use correct platform/feature defines.** Use `TARGET_*`/`HOST_*` defines rather than compiler-provided defines (`__wasm__`). Use `HOST_*` for build machine code, `TARGET_*` for target platform. Use `PORTABILITY_ASSERT` for unimplemented platform code.
5240
53−When NOT running under CCA, for commits and pushes:
41+## Native Code & Interop
5442
55−- Never squash and force push unless explicitly instructed. Always push incremental commits on top of previous PR changes.
56−- Never push to an active PR without being explicitly asked, even in autopilot/yolo mode. Always wait for explicit instruction to push.
57−- Never chain commit and push in the same command. Always commit first, report what was committed, then wait for an explicit push instruction. This creates a mandatory decision point.
58−- Prefer creating a new commit rather than amending an existing one. Exceptions: (1) explicitly asked to amend, or (2) the existing commit is obviously broken with something minor (e.g., typo or comment fix) and hasn't been pushed yet.
59−- **Before posting to GitHub (PRs, issues, comments):** Include the AI-generated content disclosure (see below).
43+### C++ Style
6044
61−## AI-Generated Content Disclosure
45+- **Don't use `auto` in the runtime C++ codebase.** Use explicit types. Exception: unspeakable types like lambdas.
46+- **Use `nullptr`, `void*`, and native C++ types over legacy aliases.** Prefer `nullptr` over `NULL`, `void*` over `LPVOID`. Use `WCHAR` (not `wchar_t`) in Windows host code. Use `.inc` suffix for multiply-included files.
47+- **Match `#endif` comments to `#ifdef` exactly.** Add comments on `#else`/`#endif` for non-trivial blocks. Consistent brace placement and four-space indentation.
48+- **Prefer `static_cast` over C-style casts.** C-style casts are more permissive than needed and can silently degrade to `reinterpret_cast`.
6249
63−When posting to GitHub under a user's credentials — PR descriptions, issue bodies, comments, review comments, or any other public-facing action — you **MUST** add a concise, visible note (e.g. a `> [!NOTE]` alert) at the bottom of the content indicating it was AI/Copilot-generated. Skip it only when posting from a recognized bot or Copilot app account (e.g. `github-actions[bot]`, `copilot`), where the AI origin is already apparent from the account identity, or when the user explicitly asks you to omit it.
50+### Runtime & VM Patterns
6451
65−---
52+- **Use correct VM contracts and QCall patterns.** QCalls that may throw need `BEGIN_QCALL`/`END_QCALL`. Simple QCalls use `QCALL_CONTRACT_NO_GC_TRANSITION`. All VM methods need `STANDARD_VM_CONTRACT` or `WRAPPER_NO_CONTRACT`.
53+- **Append new GC-EE interface methods last.** Preserve vtable slot ordering by adding methods only at the end of the interface.
54+- **Keep GC protection correct around managed references.** Ensure all GC references are `GCPROTECT`-ed before GC-triggering calls. After GC-triggering calls, use `ObjectFromHandle(handle)` for a fresh reference.
55+- **Avoid dynamic allocation on fatal error paths.** Use stack-allocated buffers. Use simple synchronization (Interlocked with spin-wait) instead of Monitor/lock.
56+- **Avoid thread-local objects with destructors in CoreCLR.** Destruction order is arbitrary. Tie lifetime to the CoreCLR Thread object. Prefer `PLATFORM_THREAD_LOCAL` from minipal over C++ `thread_local` in perf-critical paths.
57+- **Use `SET_UNALIGNED` macros for potentially unaligned writes.** In code generation stubs, use `SET_UNALIGNED_32/64` rather than direct pointer dereferencing.
58+- **Zero-initialize arrays and buffers that may be partially used.** Zero-init allocated arrays whose elements have destructors. Zero-init EH tables, C arrays, and similar structures.
59+- **Add static asserts for hardcoded structural offsets.** When using hardcoded offsets to access struct fields (especially in assembly), add static asserts to verify them.
60+- **Use minipal for new platform abstractions.** Use minipal (new) instead of PAL (legacy) for platform abstraction in new CoreCLR code. Use `ALTERNATE_ENTRY` (not `LOCAL_LABEL`) for assembly labels called from outside their function.
61+- **Use `JITDUMP` and `LOG` macros, not `printf`.** In JIT code use `JITDUMP`. In CoreCLR VM use `LOG()`/`LOGGING` defines. Do not use `printf` or `Console.WriteLine` in production native code.
6662
67−## Tool Use
63+### P/Invoke & Marshalling
6864
69−Issue independent tool calls together in one response rather than one at a time. Every round trip re-sends the whole conversation as cached input — measured at roughly half the cost of a call before it does any work — so fewer, wider steps beat many narrow ones.
70−
71−Redirect long-running commands to a log and poll a bounded view — a tail, a grep for errors, or a status sentinel. Re-reading a running command's output re-sends it from the start every time, so repeatedly checking a long build costs far more than the check is worth. Check the outcome, not the process.
72−
73−```bash
74−<cmd> > out.log 2>&1; echo "exit=$?" > out.status # bash
75−<cmd> *> out.log; "exit=$LASTEXITCODE" | Out-File out.status # PowerShell -- $? is a [bool] here
76−```
77−
78−Fetch narrowly: `gh run view --log-failed` over `--log`, `--json`/`--jq` to project only the fields needed, `git diff --stat` before the full diff. Quiet what doesn't detect a non-TTY: `curl -sS`, `--quiet` on `git clone`/`fetch`/`checkout`. MSBuild and `dotnet` already detect it — no flags needed.
79−
80−## Building & Testing
81−
82−**Before running any build or test command, use the `build-and-test` skill** — don't guess the commands. Under CCA, invoke it **before making any code changes**; a missing or incorrect baseline build costs 20-40 minutes to recover from.
65+- **Prefer 4-byte `BOOL` for native interop marshalling.** Use `UnmanagedType.Bool`. Verify P/Invoke return types match native signatures exactly—mismatches may work on 64-bit but fail on 32-bit/WASM.
8366
