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. USE FOR: integrating ManagedCode.Storage into a .NET application; reviewing how a project abstracts file or object storage; deciding whether to centralize storage provider. DO NOT USE FOR: unrelated stacks; generic tasks that do not need this specific guidance. INVOKES: inspect the reposit
NewMaintained
Automatic
◆Coding pack
Last verified 8/19/2026
What it changes
Passed 21 of 22 test cases with the skill, and 21 of 22 without it.
Without skill95%
With skill95%
Checks it passed that the model alone missed
Requires reviewing real end-to-end file upload, download, existence checking, and file deletion code paths.
1 fixed20 passed either way0 still failing1 broke
Pass-rate lift
0 pp
Tokens
-7%
Agent turns
0%
Response time
-21%
Model gemini-3.6-flashMeasured 8/19/2026v121 of 22 cases passed with skill
Tokens, turns and time describe resource use, not a dollar price.
See it in action
A test case the skill fixed. Same model, same prompt, with and without the skill.
Prompt
During a pull request review for a .NET document management module, what key code paths must reviewers inspect to ensure storage reliability beyond checking Startup.cs dependency injection setups?
What was checked, without and with the skill
Checked
Without skill
With skill
Requires reviewing real end-to-end file upload, download, existence checking, and file deletion code paths.
Missed
Passed
case-11 · gemini-3.6-flash · 8/19/2026 · answers are capped and redacted
What's inside
The instructions your model reads when the skill loads.
SKILL.md38 linessingle file
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