diff --git a/.gitignore b/.gitignore
new file mode 100644
index 0000000..d6b130c
--- /dev/null
+++ b/.gitignore
@@ -0,0 +1 @@
+.claude/settings.local.json
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
new file mode 100644
index 0000000..0c1e7a1
--- /dev/null
+++ b/CONTRIBUTING.md
@@ -0,0 +1,62 @@
+# Contributing
+
+## How to Participate
+
+This Interest 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 in this 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 | Long-form technical proposals, experimental findings | Weekly triage |
+| This repository | Living reference for approaches, findings, and decisions | Updated after meetings |
+
+## Meetings
+
+*To be scheduled* — likely biweekly working sessions once the group establishes momentum.
+
+Meeting norms:
+
+- Agendas published 24 hours in advance
+- Notes published within 48 hours
+
+## Decision-Making
+
+As an Interest Group, we operate by **rough consensus** — we're exploring and recommending, not deciding. Outputs include:
+
+- Documented requirements and use cases
+- Evaluated approaches with findings
+- Recommendations to relevant WGs or as SEP proposals
+
+## 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
+
+### Filing Issues
+
+Use GitHub Issues for:
+
+- Proposing new approaches or use cases
+- Reporting gaps in documentation
+- Tracking action items from meetings
diff --git a/README.md b/README.md
index d8993b4..ca30541 100644
--- a/README.md
+++ b/README.md
@@ -1,10 +1,25 @@
 # Skills Over MCP Interest Group
 
