Add .NET P/Invoke skill#54
Conversation
…er and README conventions
…ct references - Expand frontmatter description with trigger info (when to use / not use) - Remove redundant When to Use / When Not to Use body sections - Trim type mapping to dangerous-only entries inline; full table in references/type-mapping.md - Move blittable structs, common pitfalls, failure modes, resources to references/ - Reduce SKILL.md from ~510 to 285 lines
… portability notes
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
There was a problem hiding this comment.
Pull request overview
This pull request introduces comprehensive P/Invoke guidance for .NET, covering both modern (LibraryImport) and legacy (DllImport) approaches to native interop. The skill provides practical documentation for type mapping, memory management, string marshalling, error handling, and cross-platform concerns, along with evaluation tests to ensure agents generate correct P/Invoke declarations.
Changes:
- Added a new
dotnet-pinvokeskill with main documentation (405 lines), type mapping reference, and diagnostics guide - Introduced evaluation scenarios testing P/Invoke code generation for both .NET 8 (LibraryImport) and .NET Framework (DllImport)
- Documented dangerous type mappings (e.g.,
CLong,nuint), memory ownership patterns, SafeHandle usage, and callback handling
Reviewed changes
Copilot reviewed 4 out of 4 changed files in this pull request and generated 7 comments.
| File | Description |
|---|---|
| src/dotnet/skills/dotnet-pinvoke/SKILL.md | Main skill documentation covering P/Invoke workflow, type mapping, memory management, callbacks, and validation (405 lines, within 500 line limit) |
| src/dotnet/skills/dotnet-pinvoke/references/type-mapping.md | Comprehensive native-to-.NET type mapping reference with dangerous types, blittable types, and struct layout patterns |
| src/dotnet/skills/dotnet-pinvoke/references/diagnostics.md | Common pitfalls table, failure modes, debugging strategies, and resource links |
| src/dotnet/tests/dotnet-pinvoke/eval.yaml | Test scenarios for generating LibraryImport (.NET 8) and DllImport (.NET Framework) declarations from C headers |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
|
some thoughts
|
SKILLs are about a single task, not a complete dev workflow. This is merely about helping to write P/Invokes. The validation metric is captured in the SKILL itself as to what is correct and not.
When the P/Invoke has been written. I'm not entirely clear as to how you're viewing skills in this case. The layout and flow here follows the anthropic skills approach. How are you viewing these tools? |
Well, I'm learning, but if you mean https://platform.claude.com/docs/en/agents-and-tools/agent-skills/best-practices it includes examples of 'workflows' with validation steps. perhaps it doesn't apply here. |
Oh, nice! I didn't see find this guidance. Solid, let's suggest having it review this. |
|
added a note above about warning about docs |
|
Validation for this skill can be found at #58. |
…d clarify agent behavior
Skill Validation Results
Model: claude-opus-4.6 | Judge: claude-opus-4.6 |
|
|
||
| ## Reference Files | ||
|
|
||
| - **[references/type-mapping.md](references/type-mapping.md)** — Complete native-to-.NET type mapping table, struct layout patterns, blittable type rules |
There was a problem hiding this comment.
in what circumstances would we not want it to read this file? if it should always read it then presumably it should be inline (optional load is the reason for the references pattern)
(I mentioned this earlier but not sure of your answer)
There was a problem hiding this comment.
Do you know the best way to encode that decision?
There was a problem hiding this comment.
My latest commit has added something to the references below.
|
I ran my tool on it dotnet-pinvoke Skill AssessmentWhat's Done Well
Issues (by severity)
SummaryThis is a strong knowledge-driven skill with excellent domain depth from Aaron Robinson (the .NET interop expert). The #1 fix is adding stop signals — without them, an agent given a simple "write a P/Invoke for CreateFile" will march through all 8 steps including migration and tooling sections. The #2 fix (When to Use section) is structural and easy. Both are quick wins. Source
was the result and Was the first round of improvements it suggested. Thoughts? |
I think this is a valid set of feedback. Some I think are obvious, others I'm less inclined to agree with but I'd like to discuss in a PR. Let's go with your suggestion here and when this gets merged, we can consider that feedback. |
…type mapping and diagnostics
|
I'm going to merge this for now. Let's iterate on it with Larry's tooling. |
This pull request adds comprehensive reference documentation and new evaluation scenarios to improve .NET P/Invoke usability and correctness. The main changes include the addition of diagnostic and type mapping guides for native interop, as well as new test scenarios to ensure correct generation of P/Invoke declarations for both .NET 8 and .NET Framework targets.
Documentation Enhancements
diagnostics.mdreference guide covering common P/Invoke pitfalls, failure modes, debugging strategies, and key resources. This guide helps developers avoid and troubleshoot interop bugs, with practical advice for signature matching, memory management, and error handling.type-mapping.mdreference documenting precise mappings between C/Win32 types and .NET types, highlighting dangerous types, blittable types, and struct layout considerations. This is crucial for preventing subtle interop bugs due to type mismatches.Testing Improvements
eval.yamlto test the generation of P/Invoke declarations from C headers for both .NET 8 (usingLibraryImport) and .NET Framework (usingDllImport). The scenarios assert correct type mapping (e.g., usingnuintforsize_t) and method signature style, ensuring robust code generation across platforms.