What problem does it solve? When adding or modifying any Copilot, agent, LLM, tool, permission, sandbox, MCP, telemetry, or configuration control in VS Code, contributors must decide where the enterprise policy belongs—runtime managed settings, a VS Code configuration policy, an extension policy, or a split implementation. Choosing the wrong channel leads to duplicated enforcement, silently ignored settings, or deprecated policy paths. ## Core Features & Use Cases - Decision routing: A flowchart routes each control to the correct destination based on where the governed behavior is implemented, with dedicated guides for SDK/runtime managed settings, VS Code configuration policy, extension policy, split runtime/editor control, and pre-1.133 permission-policy migration. - Managed settings reference: Documents the canonical flattened dot-path bag, the three delivery channels (native MDM, server-managed, file-based) with per-key precedence, structured JSON-string encoding, and the projection checklist for declaring managed-settings keys on policies. - Export and testing workflow: Prescribes running npm run export-policy-data for every policy change and using the mock policy server for local testing of managed-settings responses. - Use Case: A contributor adding a new Copilot agent permission control uses this Skill to determine it belongs in the runtime managed-settings schema, then follows the projection checklist to declare the key, attach it to a policy, and export the policy catalog. ## Quick Start Ask the assistant to use the policy-and-managed-settings skill to decide where a new Copilot enterprise control should be implemented and walk through the required declaration and export steps.
