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/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.