Claude Skill

dotnet-managedcode-storage

Use ManagedCode.Storage when a .NET application needs a provider-agnostic storage abstraction with explicit configuration, container selection, upload and download flows, and backend-specific integration kept behind one library contract.

LLM Mart · 0 points · 0 0 0

Virus-scanned Reviewed automatically before listing.

Full trust report

Download postpartum-genushyacinthus29-dotnet-skills-skills_dotnet-managedcode-storage-bfa4ebd.zip · 1 KB

postpartum-genushyacinthus29/dotnet-skills 12 1 forks MIT Updated 5h ago

Part of postpartum-genushyacinthus29/dotnet-skills — 80 skills

Install

skills CLI npx skills add https://github.com/Postpartum-genushyacinthus29/dotnet-skills/tree/main/skills/dotnet-managedcode-storage

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.Storage

Trigger On

integrating ManagedCode.Storage into a .NET application
reviewing how a project abstracts file or object storage
deciding whether to centralize storage provider differences behind one library
documenting upload, download, container, or blob-handling flows with ManagedCode.Storage

Workflow

Identify the actual storage use case:
- blob or file storage
- provider abstraction across environments
- app-service integration and configuration
Verify whether the project wants one storage contract instead of provider-specific SDK calls scattered across the codebase.
Keep application code dependent on the library abstraction, not directly on backend-specific storage SDKs unless a provider-only feature is truly required.
Centralize provider configuration, credentials, and container naming in composition-root code and typed settings.
Validate the real upload, download, existence-check, and deletion flows after wiring the library.

flowchart LR
  A["Application service"] --> B["ManagedCode.Storage abstraction"]
  B --> C["Provider-specific storage implementation"]
  C --> D["Blob or object storage backend"]

Deliver

concrete guidance on when ManagedCode.Storage is the right abstraction
wiring guidance that keeps provider concerns out of business code
verification steps for the storage flows the application actually uses

Validate

the project really benefits from a storage abstraction and is not hiding provider-specific behavior it still needs
storage configuration is centralized and explicit
code reviews check real read and write paths, not only registration snippets

Files (dotnet-skills)

SKILL.md 2.1 KB

---
name: dotnet-managedcode-storage
version: "1.0.0"
category: "Data"
description: "Use ManagedCode.Storage when a .NET application needs a provider-agnostic storage abstraction with explicit configuration, container selection, upload and download flows, and backend-specific integration kept behind one library contract."
compatibility: "Requires a .NET application that integrates ManagedCode.Storage or evaluates it as a storage abstraction."
---

# ManagedCode.Storage

## Trigger On

- integrating `ManagedCode.Storage` into a .NET application
- reviewing how a project abstracts file or object storage
- deciding whether to centralize storage provider differences behind one library
- documenting upload, download, container, or blob-handling flows with ManagedCode.Storage

## Workflow

1. Identify the actual storage use case:
   - blob or file storage
   - provider abstraction across environments
   - app-service integration and configuration
2. Verify whether the project wants one storage contract instead of provider-specific SDK calls scattered across the codebase.
3. Keep application code dependent on the library abstraction, not directly on backend-specific storage SDKs unless a provider-only feature is truly required.
4. Centralize provider configuration, credentials, and container naming in composition-root code and typed settings.
5. Validate the real upload, download, existence-check, and deletion flows after wiring the library.

```mermaid
flowchart LR
  A["Application service"] --> B["ManagedCode.Storage abstraction"]
  B --> C["Provider-specific storage implementation"]
  C --> D["Blob or object storage backend"]
```

## Deliver

- concrete guidance on when ManagedCode.Storage is the right abstraction
- wiring guidance that keeps provider concerns out of business code
- verification steps for the storage flows the application actually uses

## Validate

- the project really benefits from a storage abstraction and is not hiding provider-specific behavior it still needs
- storage configuration is centralized and explicit
- code reviews check real read and write paths, not only registration snippets