changed to skill provider

docs/skills/copilot-customization/SKILL.md

@@ -1,23 +1,6 @@
 ---
 name: copilot-customization
 description: 'Plan, create, review, and debug GitHub Copilot and VS Code agent customizations, including instructions, prompt files, skills, custom agents, hooks, MCP servers, and repo-specific personal-mcp skill integration.'
-x-personal-mcp:
-  id: copilot-customization
-  version: 1.0.0
-  tags:
-    - copilot
-    - vscode
-    - customization
-    - instructions
-    - prompts
-    - agent-skills
-    - custom-agents
-    - hooks
-    - mcp
-    - personal-mcp
-    - skills
-  capabilities:
-    - resource://skills/copilot-customization/document
 ---
 
 # Copilot Customization
@@ -78,31 +61,30 @@ Use either:
 Choose one of these patterns:
 
 1. Direct URI strategy:
-  - Reference known resources directly, such as:
-    - `resource://catalog/skills_index`
-    - `resource://catalog/skills/{skill_id}`
-    - `resource://skills/<skill-id>/document`
-    - `resource://skills/<skill-id>/references/<ref-id>`
+  - Read `skill://<skill-name>/SKILL.md` when the required skill is known.
+  - Read `skill://<skill-name>/_manifest` only when supporting material may be useful.
+  - Read selected supporting files at `skill://<skill-name>/<supporting-path>`.
 2. Discovery-first strategy:
-  - Start at catalog discovery (`resource://catalog/skills_index`), select the best skill match, then load the skill document and only the minimal references needed.
+  - List resources, compare native main-resource names and descriptions, then load the best matching `SKILL.md`.
+  - In tool-only clients, use only `list_resources` and `read_resource` for the same sequence.
 
 ### Authoring guidance for shims
 
 1. Keep shim content short and procedural; avoid copying large guidance blocks from Personal MCP.
 2. State trigger conditions clearly (for example: "when creating a new skill" or "when editing docs contracts").
-3. Specify whether to use direct URIs or discovery for that repo's common workflows.
-4. Prefer loading only the most relevant skill document first; expand to references only when needed.
+3. Specify whether to use a direct native URI or resource listing for that repo's common workflows.
+4. Prefer loading only the most relevant main file first; inspect its manifest only when needed.
 5. For stable repeated workflows, use explicit URIs. For broader or ambiguous requests, use discovery-first.
 
 ### Minimal shim examples
 
 Instruction-style shim intent:
 
-1. "For markdown edits (`applyTo: '**/*.md'`), load `resource://skills/zensical-docs/document` and apply Zensical-native documentation conventions unless they conflict with expected MkDocs compatibility."
+1. "For markdown edits (`applyTo: '**/*.md'`), load `skill://zensical-docs/SKILL.md` and apply Zensical-native documentation conventions unless they conflict with expected MkDocs compatibility."
 
 Prompt-style shim intent:
 
-1. "For docs authoring tasks, consult `resource://skills/zensical-docs/document`, summarize the relevant authoring constraints, then propose the smallest markdown change for this repository."
+1. "For docs authoring tasks, consult `skill://zensical-docs/SKILL.md`, summarize the relevant authoring constraints, then propose the smallest markdown change for this repository."
 
 ### Validation for shim implementation
 
@@ -130,7 +112,7 @@ Before finishing:
 3. Confirm names match directory names where VS Code requires it.
 4. Confirm descriptions include the phrases users are likely to ask for.
 5. Confirm extra skill resources are linked from `SKILL.md`.
-6. Confirm repo skill metadata exposes the correct `resource://skills/<skill-id>/document` capability.
+6. Confirm native discovery exposes `skill://<skill-name>/SKILL.md`, `_manifest`, and supporting-file reads.
 7. State any remaining ambiguity or user choice, such as personal vs workspace scope.
 
 ## Output Contract