docs: transition from Interest Group to Working Group (#81)

* docs: transition from Interest Group to Working Group

Follow-up to modelcontextprotocol/modelcontextprotocol#2586, which
converted the charter from IG to WG.

- Rename Interest Group → Working Group in headings and prose
- Update Discord (#skills-over-mcp-wg) and Discussions
  (meeting-notes-skills-over-mcp-wg) references; channel renames
  coordinated separately
- CONTRIBUTING.md: align meeting norms with MCP group governance
  (7-day advance notice, meet.modelcontextprotocol.io) and rewrite
  Decision-Making to reflect WG authority (lazy consensus → formal
  vote → escalation), linking to the charter's Authority table
- Keep CODEOWNERS team at skills-over-mcp-ig pending access-repo
  rename; TODO comment added
- decisions.md: update present-tense preamble, log the IG → WG
  transition as a new ADR entry, and preserve historical entries

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

* docs(contributing): link to governance/charter instead of duplicating

Meetings and Decision-Making sections now point to the MCP group
governance doc and charter for canonical rules, keeping only the
repo- or group-specific bits (notes location, coordination
channels, outputs list). Also drops a leftover "rough consensus"
IG-era phrase in the Decision Log guidelines.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

* docs(codeowners): fix sentence fragment in default-owner comment

"Has day-to-day governance" read as an incomplete sentence and
overstated what CODEOWNERS actually encodes (review routing, not
governance). Replace with a direct one-liner.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

docs/approaches.md

@@ -10,12 +10,12 @@ Several design considerations are emerging from community discussion:
 - **Don't be too prescriptive about client host behavior.** Client hosts may want to innovate on how skills are utilized (e.g., progressive disclosure) and what they can even *be*. The goal is uniform discovery and consumption patterns from the server author's perspective, while leaving room for client-side innovation.
 - **Don't assume how tool paradigms will evolve.** The conceptual surface of skills shouldn't bake in assumptions about how tools develop. That doesn't preclude skills being implemented as a well-known tool, but the design should not couple skills to any particular tool evolution path.
 - **Let the primitive choice follow from the use case.** The answer may not be "resources" or "new primitive" — it may be both, depending on the interaction pattern. Some skills are context for the model. Some are context for the human. Some are both. The delivery mechanism should support that range. ([See related thread on SEP 2076](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2076#discussion_r2736299627))
-- **Minimize ecosystem complexity.** The broader AI tooling ecosystem is experiencing complexity fatigue — too many overlapping concepts (servers, skills, plugins, hooks, agents) erode credibility and adoption. Whatever approach the IG recommends should reuse existing MCP primitives where possible and only introduce new surface area when there's a clear case that existing primitives can't serve the need. ([See related issue](https://github.com/modelcontextprotocol/experimental-ext-skills/issues/14))
+- **Minimize ecosystem complexity.** The broader AI tooling ecosystem is experiencing complexity fatigue — too many overlapping concepts (servers, skills, plugins, hooks, agents) erode credibility and adoption. Whatever approach the WG recommends should reuse existing MCP primitives where possible and only introduce new surface area when there's a clear case that existing primitives can't serve the need. ([See related issue](https://github.com/modelcontextprotocol/experimental-ext-skills/issues/14))
 - **Skills are context, and the pattern extends beyond workflows.** The skill format and progressive disclosure pattern apply equally to organizational knowledge and in-context learning — not just tool-usage workflows.
 
 ## Central Tension: Convention vs. Protocol Extension
 
-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.
+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 WG 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.