Update docs to reflect convention-to-SEP evolution; link to charter (#78)

docs/approaches.md

@@ -17,6 +17,8 @@ Several design considerations are emerging from community discussion:
 
 The approaches below span a spectrum. At one end, skills become a first-class MCP primitive with dedicated protocol methods (Approach 1). At the other, existing primitives are used with documented conventions (Approach 6). A key question for this IG is whether convention can prove patterns before standardization — or whether the ecosystem needs protocol-level support to achieve reliable interoperability. These are not mutually exclusive; convention work can inform and de-risk a future protocol extension.
 
+**Current status:** The convention approach (Approach 6) was pursued and quickly evolved into a formal Extensions Track SEP ([#69](https://github.com/modelcontextprotocol/experimental-ext-skills/pull/69)), building on convergence across 4+ independent `skill://` implementations. The SEP uses existing Resources primitives with zero protocol changes, positioning it between pure convention and a new primitive. See [#75](https://github.com/modelcontextprotocol/experimental-ext-skills/issues/75) for tracking.
+
 ## 1. Skills as Distinct MCP Primitives
 
 Add Agent Skills as a first-class, discoverable primitive in MCP. A skill is a named bundle of instructions plus references to tools, prompts, and resources that together teach an agent how to perform a domain-specific workflow.
@@ -60,6 +62,7 @@ Examples:
 - Expose skills via tools like `list_skills` and `read_skills`. Server instructions can direct the agent to call the skill tool first.
 - Expose skills as resources (e.g. skill://...), which can also be exposed through tools
 
+**See also:** [#41](https://github.com/modelcontextprotocol/experimental-ext-skills/issues/41) — Server-side reference implementation, [#55](https://github.com/modelcontextprotocol/experimental-ext-skills/issues/55) — Recommended _meta keys for skill resources
 
 **Implementations:** 
 
@@ -97,6 +100,8 @@ Several design considerations have been suggested in community discussion and pr
 - **Git-based distribution:** Versioned distribution via git (tags, pinned refs) can be viable without a formal registry. Clare Liguori (AWS) noted that Terraform operated without a formal registry for a long time — Feb 26 office hours.
 - **Domain-level discovery:** The [Agent Skills Discovery RFC](https://github.com/cloudflare/agent-skills-discovery-rfc) proposes `/.well-known/skills/` for organizations to publish skills at predictable URLs with content integrity (SHA-256 digests). This is complementary to MCP — it handles discovery and distribution while MCP handles runtime consumption.
 
+**See also:** [#44](https://github.com/modelcontextprotocol/experimental-ext-skills/issues/44) — Define well-known URI schemes and naming patterns for skill resources
+
 **Community input:**
 
 > "Installless/temporary/ephemeral skill availability while server is installed feels like a good pattern. Clients could optionally offer to permanently install." — [Sam Morrow](https://github.com/SamMorrowDrums) (GitHub), via Discord
@@ -113,6 +118,8 @@ Instead of exposing skill tools to the main agent, use MCP's Sampling with Tools
 
 **Source:** [jbnitorum](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2076#issuecomment-3806151745)
 
+**See also:** [#42](https://github.com/modelcontextprotocol/experimental-ext-skills/issues/42) — Test skills-via-sampling approach
+
 ## 4. Gateway/Composition Pattern
 
 A gateway-style server that provides a group of MCPs as one, ensuring they get requisite configuration and instructions to work in harmony.
@@ -131,6 +138,8 @@ Use server instructions as a pointer to a resource: "If you need to do X, fetch
 
 ## 6. Official Convention as Intermediate Step
 
+> **Status:** This approach was pursued and graduated into the draft [Skills Extension SEP](https://github.com/modelcontextprotocol/experimental-ext-skills/pull/69) ([#75](https://github.com/modelcontextprotocol/experimental-ext-skills/issues/75)). The SEP formalizes the convention as an Extensions Track specification using existing Resources primitives — zero protocol changes, backward compatible. Content format is delegated to [agentskills.io](https://agentskills.io/specification). The text below is preserved as historical context for how this approach was originally framed.
+
 A documented "MCP Skills Convention" as a middle path between ad-hoc experiments and protocol extension. This could:
 
 - Define well-known URI schemes or naming patterns (e.g., resources matching `**/SKILL.md`). See [Skill URI Scheme Proposal](skill-uri-scheme.md) for a detailed survey and recommendation.
@@ -139,7 +148,7 @@ A documented "MCP Skills Convention" as a middle path between ad-hoc experiments
 - Be documented in MCP docs as a "Pattern" — not in protocol schema, but officially recommended
 - Allow data gathering on adoption before considering protocol-level changes
 
-This mirrors how other ecosystems (e.g., Kubernetes) graduate patterns: start as convention, prove value, then formalize. Could be a concrete IG deliverable: "MCP Skills Convention v0.1."
+This mirrors how other ecosystems (e.g., Kubernetes) graduate patterns: start as convention, prove value, then formalize.
 
 **Advantages of the convention approach:**
 

docs/experimental-findings.md

@@ -1,5 +1,7 @@
 # Experimental Findings
 
+> **Contributing findings?** See [#50](https://github.com/modelcontextprotocol/experimental-ext-skills/issues/50) for the contribution template proposal.
+
 ## McpGraph: Skills in MCP Server Repo
 
 **Repo:** [TeamSparkAI/mcpGraph](https://github.com/TeamSparkAI/mcpGraph)
@@ -86,3 +88,5 @@ Multiple community members have independently reported that models do not reliab
 > "Skills are ephemeral and/or time decaying — it clicks once and then give it some time and they lose the plot." — Kryspin (qcompute), via Discord
 
 > "I've seen lazy load skills with various degrees of success, actually looks like it might be model specific… [best pattern is] putting them in with a subagent that similarly named or mentions the topic in their description." — Kryspin (qcompute), via Discord
+
+**See also:** [#37](https://github.com/modelcontextprotocol/experimental-ext-skills/issues/37) — Compare skill delivery mechanisms: file-based vs MCP-based

docs/open-questions.md

@@ -2,6 +2,8 @@
 
 ## 1. Is this a registry problem or an MCP server problem?
 
+> **See also:** [#44](https://github.com/modelcontextprotocol/experimental-ext-skills/issues/44) — Define well-known URI schemes and naming patterns for skill resources
+
 Should skills be discoverable through registry metadata ("if you install this server, also install this skill") or contained within the MCP server itself?
 
 A third option is emerging: domain-level discovery via `/.well-known/skills/` (see [Agent Skills Discovery RFC](https://github.com/cloudflare/agent-skills-discovery-rfc)). This decouples skill discovery from both registries and MCP servers — an organization publishes skills at a predictable URL on its own domain. This could complement MCP-level discovery rather than replace it: `.well-known` handles "find available skills," MCP handles "load and use them at runtime."
@@ -18,6 +20,8 @@ Or is the separation between "primitive server" and "skill that uses the primiti
 
 ## 4. How should skills relate to multiple servers?
 
+> **Tracked in:** [#39](https://github.com/modelcontextprotocol/experimental-ext-skills/issues/39) — Research skill dependency declaration and host-mediated resolution
+
 A skill orchestrating tools from several servers can't live in any single server's instructions.
 
 **Related:** [agentskills/agentskills#110](https://github.com/agentskills/agentskills/issues/110) — Discusses how skills should declare their tool/server dependencies. The lack of explicit dependency configuration makes multi-server skill execution unpredictable: if required servers and tools aren't already loaded, the skill can't reliably execute.
@@ -36,6 +40,9 @@ The agentskills.io spec currently has a freeform [compatibility field](https://a
 
 ## 5. Do clients actually leverage skills when presented via MCP?
 
+> **Tracked in:** [#38](https://github.com/modelcontextprotocol/experimental-ext-skills/issues/38) — Survey client resource-loading support across major MCP clients
+> **See also:** [#37](https://github.com/modelcontextprotocol/experimental-ext-skills/issues/37) — Compare skill delivery mechanisms: file-based vs MCP-based
+
 Early experiments suggest they do, but more rigorous testing is needed.
 
 **Community input:**
@@ -48,10 +55,14 @@ Early experiments suggest they do, but more rigorous testing is needed.
 
 ## 7. What would MCP have had to get right for skills to have been shipped over MCP from the beginning?
 
+> **See also:** [#47](https://github.com/modelcontextprotocol/experimental-ext-skills/issues/47) — Create evaluation matrix mapping approaches to requirements
+
 — [Keith Groves](https://github.com/keithagroves)
 
 ## 8. What could MCP reasonably change so that it will be the obvious choice for new formats?
 
+> **See also:** [#54](https://github.com/modelcontextprotocol/experimental-ext-skills/issues/54) — The case for custom metadata instead of a URI convention
+
 — [Keith Groves](https://github.com/keithagroves)
 
 **Community input:**
@@ -94,6 +105,8 @@ Note: Some apps like Claude Code have started to indicate in the skill frontmatt
 
 ## 12. Why not just resources?
 
+> **See also:** [#54](https://github.com/modelcontextprotocol/experimental-ext-skills/issues/54) — The case for custom metadata instead of a URI convention, [#55](https://github.com/modelcontextprotocol/experimental-ext-skills/issues/55) — Define recommended _meta keys for skill resources
+
 **Core Maintainer input:**
 
 > "Why not just resources? That feels like the obvious implementation since skills are just files and resources already exist to expose files. i.e. just expose skills as resources the same as they're currently exposed on the filesystem and then just use the existing Agent Skills specification — client can find skills using resources/list to find SKILL.md files." — [Peter Alexander](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2076#discussion_r2736299627)
@@ -108,6 +121,9 @@ See also [Approaches](approaches.md) for more notes on using resources.
 
 ## 13. What is the optimal relationship between skills and MCP?
 
+> **Tracked in:** [#75](https://github.com/modelcontextprotocol/experimental-ext-skills/issues/75) — Skills Extension SEP
+> **See also:** [#47](https://github.com/modelcontextprotocol/experimental-ext-skills/issues/47) — Create evaluation matrix mapping approaches to requirements
+
 Skills already work as simple files that agents load directly. Adding MCP to the process should provide clear value beyond what standalone skills already offer.
 
 **Community input:**

docs/skill-uri-scheme.md

@@ -3,13 +3,13 @@
 > Proposed convention for identifying skill resources over MCP.
 
 **Issue:** [#44](https://github.com/modelcontextprotocol/experimental-ext-skills/issues/44)
-**Status:** Draft
+**Status:** Incorporated into the draft [Skills Extension SEP](https://github.com/modelcontextprotocol/experimental-ext-skills/pull/69). This survey informed the SEP's URI scheme design; see also [PR #70](https://github.com/modelcontextprotocol/experimental-ext-skills/pull/70) for subsequent refinements (multi-segment paths, path-name decoupling).
 
 ---
 
 ## Summary
 
-This document surveys existing URI patterns for skill resources across implementations, analyzes their trade-offs, and proposes a recommended `skill://` URI scheme for the MCP Skills Convention.
+This document surveys existing URI patterns for skill resources across implementations, analyzes their trade-offs, and proposes a recommended `skill://` URI scheme for skill resources over MCP.
 
 ## Survey of Existing Patterns
 

docs/use-cases.md

@@ -30,6 +30,8 @@ Skills that leverage tools from multiple off-the-shelf servers where you can't (
 
 Beyond multi-server tool orchestration, skills themselves may be composable — one skill depending on another skill's output or behavior. This extends the dependency model beyond tool availability to skill availability, and raises questions about declarative dependency metadata. See [Open Question 4](open-questions.md#4-how-should-skills-relate-to-multiple-servers) for the emerging proposal on host-mediated dependency resolution.
 
+**See also:** [#39](https://github.com/modelcontextprotocol/experimental-ext-skills/issues/39) — Skill dependency declaration, [#45](https://github.com/modelcontextprotocol/experimental-ext-skills/issues/45) — Worked examples for multi-server composition
+
 ## 4. Progressive Disclosure
 
 Skills broken into linked sets of files for effective context management, loaded progressively as the agent needs them rather than all at once.
@@ -46,6 +48,8 @@ Skills broken into linked sets of files for effective context management, loaded
 
 **Related:** [Anthropic's guidance on progressive disclosure](https://www.anthropic.com/engineering/equipping-agents-for-the-real-world-with-agent-skills)
 
+**See also:** [#45](https://github.com/modelcontextprotocol/experimental-ext-skills/issues/45) — Worked examples for progressive disclosure, [#40](https://github.com/modelcontextprotocol/experimental-ext-skills/issues/40) — Client-side reference implementation for model-driven resource loading
+
 ## 5. Server-Skill Pairing
 
 Servers that are difficult or impossible to use effectively without an accompanying skill.