-> ⚠️ **Experimental** — This repository is an incubation space for the [Skills Over MCP Interest Group](https://docs.google.com/document/d/1j-AGRcvLkYiiIJ9asmmF1mLLjjUiova7a9BgkSXtD4s/edit?usp=sharing). Contents are exploratory and do not represent official MCP specifications or recommendations.
+> ⚠️ **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.
 
 ## Mission
 
-This Interest Group explores how "[agent skills](https://agentskills.io/)" (rich, structured instructions for agent workflows) can be discovered and consumed through MCP. Native skills support in host applications demonstrates strong demand, but the community hasn't aligned on whether existing MCP primitives suffice or what conventions to standardize.
+This Interest Group explores how "[agent skills](https://agentskills.io/)" (rich, structured instructions for agent workflows) can be discovered and consumed through MCP. Native skills support in host applications demonstrates strong demand, but the community hasn't aligned on whether existing MCP primitives suffice or what conventions to standardize. Cross-cutting collaboration is needed because solutions touch the protocol spec, registry schema, SDK implementations, and client behavior.
+
+## Scope
+
+### In Scope
+
+- **Requirements gathering:** Documenting use cases, constraints, and gaps in current MCP primitives for skill distribution
+- **Pattern exploration:** Testing and evaluating approaches (skills as tools, resources, registry metadata, protocol primitives)
+- **Coordination:** Bridging discussions across Registry WG, Agents WG, and external stakeholders (Agent Skills spec owners, FastMCP, PydanticAI)
+- **Proof of concepts:** Maintaining a shared repo of reference implementations and experimental findings
+
+### Out of Scope
+
+- **Approving spec changes:** This IG does not have authority to approve protocol changes; recommendations flow through the SEP process
+- **Registry schema decisions:** Coordinate with Registry WG; this IG explores requirements but doesn't own the schema
+- **Client implementation mandates:** We can document patterns but not require specific client behavior
 
 ## Problem Statement
 
@@ -15,7 +30,70 @@ Native "skills" support in host applications demonstrates demand for rich workfl
 - **No discovery mechanism** — users installing MCP servers don't know if there's a corresponding skill they should also install
 - **Multi-server orchestration** — skills may need to coordinate tools from multiple servers
 
-## Status
+See [problem-statement.md](problem-statement.md) for full details.
+
+## Repository Contents
+
+| Document | Description |
+| :--- | :--- |
+| [Problem Statement](problem-statement.md) | Current limitations and gaps |
+| [Use Cases](use-cases.md) | Key use cases driving this work |
+| [Approaches](approaches.md) | Approaches being explored (not mutually exclusive) |
+| [Open Questions](open-questions.md) | Unresolved questions with community input |
+| [Experimental Findings](experimental-findings.md) | Results from implementations and testing |
+| [Related Work](related-work.md) | SEPs, implementations, and external resources |
+| [Contributing](CONTRIBUTING.md) | How to participate |
+
+## Stakeholder Groups
+
+| Group | Overlap |
+| :--- | :--- |
+| Agents WG | How agents consume server metadata, skill activation |
+| Registry WG | Skills discovery/distribution, registry schema changes |
+| Primitive Grouping WG | Progressive disclosure patterns |
+
+## Facilitators
+
+| Role | Name | Organization | GitHub |
+| :--- | :--- | :--- | :--- |
+| Maintainer | Ola Hungerford | Nordstrom / MCP Maintainer | [@olaservo](https://github.com/olaservo) |
+| Facilitator | Bob Dickinson | TeamSpark.ai | [@TeamSparkAI](https://github.com/TeamSparkAI) |
+| Facilitator | Rado | Stacklok / MCP Maintainer | |
+| Facilitator | Yu Yi | Google | [@erain](https://github.com/erain) |
+| Facilitator | Ozz | Stacklok | [@JAORMX](https://github.com/JAORMX) |
+| Facilitator | Kaxil Naik | Astronomer / Apache Airflow PMC | [@kaxil](https://github.com/kaxil) |
+
+## Lifecycle
+
+**Current Status: Active Exploration**
+
+### Graduation Criteria (IG → WG)
+
+This IG may propose becoming a Working Group if:
+
+- Clear consensus emerges on an approach requiring sustained spec work
+- Cross-cutting coordination requires formal authority delegation
+- At least two Core Maintainers sponsor WG formation
+
+### Retirement Criteria
+
+- Problem space resolved (conventions established, absorbed into other WGs)
+- Insufficient participation to maintain momentum
+- Community consensus that skills don't belong in MCP protocol scope
+
+## Work Tracking
+
+| Item | Status | Champion | Notes |
+| :--- | :--- | :--- | :--- |
+| Requirements alignment | In Progress | All facilitators | Review approaches, identify common requirements and gaps |
+| Agent Skills spec coordination | Not Started | TBD | Establish communication with agentskills.io maintainers |
+| Experimental findings repo | Proposed | Ola | Dedicated repo for implementations and evaluation results |
+| SEP-2076 review | In Progress | Yu Yi | Skills as first-class primitive proposal |
+| Registry skills.json proposal | In Progress | Ozz | Skills metadata in registry schema |
+| MCP Skills Convention v0.1 | Proposed | TBD | Documented pattern (not spec) for skills over existing primitives |
+
+## Success Criteria
 
-- This repository is WIP and will ultimately replace [this public Google Document](https://docs.google.com/document/d/1j-AGRcvLkYiiIJ9asmmF1mLLjjUiova7a9BgkSXtD4s/edit?usp=sharing).
-- Until this note is removed, please continue to use the above document and the [#skills-over-mcp-ig Discord channel](https://discord.com/channels/1358869848138059966/1464745826629976084) for ongoing discussion.
+- **Short-term:** Documented consensus on requirements and evaluation of existing approaches
+- **Medium-term:** Clear recommendation (convention vs. protocol extension vs. both)
+- **Long-term:** Interoperable skill distribution across MCP servers and clients
diff --git a/docs/approaches.md b/docs/approaches.md
new file mode 100644
index 0000000..4acea04
--- /dev/null
+++ b/docs/approaches.md
@@ -0,0 +1,111 @@
+# Approaches Being Explored
+
+> These are not mutually exclusive solutions.
+
+## Design Principles
+
+Whatever approach is adopted, community members have highlighted several principles:
+
+> "There should be intentional focus on making it easy for server authors to create and expose skills... client hosts are strongly incentivized to have a relatively uniform way to discover and consume them — at least from the point of view of a server author — while also leaving room for client host innovation." — [Peder Holdgaard Pedersen](https://github.com/PederHP)
+
+## 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.
+
+## 1. Skills as 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.
+
+**Proposal:** [SEP-2076](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2076)
+
+**Author:** [Yu Yi](https://github.com/erain)
+
+**Key elements:**
+
+- New protocol methods: `skills/list` and `skills/get`
+- A `skills` server capability
+- A `notifications/skills/list_changed` notification
+- Progressive disclosure: clients load skill summaries at startup, fetch full instructions on demand
+- Mapping to existing SKILL.md format
+
+**Status:** Draft, seeking sponsor.
+
+**Community input:**
+
+> "My main motivation is: we have so many MCP servers already available, how can we leverage them to distribute Skills?" — [Yu Yi](https://github.com/erain)
+
+## 2. Skills as Registry Metadata
+
+Add skill references to MCP registry entries so users know to install associated skills alongside servers.
+
+**Implementations:** 
+- [Ozz](https://github.com/JAORMX) started a discussion around [skills.json format proposal](https://github.com/modelcontextprotocol/registry/discussions/895)
+- NimbleBrain has implemented this via a `skill` field in registry `_meta`, supporting `.skill` artifact bundles (ZIP containing SKILL.md + manifest.json).
+    - https://github.com/NimbleBrainInc/skills
+    - [registry.nimbletools.ai](https://registry.nimbletools.ai/)
+
+**Community input:**
+
+> "We view skills as an opportunity to use them as both a standalone (general-purpose capabilities) & MCP-paired (tool-specific guidance). For the main registry, the binding could be softer: optional fields like suggestedSkills or recommendedSkills rather than definitive pairing, since skill authorship is often decoupled from server authorship." — [Mat Goldsborough](https://github.com/mgoldsborough)
+
+## 3. Skills as Tools
+
+Expose skills via tools like `list_skills` and `read_skills`. Server instructions can direct the agent to call the skill tool first.
+
+**Implementations:** 
+
+- [skilljack-mcp](https://github.com/olaservo/skilljack-mcp)
+- [skills-over-mcp](https://github.com/keithagroves/skills-over-mcp)
+
+**Community input:**
+
+> "I wonder if a better way to approach this with existing primitives is by implementing a Skill() tool and establishing this as a standard recommendation for servers and clients, rather than adding a new primitive to MCP." — [Ola Hungerford](https://github.com/olaservo)
+
+This approach may also:
+
+- Expose skills as MCP resources
+- Use Prompts for explicit skill invocation
+- Use `tools/listChanged` and other notifications for dynamic updates without server re-initialization
+
+### Variant: Skills via Sampling
+
+Instead of exposing skill tools to the main agent, use MCP's Sampling with Tools capability ([SEP-1577](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/1577)). The server requests a sampling call with skill-specific tools (`read_skill_md`, `execute_script`, etc.) that are only visible during that sampling request. This keeps skill tools hidden from the main agent, addressing tool bloat. The server orchestrates skill execution; the main agent just sees the result.
+
+**Caveat:** Sampling has limited client support currently.
+
+**Source:** [jbnitorum](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2076#issuecomment-3806151745)
+
+## 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.
+
+This pattern could enable loading primitives (tools) without the full "server" boundary.
+
+**Community input:**
+
+> "MCP repos can also be used as libraries... a gateway in same language as bundle servers could also load primitives like tools, and not necessarily need or want the 'server' parts." [SamMorrowDrums](https://github.com/SamMorrowDrums)
+
+## 5. Server Instructions Reference
+
+Use server instructions as a pointer to a resource: "If you need to do X, fetch resource Y for further instructions." This defers loading skill content until needed, managing context more efficiently.
+
+**Limitation:** May not work with off-the-shelf servers where you can't modify their instructions.
+
+## 6. Official Convention as Intermediate Step
+
+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`)
+- Recommend metadata structure (version, tags, dependencies) aligned with agentskills.io
+- Provide guidance on control model: resources for application-controlled, `skill()` tool for model-controlled
+- 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."
+
+**Advantages of the convention approach:**
+
+- Since MCP supports dynamically updating tools, the latest skills manifest can be included in tool descriptions
+- Skills can also be modeled as Resources (using `skill://` URI) for application-controlled access
+- Prompts could support explicit skill invocation
+- The convention and protocol extension approaches are not mutually exclusive — convention can prove patterns before standardization
diff --git a/docs/experimental-findings.md b/docs/experimental-findings.md
new file mode 100644
index 0000000..d20297c
--- /dev/null
+++ b/docs/experimental-findings.md
@@ -0,0 +1,63 @@
+# Experimental Findings
+
+## McpGraph: Skills in MCP Server Repo
+
+**Repo:** [TeamSparkAI/mcpGraph](https://github.com/TeamSparkAI/mcpGraph)
+**Skill:** [mcpgraphtoolkit/SKILL.md](https://github.com/TeamSparkAI/mcpGraph/blob/main/skills/mcpgraphtoolkit/SKILL.md) (875+ lines)
+
+Bob Dickinson built a standalone SKILL.md file that lives in the same repo as the MCP server, but they weren't formally connected. The skill instructs agents on building directed graphs of MCP nodes to orchestrate tool calls.
+
+**Findings:**
+
+- Claude ignored the SKILL.md initially, even when the skill and server had similar descriptions
+- Claude would fail at using the server tools a couple times, then read the skill and succeed
+- Expected Claude to start with the skill ("I know how to do X") before the server ("I do X"), but it didn't
+
+**Resolution:** Added a server instruction telling the agent to read the SKILL.md before using the tool. That one change caused Claude to reliably read the skill first.
+
+**Remaining concerns:**
+
+- This workaround works for 1:1 skill-to-server case, but doesn't solve discovery — users installing from a registry don't know to also install the skill
+- Distinguishes between "skill required to make the server work at all" vs. "skill that orchestrates tools you could use without it" — potentially different solutions needed
+
+## Skilljack MCP
+
+**Repo:** [olaservo/skilljack-mcp](https://github.com/olaservo/skilljack-mcp)
+
+Loads skills into tool descriptions. Uses dynamic tool updates to keep the skills manifest current.
+
+## worfcat's Three-Way Comparison
+
+Tested skills exposed in three ways across multiple clients:
+
+### 1. Skills as MCP Resources (with a simple `validate_skill` tool)
+
+**Result: Bad.** The model never used them or looked at them unless explicitly asked.
+
+### 2. Skills as Tools in an MCP Server (`list_skills` and `read_skills`)
+
+**Result: Mixed.** Needed some tool description tuning to get used. More brittle than native. Worked with Claude Code, OpenAI agent builder, and a few other clients.
+
+### 3. Native Skills (installing in `skills/` folder of Claude Code)
+
+**Result: Best.** Easiest, worked out of the box.
+
+**Key insight:**
+
+> "There is a many-many relationship between skills and tools. A skill should not require pieces of instruction like 'here's how you use this single tool'. If an instruction of how to use an MCP server is copied across skills, it should live at the server level. Context decomposition basically."
+
+**Note:** Claude Code's skill implementation is just a tool call — `Skill(<n>)` returns the SKILL.md file. Nothing fancy (at least for now).
+
+## FastMCP 3.0 Skills Support
+
+**URL:** [gofastmcp.com/servers/providers/skills](https://gofastmcp.com/servers/providers/skills)
+
+FastMCP added skills support in version 3.0. Worth examining for alignment with other approaches.
+
+**Related:** [jlowin/fastmcp#2694](https://github.com/jlowin/fastmcp/issues/2694)
+
+## PydanticAI Skills Support
+
+**PR:** [pydantic/pydantic-ai#3780](https://github.com/pydantic/pydantic-ai/pull/3780)
+
+Introduces support for agent skills with a tools-based approach.
diff --git a/docs/open-questions.md b/docs/open-questions.md
new file mode 100644
index 0000000..6eb05b4
--- /dev/null
+++ b/docs/open-questions.md
@@ -0,0 +1,101 @@
+# Open Questions
+
+## 1. Is this a registry problem or an MCP server problem?
+
+Should skills be discoverable through registry metadata ("if you install this server, also install this skill") or contained within the MCP server itself?
+
+## 2. How do "first-class" skills differ from "skills as context"?
+
+Native agent skills can be presented through the user agent, bundled with subagents, etc. Do MCP-surfaced skills lose capabilities compared to directly installed skills?
+
+**Community input:**
+
+> "The only slight concern I have is the idea that there are still 'first class skills' (skills that agents recognize as skills, can be presented as skills through the user agent, can be bundled with subagents, etc) and these sort of 'skills as context' approaches where the agent can certainly discover and ingest the skills data, but possibly with some differences compared to how they would apply first class skills." — [Bob Dickinson](https://github.com/TeamSparkAI)
+
+> "I don't like creating dichotomy between first-class skills and skills as context, because pretty much everything an MCP server exposes is context. Skills-as-resources is much more accurate." — [Peder Holdgaard Pedersen](https://github.com/PederHP)
+
+## 3. Should server.instructions be extended for richer content?
+
+Or is the separation between "primitive server" and "skill that uses the primitive" the right abstraction?
+
+**Community input:**
+
+> "I would caution against seeing skills as too tightly coupled with tools. Not all skills need to be related to the tools on a server — or even client-side tool use at all. This is especially true for agents that use very broad tools or heavily reliant on code interpreter and similar meta-tools." — [Peder Holdgaard Pedersen](https://github.com/PederHP)
+
+## 4. How should skills relate to multiple servers?
+
+A skill orchestrating tools from several servers can't live in any single server's instructions.
+
+## 5. Do clients actually leverage skills when presented via MCP?
+
+Early experiments suggest they do, but more rigorous testing is needed.
+
+**Community input:**
+
+> "Clients have been slow to implement support for resources. Had some parallel primitive 'skills' been implemented, I'm not sure clients would have implemented them any faster. Basically they all went for 'tools' and have slowly been getting around to implementing other primitives." — [Cliff Hall](https://github.com/cliffhall)
+
+## 6. How do we coordinate with agent skills spec owners?
+
+The contribution model for the skills spec isn't clear, and MCP-related efforts should be brought to their attention.
+
+- [Ola Hungerford](https://github.com/olaservo)
+
+## 7. What would MCP have had to get right for skills to have been shipped over MCP from the beginning?
+
+— [Keith Groves](https://github.com/keithagroves)
+
+## 8. What could MCP reasonably change so that it will be the obvious choice for new formats?
+
+— [Keith Groves](https://github.com/keithagroves)
+
+**Community input:**
+
+> "It's worth noting that skills aren't the only standard, there's also Kiro Powers and inevitably others will emerge that may or may not get traction. Will clients have to keep making custom integrations for new formats?" — [Keith Groves](https://github.com/keithagroves)
+
+## 9. Who gets visibility into skill content, and who decides when it gets loaded?
+
+The control model question — model-controlled vs. application-controlled.
+
+— [Ola Hungerford](https://github.com/olaservo)
+
+**Community input:**
+
+> "One big advantage of skills over resources is that they are intended to be model-controlled by default. The people I've talked to about using MCP Resources in their servers have seen the 'application controlled' part as reducing their practical use... the bigger question for 'skills over MCP' is about the control model: who gets visibility into this content, and who decides when it gets loaded?" — [Ola Hungerford](https://github.com/olaservo)
+
+## 10. How should skills handle security and trust boundaries?
+
+If skills can be abused for prompt injection, what mitigations should be spec'd? (provenance, gating, explicit policy)
+
+— [Prince Roshan](https://github.com/Agent-Hellboy)
+
+**Community input:**
+
+> "If a user registers an MCP server, they are already extending their trust boundary. A malicious server can do far worse via tools than via a 'skill' document." — [sebthom](https://github.com/modelcontextprotocol/modelcontextprotocol/issues/2167#issuecomment-3824771018)
+
+Proposed mitigations: skills are untrusted docs not directives; clients MUST NOT auto-apply without explicit policy; skills should be presented with provenance and be optionally gated.
+
+## 11. Should the control model be use-case specific?
+
+Perhaps resources (application-controlled) for some use cases, tools (model-controlled) for others? Can a convention support both?
+
+Note: Some apps like Claude Code have started to indicate in the skill frontmatter whether a particular skill should be model-controlled-only, human-controlled-only, or either — and has also started to blur the lines between slash commands and skills.
+
+## 12. Why not just 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)
+
+**Community input:**
+
+> "I'd like Skills to be 'more official' than generic resources — which could be ANYTHING. More specifically, skill as a separate spec may advance in the near future, e.g. versioning etc., so having MCP as an official distribution mechanism and support it in the current and future form is important." — [Yu Yi](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2076#discussion_r2747846895)
+
+> "If the conclusion is 'just use resources', I am fine with that direction too — but then we should standardize a way to identify and list workflow resources as 'skills' so clients can reliably surface them (otherwise we are back to out-of-band conventions)." — [sebthom](https://github.com/modelcontextprotocol/modelcontextprotocol/issues/2167#issuecomment-3824771018)
+
+## 13. What is the optimal relationship between skills and MCP?
+
+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:**
+
+> "Skills are simple files that agents can load directly even if they don't have any MCP servers connected. Adding MCP to the process only for that would be over complicating something that already works well... the question becomes 'what is the optimal relationship between skills and MCP?'" — [Cliff Hall](https://github.com/cliffhall)
diff --git a/docs/problem-statement.md b/docs/problem-statement.md
new file mode 100644
index 0000000..a751f5b
--- /dev/null
+++ b/docs/problem-statement.md
@@ -0,0 +1,23 @@
+# Problem Statement
+
+[Agent Skills](https://agentskills.io/home) support in AI applications demonstrates demand for rich workflow instructions, but there's no convention for exposing equivalent functionality through MCP primitives.
+
+## Current Limitations
+
+- **Server instructions load only at initialization** — new or updated skills require re-initializing the server
+- **Complex workflows exceed practical instruction size** — some skills require hundreds of lines of markdown with references to bundled files, scripts, and examples
+- **No discovery mechanism** — users installing MCP servers from a registry don't know if there's a corresponding skill they should also install
+- **Multi-server orchestration** — skills may need to coordinate tools from multiple servers, which doesn't fit the single-server instruction model
+
+## Key Use Cases
+
+See [use-cases.md](use-cases.md) for detailed use cases and community input. In summary:
+
+1. **Complex Workflow Orchestration** — Multi-step workflows requiring 875+ lines of instruction (e.g., [mcpGraph](https://github.com/TeamSparkAI/mcpGraph))
+2. **Conditional Workflows** — Branching instructions dynamically loaded based on context
+3. **Multi-Server Composition** — Skills leveraging tools from multiple off-the-shelf servers
+4. **Progressive Disclosure** — Skills broken into linked file sets, loaded on demand
+
+## Open Questions
+
+See [open-questions.md](open-questions.md) for the full list of unresolved questions with community input.
diff --git a/docs/related-work.md b/docs/related-work.md
new file mode 100644
index 0000000..c96cf6d
--- /dev/null
+++ b/docs/related-work.md
@@ -0,0 +1,33 @@
+# Related Work
+
+## Open SEPs and Proposals
+
+| Proposal | Venue | Description |
+| :--- | :--- | :--- |
+| [SEP-2076](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2076) | MCP Spec | Agent Skills as a first-class MCP primitive |
+| [skills.json format proposal](https://github.com/modelcontextprotocol/registry/discussions/895) | MCP Registry | Skills metadata in registry schema |
+
+## Implementations
+
+| Implementation | Author | URL | Notes |
+| :--- | :--- | :--- | :--- |
+| skilljack-mcp | Ola Hungerford | [github.com/olaservo/skilljack-mcp](https://github.com/olaservo/skilljack-mcp) | Skills as tools with dynamic updates |
+| mcpGraph skill | Bob Dickinson | [github.com/TeamSparkAI/mcpGraph](https://github.com/TeamSparkAI/mcpGraph) | 875+ line skill for graph orchestration |
+| skills-over-mcp | Keith Groves | [github.com/keithagroves/skills-over-mcp](https://github.com/keithagroves/skills-over-mcp) | Example using skills with current MCP primitives |
+| chrome-devtools-mcp | Anthropic | [github.com/anthropics/anthropic-quickstarts/…/chrome-devtools-mcp](https://github.com/anthropics/anthropic-quickstarts/tree/main/mcp-servers/chrome-devtools-mcp) | Real-world example: `skills/` folder requires separate install path |
+| NimbleBrain skills repo | NimbleBrain | [github.com/NimbleBrainInc/skills](https://github.com/NimbleBrainInc/skills) | Monorepo with `.skill` artifact format |
+| NimbleBrain registry | NimbleBrain | [registry.nimbletools.ai](https://registry.nimbletools.ai/) | Registry with skill metadata support |
+| FastMCP 3.0 Skills | FastMCP | [gofastmcp.com/servers/providers/skills](https://gofastmcp.com/servers/providers/skills) | Native skills provider ([#2694](https://github.com/jlowin/fastmcp/issues/2694)) |
+| PydanticAI Skills | PydanticAI | [pydantic/pydantic-ai#3780](https://github.com/pydantic/pydantic-ai/pull/3780) | Agent skills with tools-based approach |
+| mcp-cli | philschmid | [github.com/philschmid/mcp-cli](https://github.com/philschmid/mcp-cli) | Wraps MCP servers as CLI for progressive disclosure |
+| mcp-execution | bug-ops | [github.com/bug-ops/mcp-execution](https://github.com/bug-ops/mcp-execution) | Compiles MCP servers into skill packages |
+| Astronomer agents | Kaxil Naik | [github.com/astronomer/agents](https://github.com/astronomer/agents) | Skills distribution via MCP for Apache Airflow |
+
+## External Resources
+
+- **Agent Skills Standard:** [agentskills.io](https://agentskills.io/)
+- **Anthropic's guidance on progressive disclosure:** [Equipping agents for the real world with agent skills](https://www.anthropic.com/engineering/equipping-agents-for-the-real-world-with-agent-skills)
+- **"MCP and Skills: Why Not Both?"** (Kurtis Van Gent): [kvg.dev/posts/20260125-skills-and-mcp/](https://kvg.dev/posts/20260125-skills-and-mcp/) — Frames MCP (connectivity) and Skills (context saturation) as complementary; discusses hybrid approaches
+- **Conceptual spec visualization** (Keith Groves): [enact-465fb1fc.mintlify.app/specification/draft/server/skills](https://enact-465fb1fc.mintlify.app/specification/draft/server/skills) — "What if" exploration
+- **Apache Airflow AIP-91** (MCP integration): [cwiki.apache.org/…/AIP-91+-+MCP](https://cwiki.apache.org/confluence/display/AIRFLOW/AIP-91+-+MCP)
+- **Video background:** [youtube.com/watch?v=CEvIs9y1uog](https://www.youtube.com/watch?v=CEvIs9y1uog)
diff --git a/docs/use-cases.md b/docs/use-cases.md
new file mode 100644
index 0000000..8e82776
--- /dev/null
+++ b/docs/use-cases.md
@@ -0,0 +1,65 @@
+# Use Cases
+
+## 1. Complex Workflow Orchestration
+
+Skills that teach agents how to perform multi-step workflows that they wouldn't know how to execute from tool descriptions alone.
+
+**Example:** Bob Dickinson's [mcpGraph](https://github.com/TeamSparkAI/mcpGraph) toolkit requires a [skill file of 875+ lines](https://github.com/TeamSparkAI/mcpGraph/blob/main/skills/mcpgraphtoolkit/SKILL.md) to instruct agents on building directed graphs of MCP nodes. This orchestration logic is "way more than you'd want to put in instructions."
+
+**Community input:**
+
+> "Skills may define how to use tools, possibly from different servers, to accomplish complex workflows requiring contextual reasoning that could not be coded with MCP tools." — [Daniele Martinoli](https://github.com/dmartinol)
+
+## 2. Conditional Workflows
+
+Workflows that reference tools conditionally based on context, requiring rich structured instructions that can be dynamically loaded.
+
+**Example:** A skill that guides an agent through different branches of a debugging workflow depending on the type of error encountered, loading relevant sub-instructions only when needed.
+
+## 3. Multi-Server Composition
+
+Skills that leverage tools from multiple off-the-shelf servers where you can't (or don't want to) modify their individual instructions.
+
+**Community input:**
+
+> "I think there might also be a subtle difference between the kind of skill that allows you to orchestrate a set of tools, possibly from different servers, to do something the agent wouldn't have necessarily known how to do without the skill (more of a skill registry issue), and the 'you're pretty much going to need this skill to make use of this server at all' (an MCP server registry issue, maybe)." — [Bob Dickinson](https://github.com/TeamSparkAI)
+
+> "The ecosystem has been too focused on the server being the main deliverable in some ways, and actually there's a lot that can be done in terms of composition that we miss by people generally imagining their code as being the server boundary and not providing functionality more as a library." — [Sam Morrow](https://github.com/SamMorrowDrums)
+
+## 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.
+
+**Community input:**
+
+> "Especially mimicking progressive disclosure via resources and dynamically adding new ones as the agent reads pieces of the skill has been quite handy!" — [Ozz / Juan Antonio Osorio](https://github.com/JAORMX)
+
+**Related:** [Anthropic's guidance on progressive disclosure](https://www.anthropic.com/engineering/equipping-agents-for-the-real-world-with-agent-skills)
+
+## 5. Server-Skill Pairing
+
+Servers that are difficult or impossible to use effectively without an accompanying skill.
+
+**Community input:**
+
+> "Clients of the registry presumably understand MCP, but there is no guarantee that they understand skills. So if it is going to be hard for an agent to use the server without the 'skill' then doesn't it make sense for the MCP server to contain all the instructions necessary to use it?" — [Cliff Hall](https://github.com/cliffhall)
+
+**Example:** [chrome-devtools-mcp](https://github.com/anthropics/anthropic-quickstarts/tree/main/mcp-servers/chrome-devtools-mcp) ships with a skills/ folder that requires a separate install path from the MCP server itself.
+
+## 6. Skill Versioning and Updates
+
+Skills that evolve over time and need version-aware distribution.
+
+**Community input:**
+
+> "I'd like for skills over MCP to enable the client to make use of the version attribute... If a skill stored locally has an older version than the skill seen on the MCP server, the client can download the latest skill on the spot." — [woweow](https://github.com/woweow)
+
+## 7. Enterprise Integration
+
+Organizations building official MCP servers for established platforms are looking to skills as a distribution mechanism for domain-specific workflow guidance.
+
+**Community input:**
+
+> "As part of Apache Airflow community, we are planning to build our official MCP Server... and I am specifically interested in integrating Skills as part of the MCP protocol." — [Kaxil Naik](https://github.com/kaxil)
+
+**Related:** [Apache Airflow AIP-91 (MCP integration)](https://cwiki.apache.org/confluence/display/AIRFLOW/AIP-91+-+MCP)