원클릭으로 Manus에서 모든 스킬 실행

dotnet-managedcode-storage

스타41

포크9

업데이트2026년 4월 19일 19:47

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.

설치

Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.

Manus에서 실행

출처

managedcode

managedcode/PrompterOne

GitHub 저장소 열기 Creator 저장소 보기

다운로드

Manus에서 실행

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

이 저장소의 다른 Skills

같은 저장소

dotnet-analyzer-config

managedcode/PrompterOne

Use a repo-root `.editorconfig` to configure free .NET analyzer and style rules. Use when a .NET repo needs rule severity, code-style options, section layout, or analyzer ownership made explicit. Nested `.editorconfig` files are allowed when they serve a clear subtree-specific purpose.

2026-04-1941

dotnet-aspnet-core

managedcode/PrompterOne

Build, debug, modernize, or review ASP.NET Core applications with correct hosting, middleware, security, configuration, logging, and deployment patterns on current .NET.

2026-04-1941

dotnet-biome

managedcode/PrompterOne

Use Biome in .NET repositories that ship Node-based frontend assets and want a fast combined formatter-linter-import organizer for JavaScript, TypeScript, CSS, JSON, GraphQL, or HTML. Use when a repo prefers a modern all-in-one CLI over a larger ESLint plus Prettier style stack.

2026-04-1941

dotnet-blazor

managedcode/PrompterOne

Build and review Blazor applications across server, WebAssembly, web app, and hybrid scenarios with correct component design, state flow, rendering, and hosting choices.

2026-04-1941

dotnet-code-analysis

managedcode/PrompterOne

Use the free built-in .NET SDK analyzers and analysis levels with gradual Roslyn warning promotion. Use when a .NET repo needs first-party code analysis, `EnableNETAnalyzers`, `AnalysisLevel`, or warning-as-error policy wired into build and CI.

2026-04-1941

dotnet-csharpier

managedcode/PrompterOne

Use the open-source free `CSharpier` formatter for C# and XML. Use when a .NET repo intentionally wants one opinionated formatter instead of a highly configurable `dotnet format`-driven style model.

2026-04-1941

name	dotnet-managedcode-storage
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

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