Live data from Hacker News

Claude Skills

anthropic.com

131–140 of 443 posts

Re: Claude Skills

#131

So skills are basically preset system prompts, assuming different roles etc? Or is there more to it. I'm a little confused.

Right, that's my interpretation as well.

"AI" companies have reached the end of the road when it comes to throwing more data and compute at the problem. The only way now for charts to go up and to the right is to deliver value-added services.

And, to be fair, there's a potentially long and profitable road by doing good engineering work that was needed anyways.

But it should be obvious to anyone within this bubble that this is not the road to "superintelligence" or "AGI". I hope that the hype and false advertising stops soon, so that we can focus on practical applications of this technology, which are numerous.

Re: Claude Skills

#132
post #97

Earlier quoted context omitted.

Why are you asking them to cite something for that statement? Are you questioning whether it's the foundation for intelligence or whether LLMS understand goals and consequences?

Yes, I'm questioning if that's the foundation of intelligence. Says who?

[deleted]

Re: Claude Skills

#133
Sub agents, mcp, skills - wonder how are they supposed to interact with each other?

Feels like fair bit of overlap here. It's ok to proceed in a direction where you are upgrading the spec and enabling claude wth additional capabilities. But one can pretty much use any of these approaches and end up with the same capability for an agent.

Right now feels like a ux upgrade from mcp where you need a json but instead can use a markdown in a file / folder and provide multi-modal inputs.

Re: Claude Skills

#134
post #17

I wonder how this works with mcpb (renamed from dxt Desktop extensions): https://github.com/anthropics/mcpb Specifically, it looks like skills are a different structure than mcp, but overlap in what they provide? Skills seem to be just markdown file & then scripts (instead of prompts & tool calls defined in MCP?). Question I have is why would I use one over the other?

One difference I see is that with tool calls the LLM doesn’t see the actual code. It delegates the task to the LLM. With scripts in an agent, I think the agent can see the code being run and can decide to run something different. I may be wrong about this. The documentation says that assets aren’t read into context. It doesn’t say the same about scripts, which is what makes me think the LLM can read them.

Re: Claude Skills

#135

There seems to be a lot of overlap of this with MCP tools. Also presumably if there are a lot of skills, they will be too big for the context and one would need some way to find the right one. It is unclear how well this approach will scale.

Anthropic talks about ‘progressive disclosure’.

If you have a large number of skills, you could group them into a smaller number of skills each with subskills. That way not all the (sub)skill descriptions need to be loaded into context.

For example, instead of having a ‘PDF editing’ skill, you can have a ‘file editing’ skill that, when loaded into context, tells the LLM what type of files it can operate on. And then the LLM can ask for the info about how to do stuff with PDF files.

Re: Claude Skills

#136

Can someone explain the differences between this and Agents in Claude Code? Logically they seem similar. From my perspective it seems like Skills are more well-defined in their behavior and function?

Subagents have their own context. Skills do not.

Re: Claude Skills

#138
post #27

Earlier quoted context omitted.

If so it would be most welcome since LLMs doesn't always consistently follow the folder full of MD files to the same depth and consistency.

what makes it more likely that claude would read these .md files then?

Skills is hopefully put through a deterministic process that is guaranteed to occur, instead of a non-deterministic one that can only ever be guaranteed to happen most of the time (the way it is now).

Re: Claude Skills

#139
post #74

getting hard to keep up with skills, plugins, marketplaces, connectors, add-ons, yada yada

IMHO, don't, don't keep up. Just like "best practices in prompt engineering", these are just temporary workaround for current limitations, and they're bound to disappear quickly. Unless you really need the extra performance right now, just wait until models get you this performance out of the box instead of investing into learning something that'll be obsolete in months.

IMO, these are just marketing or new ways of using functions calling, under the hood they all get re-written as tools the model can call
Post reply on HN