MCP Prompts are meant to be user triggered, whereas I believe a Skill is meant to be an LLM-triggered, use-case centric set of instructions for a specific task.

  - MCP Prompt: "Please solve GitHub Issue #{issue_id}"
  - Skills:
    - React Component Development (React best practices, accessible tools)
    - REST API Endpoint Development
    - Code Review

This will probably result in:

  - Single "CLAUDE.md" instructions are broken out into discoverable instructions that the LLM will dynamically utilize based on the user's prompt
  - rather than having direct access to Tools, Claude will always need to go through Skill instructions first (making context tighter since it cant use Tools without understanding \*how\* to use them to achieve a certain goal)
  - Clients will be able to add infinite MCP servers / tools, since the Tools themselves will no longer all be added to the context window

It's basically a way to decouple User prompts from direct raw Tool access, which actually makes a ton of sense when you think of it.

I see this as a lower overhead replacement for MCP. Rather than managing a bunch of MCP's, use the directory structure to your advantage, leverage the OS's capability to execute

For me the concept of MCP was to have a client/server relation. For skills everything will be local.

I think you are right.

Yeah how is this different from MCP prompts?

Narrowly focused semantics/affordances (for both LLM and users/future package managers/communities, ease of redistribution and context management:

- skills are plain files that are injected contextually whereas prompts would come w the overhead of live, running code that has to be installed just right into your particular env, to provide a whole mcp server. Tbh prompts also seem to be more about literal prompting, too

- you could have a thousand skills folders for different softwares etc but good luck with having more than a few mcp servers that are loaded into context w/o it clobbering the context