* 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>
4.6 KiB
Contributing
How to Participate
This Working Group welcomes contributions from anyone interested in skills distribution over MCP. You can participate by:
- Joining discussions in the #skills-over-mcp-wg Discord channel (info on joining the Discord server here)
- Opening or commenting on GitHub Discussions 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-wg | Quick questions, coordination, async discussion | Best effort |
| GitHub Discussions | 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 is maintained in the 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 in that repository.
Before opening a discussion, review the Agent Skills contributing guide.
Meetings
Working Session cadence is defined in the charter; the schedule is published on meet.modelcontextprotocol.io. Meeting requirements — advance notice, agendas, and notes — follow MCP group governance.
Notes are published to Meeting Notes — Skills Over MCP WG. Scheduling surveys and between-meeting coordination happen in #skills-over-mcp-wg.
Decision-Making
Scope and per-decision-type authority are defined in the charter. The decision progression (lazy consensus → formal vote → escalation) follows MCP group governance.
Outputs include:
- 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
Documenting Approaches and Findings
When adding experimental findings or new approaches:
- Include enough detail for others to reproduce or evaluate
- Note which clients and servers were tested
- Be explicit about what worked, what didn't, and what remains untested
- Attribute community input with GitHub handles and link to the source where possible
Community Input
When adding quotes or input from community discussions:
- Attribute to the contributor by name and GitHub handle
- Link to the original source (Discord thread, GitHub comment, etc.) where possible
- Present input as blockquotes to distinguish it from editorial content
Decision Log
Significant decisions made during meetings or through async discussion should be recorded in docs/decisions.md using the ADR-lite format defined there. A decision is worth logging when it:
- Chooses one approach over alternatives
- 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 consensus is reached asynchronously. Include context, the decision itself, rationale, and links to relevant issues, PRs, or discussion threads.
Filing Issues
Use GitHub Issues for:
- Proposing new approaches or use cases
- Reporting gaps in documentation
- Tracking action items from meetings