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>

Author: olaservo

.github/CODEOWNERS

@@ -7,6 +7,6 @@
 # Team mappings are configured in the access repository:
 # https://github.com/modelcontextprotocol/access
 
-# Default owners for all files in the repository
-# The Skills Over MCP Interest Group has day-to-day governance
+# Default owners for all files — reviews route to the Skills Over MCP Working Group.
+# TODO: rename team to skills-over-mcp-wg once modelcontextprotocol/access updates (roleIds.ts, roles.ts, users.ts)
 * @modelcontextprotocol/skills-over-mcp-ig

CONTRIBUTING.md

@@ -2,43 +2,42 @@
 
 ## How to Participate
 
-This Interest Group welcomes contributions from anyone interested in skills distribution over MCP. You can participate by:
+This Working Group welcomes contributions from anyone interested in skills distribution over MCP. You can participate by:
 
-- Joining discussions in the [#skills-over-mcp-ig Discord channel](https://discord.com/channels/1358869848138059966/1464745826629976084) (info on joining the Discord server [here](https://modelcontextprotocol.io/community/communication#discord))
-- Opening or commenting on [GitHub Discussions](https://github.com/modelcontextprotocol/modelcontextprotocol/discussions/categories/meeting-notes-skills-over-mcp-ig) in the main MCP repo
+- Joining discussions in the [#skills-over-mcp-wg Discord channel](https://discord.com/channels/1358869848138059966/1464745826629976084) (info on joining the Discord server [here](https://modelcontextprotocol.io/community/communication#discord))
+- Opening or commenting on [GitHub Discussions](https://github.com/modelcontextprotocol/modelcontextprotocol/discussions/categories/meeting-notes-skills-over-mcp-wg) in the main MCP repo
 - Sharing experimental findings from your own implementations
 - Contributing to documentation and pattern evaluation
 
 ## Communication Channels
 
 | Channel | Purpose | Response Expectation |
 | :--- | :--- | :--- |
-| [Discord #skills-over-mcp-ig](https://discord.com/channels/1358869848138059966/1464745826629976084) | Quick questions, coordination, async discussion | Best effort |
-| [GitHub Discussions](https://github.com/modelcontextprotocol/modelcontextprotocol/discussions/categories/meeting-notes-skills-over-mcp-ig) | Meeting notes, long-form technical proposals, experimental findings | Weekly triage |
+| [Discord #skills-over-mcp-wg](https://discord.com/channels/1358869848138059966/1464745826629976084) | Quick questions, coordination, async discussion | Best effort |
+| [GitHub Discussions](https://github.com/modelcontextprotocol/modelcontextprotocol/discussions/categories/meeting-notes-skills-over-mcp-wg) | Meeting notes, long-form technical proposals, experimental findings | Weekly triage |
 | This repository | Living reference for approaches, findings, and decisions | Updated after meetings |
 
 ## Coordination with the Agent Skills Spec
 
-The [Agent Skills spec](https://agentskills.io/) is maintained in the [agentskills/agentskills](https://github.com/agentskills/agentskills) repository. For topics that intersect with both this IG and the Agent Skills spec (e.g., protocol design questions, proposed extensions, or alignment on terminology), the recommended channel is [Discussions](https://github.com/agentskills/agentskills/discussions) in that repository.
+The [Agent Skills spec](https://agentskills.io/) is maintained in the [agentskills/agentskills](https://github.com/agentskills/agentskills) repository. For topics that intersect with both this WG and the Agent Skills spec (e.g., protocol design questions, proposed extensions, or alignment on terminology), the recommended channel is [Discussions](https://github.com/agentskills/agentskills/discussions) in that repository.
 
 Before opening a discussion, review the [Agent Skills contributing guide](https://github.com/agentskills/agentskills/blob/main/CONTRIBUTING.md).
 
 ## Meetings
 
-[Meeting notes](https://github.com/modelcontextprotocol/modelcontextprotocol/discussions/categories/meeting-notes-skills-over-mcp-ig) are published in the main MCP repo discussions. Future meetings will be scheduled and scheduling surveys posted in the [#skills-over-mcp-ig Discord channel](https://discord.com/channels/1358869848138059966/1464745826629976084).
+Working Session cadence is defined in the [charter](https://modelcontextprotocol.io/community/skills-over-mcp/charter#operations); the schedule is published on [meet.modelcontextprotocol.io](https://meet.modelcontextprotocol.io). Meeting requirements — advance notice, agendas, and notes — follow MCP [group governance](https://modelcontextprotocol.io/community/working-interest-groups#meeting-requirements).
 
-Meeting norms:
-
-- Agendas published 24 hours in advance
-- Notes published within 48 hours
+Notes are published to [Meeting Notes — Skills Over MCP WG](https://github.com/modelcontextprotocol/modelcontextprotocol/discussions/categories/meeting-notes-skills-over-mcp-wg). Scheduling surveys and between-meeting coordination happen in [#skills-over-mcp-wg](https://discord.com/channels/1358869848138059966/1464745826629976084).
 
 ## Decision-Making
 
-As an Interest Group, we operate by **rough consensus** — we're exploring and recommending, not deciding. Outputs include:
+Scope and per-decision-type authority are defined in the [charter](https://modelcontextprotocol.io/community/skills-over-mcp/charter#authority-decision-rights). The decision progression (lazy consensus → formal vote → escalation) follows MCP [group governance](https://modelcontextprotocol.io/community/working-interest-groups#decision-making-process).
+
+Outputs include:
 
-- Documented requirements and use cases
-- Evaluated approaches with findings
-- Recommendations to relevant WGs or as SEP proposals
+- SEPs we shepherd from proposal through review (Extensions Track and related protocol changes)
+- Reference implementations demonstrating skill discovery and consumption
+- Documented requirements, evaluated approaches, and experimental findings
 
 ## Contribution Guidelines
 
@@ -67,7 +66,7 @@ Significant decisions made during meetings or through async discussion should be
 - Sets or changes the group's scope
 - Establishes a convention or coordination mechanism
 
-Add a new entry after the meeting where the decision was made or when rough consensus is reached asynchronously. Include context, the decision itself, rationale, and links to relevant issues, PRs, or discussion threads.
+Add a new entry after the meeting where the decision was made or when consensus is reached asynchronously. Include context, the decision itself, rationale, and links to relevant issues, PRs, or discussion threads.
 
 ### Filing Issues
 

README.md

@@ -1,11 +1,11 @@
-# Skills Over MCP Interest Group
+# Skills Over MCP Working Group
 
-> ⚠️ **Experimental** — This repository is an incubation space for the Skills Over MCP Interest Group. Contents are exploratory and do not represent official MCP specifications or recommendations.
+> ⚠️ **Experimental** — This repository is an incubation space for the Skills Over MCP Working Group. Contents are exploratory and do not represent official MCP specifications or recommendations.
 
 **Charter:** [modelcontextprotocol.io/community/skills-over-mcp/charter](https://modelcontextprotocol.io/community/skills-over-mcp/charter) — mission, scope, membership, active work items, and success criteria.
-**Project board:** [Skills Over MCP IG](https://github.com/orgs/modelcontextprotocol/projects/38/views/1)
-**Meeting notes:** [Skills Over MCP IG discussions](https://github.com/modelcontextprotocol/modelcontextprotocol/discussions/categories/meeting-notes-skills-over-mcp-ig)
-**Discord:** [#skills-over-mcp-ig](https://discord.com/channels/1358869848138059966/1464745826629976084)
+**Project board:** [Skills Over MCP WG](https://github.com/orgs/modelcontextprotocol/projects/38/views/1)
+**Meeting notes:** [Skills Over MCP WG discussions](https://github.com/modelcontextprotocol/modelcontextprotocol/discussions/categories/meeting-notes-skills-over-mcp-wg)
+**Discord:** [#skills-over-mcp-wg](https://discord.com/channels/1358869848138059966/1464745826629976084)
 
 ## Why Skills Over MCP?
 

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.
 

docs/decisions.md

@@ -1,6 +1,6 @@
 # Decision Log
 
-This document records significant decisions made by the Skills Over MCP Interest Group, using an ADR-lite (Architecture Decision Record) format. It serves as a transparent, auditable trace of the group's reasoning over time.
+This document records significant decisions made by the Skills Over MCP Working Group, using an ADR-lite (Architecture Decision Record) format. It serves as a transparent, auditable trace of the group's reasoning over time.
 
 For background on the ADR format, see [adr.github.io](https://adr.github.io/).
 
@@ -117,3 +117,20 @@ For background on the ADR format, see [adr.github.io](https://adr.github.io/).
 - [Issue #55](https://github.com/modelcontextprotocol/experimental-ext-skills/issues/55)
 - [Discord discussion](https://discord.com/channels/1358869848138059966/1482008994062274610)
 - [Using `_meta` for Skill Resources](skill-meta-keys.md)
+
+---
+
+### 2026-04-16: Convert Skills Over MCP from Interest Group to Working Group
+
+**Status:** [Accepted by Core Maintainers](https://discord.com/channels/1358869848138059966/1464745826629976084/1494774410891231352)
+
+**Context:** The group formed as an Interest Group on 2026-02-01 to explore skills distribution over MCP. Over the following weeks the work moved beyond problem-framing into concrete deliverables including the Skills Extension SEP (Extensions Track). Per MCP [group governance](https://modelcontextprotocol.io/community/working-interest-groups), Interest Groups focus on "identifying problems worth solving" and produce non-binding recommendations, while Working Groups "collaborate on a SEP, a series of related SEPs, or an officially endorsed project" and make binding decisions. The group's output had crossed that boundary.
+
+**Decision:** Convert to a Working Group. The group retains its existing scope (skills discovery, distribution, and consumption through MCP) and charter location, now governed by WG rules: lazy consensus → formal vote → escalation, with WG Leads holding autonomous authority over meeting logistics, proposal prioritization, and in-scope SEP triage. Spec changes require WG consensus plus Core Maintainer approval.
+
+**Rationale:** The group was already doing WG work — shepherding SEPs, building reference implementations, and coordinating cross-WG concerns — without the matching authority structure. Aligning form with function lets the group own SEP decisions in its scope (rather than routing recommendations through other WGs), formalizes the two-Lead model already in practice, and makes responsibilities explicit under the governance doc.
+
+**References:**
+- [PR #2586](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2586) — charter conversion (merged 2026-04-16)
+- [Charter](https://modelcontextprotocol.io/community/skills-over-mcp/charter)
+- [Group governance](https://modelcontextprotocol.io/community/working-interest-groups)

docs/related-work.md

@@ -9,9 +9,9 @@
 | [PR #2527](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2527) | MCP Spec | Recommend clients expose resource read to models — prerequisite for the resources-based skills approach |
 | [skills.json format proposal](https://github.com/modelcontextprotocol/registry/discussions/895) | MCP Registry | Skills metadata in registry schema |
 
-## IG Member Implementations
+## Working Group Member Implementations
 
-Work by IG facilitators and active participants that directly implements the group's core patterns: SKILL.md with YAML frontmatter, `skill://` resource URIs, and progressive disclosure via MCP primitives.
+Work by WG leads and active participants that directly implements the group's core patterns: SKILL.md with YAML frontmatter, `skill://` resource URIs, and progressive disclosure via MCP primitives.
 
 | Implementation | Author | Organization | URL | Notes |
 | :--- | :--- | :--- | :--- | :--- |
@@ -21,7 +21,7 @@ Work by IG facilitators and active participants that directly implements the gro
 
 ## Alternative Approaches
 
-Work by IG members and MCP maintainers that explores skills over MCP through different technical approaches than the core SKILL.md / `skill://` pattern.
+Work by WG members and MCP maintainers that explores skills over MCP through different technical approaches than the core SKILL.md / `skill://` pattern.
 
 | Implementation | Author | Organization | URL | Notes |
 | :--- | :--- | :--- | :--- | :--- |

docs/why-and-when.md

@@ -6,7 +6,7 @@
 
 MCP servers give agents access to tools. But tools alone are insufficient for complex workflows — tool descriptions tell an agent *what* a tool does, not *how to orchestrate* multiple tools together to achieve a goal. Skills bridge this gap. They are the structured "how-to" knowledge that makes tools useful: multi-step workflows, conditional logic, domain-specific patterns, and orchestration instructions that can run to hundreds of lines.
 
-Skills are *context*, and MCP is a *context protocol*. This Interest Group isn't looking for problems to solve with the MCP hammer. The question is narrower and more practical: agents already connect to remote services over MCP to get tools — can they get the know-how to use those tools through the same channel?
+Skills are *context*, and MCP is a *context protocol*. This Working Group isn't looking for problems to solve with the MCP hammer. The question is narrower and more practical: agents already connect to remote services over MCP to get tools — can they get the know-how to use those tools through the same channel?
 
 The answer matters because skills and tools are often tightly coupled. A server that provides graph-building tools is hard to use without 875 lines of orchestration instructions. A server exposing Airflow APIs needs version-specific guidance to avoid suggesting deprecated patterns. One workaround is wrapping each MCP server in a custom sub-agent with hand-written instructions — but this means independently reinventing the same orchestration guidance for the same servers. Skills over MCP makes those instructions portable and shareable: the server author ships them once, and every user benefits. See [problem-statement.md](problem-statement.md) for the full gap analysis.