Expose session-scoped in-memory skill providers

Start with the existing SessionConfigBase session configuration and the CLI 1.0.83 skillProvider.list/read callbacks, using github/copilot-sdk#2494 for context on the generated handler surface. Done means reaching maintainer agreement on a public, session-scoped provider API and its compatibility and language-parity requirements before implementation.

Use case

An SDK host may manage reusable skills in its own data store rather than in a project directory. We would like those skills to participate in Copilot's normal skill catalog and native skill tool, alongside file-based skills, without:

• materializing and synchronizing SKILL.md files;
• registering a second skill-loading tool;
• replacing the native skill tool and reimplementing its fallback/activation behavior.

Custom agents and MCP servers already have programmatic session configuration; skill content currently has no equivalent public provider in the .NET SDK.

Existing runtime support

The published CLI 1.0.83 protocol already contains the internal/experimental skillProvider.list and skillProvider.read callbacks and the hasSkillProvider session flag. It identifies these as lazy, pathless, text-only SDK skills. The .NET SDK does not expose the corresponding handwritten session registration API.

I understand that keeping these transport callbacks out of the generated public handler surface is intentional: see github/copilot-sdk#2494. This proposal is for a small, idiomatic public facade, not for making the raw internal callbacks public or changing the generator.

Proposed behavior for discussion

• An optional session-scoped provider lists skill metadata and reads complete Markdown on demand.
• Register the provider before create/resume so early runtime callbacks can be handled.
• The native skill tool performs activation; no extra tool or native-tool override.
• Re-supply the provider on resume; it is not serialized into session history.
• Leave sessions without a provider unchanged.
• Respect EnableSkills = false, native invocation flags, cancellation, and session ownership.
• Keep this text-only: no asset provider, virtual filesystem, or new storage layer.

A possible .NET shape is an experimental SessionConfigBase.SkillProvider backed by asynchronous ListAsync and ReadAsync methods. The exact API and cross-language equivalents should be aligned with the maintainers.

Investigation and prototype

A local prototype using the existing CLI 1.0.83 runtime has exercised:

• lazy native activation without skill directories;
• coexistence with native file-based skills;
• create/resume binding and reloading updated content;
• native subagent invocation and assigned-skill preloading;
• source-generated .NET JSON serialization with reflection disabled.

This is not a claim that the internal protocol is a supported public contract. I would like to confirm whether exposing this capability is on the roadmap and what public API/compatibility policy the team prefers.

Maintainer alignment

The contribution guide asks for feature discussion before a review-ready implementation and notes the need for language parity. I am opening this proposal first. A linked draft .NET PR can serve as a concrete, tested implementation for discussion; it would not imply that the feature or .NET-only rollout has been agreed.

Would the team be interested in this facade, and is there an existing planned implementation or issue it should align with?