Claude
Skill
dotnet-managedcode-communication
Use ManagedCode.Communication when a .NET application needs explicit result objects, structured errors, and predictable service or API boundaries instead of exception-driven control flow.
Virus-scanned
Reviewed automatically before listing.
Download
postpartum-genushyacinthus29-dotnet-skills-skills_dotnet-managedcode-communication-bfa4ebd.zip · 0 KB
Install
skills CLI
npx skills add https://github.com/Postpartum-genushyacinthus29/dotnet-skills/tree/main/skills/dotnet-managedcode-communication
Claude Code
claude plugin marketplace add https://llmmart.ai/marketplace.json && claude plugin install postpartum-genushyacinthus29-dotnet-skills@llmmart
Git
git clone https://github.com/Postpartum-genushyacinthus29/dotnet-skills.git
The skills CLI installs just this skill, for any of its supported agents. Claude Code installs the whole postpartum-genushyacinthus29/dotnet-skills collection as a plugin from our marketplace. Git is the plain clone.
Skill manifest
ManagedCode.Communication
Trigger On
- integrating
ManagedCode.Communicationinto services or APIs - replacing exception-driven result handling with explicit results
- reviewing service boundaries that return success or failure payloads
- documenting result-pattern usage across ASP.NET Core or application services
Workflow
- Confirm the boundary where the library belongs:
- service result contracts
- application manager boundaries
- API endpoints that translate results into HTTP responses
- Keep result creation and error mapping explicit instead of mixing exceptions, nulls, and ad-hoc tuples.
- Pattern-match result objects at the boundary that converts them into user-facing responses.
- Do not hide domain failures behind generic success wrappers.
- Validate positive, negative, and error-path handling after integration.
flowchart LR A["Domain or service operation"] --> B["ManagedCode.Communication result"] B --> C["Application or API boundary"] C --> D["HTTP response or caller-visible contract"]
Deliver
- guidance on where explicit result objects improve clarity
- usage boundaries for translating results into API or caller responses
- validation expectations for success and failure flows
Validate
- result handling is consistent across the boundary that uses the library
- callers do not fall back to exception-only logic for normal failure cases
- negative and error scenarios are documented and tested
Files (dotnet-skills)
-
SKILL.md 1.8 KB
--- name: dotnet-managedcode-communication version: "1.0.0" category: "Core" description: "Use ManagedCode.Communication when a .NET application needs explicit result objects, structured errors, and predictable service or API boundaries instead of exception-driven control flow." compatibility: "Requires a .NET application, service layer, or API boundary that integrates ManagedCode.Communication." --- # ManagedCode.Communication ## Trigger On - integrating `ManagedCode.Communication` into services or APIs - replacing exception-driven result handling with explicit results - reviewing service boundaries that return success or failure payloads - documenting result-pattern usage across ASP.NET Core or application services ## Workflow 1. Confirm the boundary where the library belongs: - service result contracts - application manager boundaries - API endpoints that translate results into HTTP responses 2. Keep result creation and error mapping explicit instead of mixing exceptions, nulls, and ad-hoc tuples. 3. Pattern-match result objects at the boundary that converts them into user-facing responses. 4. Do not hide domain failures behind generic success wrappers. 5. Validate positive, negative, and error-path handling after integration. ```mermaid flowchart LR A["Domain or service operation"] --> B["ManagedCode.Communication result"] B --> C["Application or API boundary"] C --> D["HTTP response or caller-visible contract"] ``` ## Deliver - guidance on where explicit result objects improve clarity - usage boundaries for translating results into API or caller responses - validation expectations for success and failure flows ## Validate - result handling is consistent across the boundary that uses the library - callers do not fall back to exception-only logic for normal failure cases - negative and error scenarios are documented and tested
Comments (0)
Sign in to join the conversation.
Reviews (0)
No reviews yet.
No comments yet.