[vidarh]

Skills are less exciting because they're effectively documentation that's selectively loaded.

They are a bigger deal in a sense because they remove the need for all the scaffolding MCPs require.

E.g. I needed Claude to work on transcripts from my Fathom account, so I just had it write a CLI script to download them, and then I had it write a SKILL.md, and didn't have to care about wrapping it up into an MCP.

At a client, I needed a way to test their APIs, so I just told Claude Code to pull out the client code from one of their projects and turn it into a CLI, and then write a SKILL.md. And again, no need to care about wrapping it up into an MCP.

But this seems a lot less remarkable, and there's a lot less room to build big complicated projects and tooling around it, and so, sure, people will talk about it less.

[stingraycharles]

Skills are good for context management as everything that happens while executing the skill remains “invisible” to the parent context, but they do inherit the parent context. So it’s pretty effective for a certain set of problems.

MCP is completely different, I don’t understand why people keep comparing the two. A skill cannot connect to your Slack server.

Skills are more similar to sub-agents, the main difference being context inheritance. Sub-agents enable you to set a different system prompt for those which is super useful.

[ako]

Are you sure, i thought skill were loaded into the main context, unlike (sub)agents. According to Claude they're loaded into the main context. Do you have link?

[stingraycharles]

No, just their header / when they should be invoked, the actual contents of the skill is never loaded in the main context.

[ako]

Unless claude decides a skill is needed, then it loads the additional details into the main context to use. It's basically lazy loading into main context.

[vidarh]

A skill can absolutely connect to your slack server. Either by describing how to use standard tools to do so, or by including code.

Most of my skills connect to APIs.