Live data from Hacker News

Claude Skills

anthropic.com

361–370 of 443 posts

Re: Claude Skills

#361

Earlier quoted context omitted.

You forgot mcp-everything! Yes, it's a mess, and there will be a lot of churn, you're not wrong, but there are foundational concepts underneath it all that you can learn and then it's easy to fit insert-new-feature into your mental model. (Or you can just ignore the new features, and roll your own tools. Some people here do that with a lot of success.) The foundational mental model to get the hang of is really just:…

> You forgot mcp-everything! One great thing about the MCP craze, is it has given vendors a motivation to expose APIs which they didn’t offer before - real example, Notion’s public REST API lacks support for duplicating pages.. yes their web UI can do it, calling their private REST API, but their private APIs are complex, undocumented, and could stop working at any time with no notice. Then they added it to their MCP…

I remember reading in one of Simon Willison's recent blog posts his half-joking point that MCP got so much traction so fast because adding a remote MCP server allowed tech management at big companies whose C-suite is asking them for an "AI Strategy" to show that they were doing something. I'm sure that is a little bit true - a project framed as "make our API better and more open and well-documented" would likely never have got off the ground at many such places. But that is exactly what this is, really.

At least it's something we all reap the benefits of, even if MCP is really mostly just an api wrapper dressed up as "Advanced AI Technology."

Re: Claude Skills

#362

Earlier quoted context omitted.

> […] and then ask about a list of foo Not OP, but this is the part that I take issue with. I want to forget what tools are there and have the LLM figure out on its own which tool to use. Having to remember to add special words to encourage it to use specific tools (required a lot of the time, especially with esoteric tools) is annoying. I’m not saying this renders the whole thing “useless” because it’s good to have…

I've got a project that needs to run a special script and not just "make $target" at the command line in order to build, and with instructions in multiple . MD files, codex w/ gpt-5-high still forgets and runs make blindly which fails and it gets confused annoyingly often. ooh, it does call make when I ask it to compile, and is able to call a couple other popular tools without having to refer to them by name. if I as…

Yeah, I've done this just now.

I installed ImageMagik on Windows.

Created a ".claude/skills/Image Files/" folder

Put an empty SKILLS.md file in it

and told Claude Code to fill in the SKILLS.md file itself with the path to the binaries.

and it created all the instructions itself including examples and troubleshooting

and in my project prompted

"@image.png is my base icon file, create all the .ico files for this project using your image skill"

and it all went smoothly

Re: Claude Skills

#363
This is interesting, and I think there are use cases where this feature may make sense.

But this is not the feature they should or could have built, at least for Claude Code. CC already had a feature very similar to this -- subagents (or agents-as-tools).

Like Skills, Subagents have a metadata description that allows the model to choose to use them in the right moment.

Like Skills, Subagents can have their own instruction MD file(s) which can point to other files or scripts.

Like Skills, Subagents can have their own set of tools.

But critically, unlike Skills, Subagents don't pollute the main agent's context with noise from the specialized task.

And this, I think, is a major product design failure on Anthropic's part. Instead of a new concept, why not just expand the Subagent concept with something like "context sharing" or "context merging" or "in-context Subagents", or add the ability for the user to interactively chat with the Subagent via the normal CLI chat?

Now people have to choose between Skill and Subagent for what I think will be very similar or identical use cases, when really the choice of how this extra prompting/scripting should relate to the agent loop should be a secondary configuration choice rather than a fundamental architecture one.

Looking forward to a Skill-Subagenr shim that allows for this flexibility. Not thrilled that a hack like that is necessary, but I guess it's nice that CC's use of simple MD files on disk make it easy enough to accomplish.

Re: Claude Skills

#364

I’m kind of in stitches over this. Claude’s “skills” are dependent upon developers writing competent documentation and keeping it up to date…which most seemingly can’t even do for actual code they write, nevermind a brute-force black box like an LLM. For those few who do write competent documentation and have well-organized file systems and the risk tolerance to allow LLMs to run roughshod over data, sure, there’s so…

I always find it hilarious and painfully ironic that Anthropic can't even keep Claude Code's docs up to date. I don't know how much to read into it, but it is a modern marvel of process failure.

The team is obviously doing a lot of cool things very rapidly, so I don't want to be too negative, but ... please just ask Claude to review your own docs before you merge a change.

Re: Claude Skills

#365

Earlier quoted context omitted.

> I keep meaning to write a similar blog post with Python... Just have your agent do it.

I could, but I'm actually rather snobbish about my writing and don't believe in having LLMs write first drafts (for proofreading and editing, they're great). (I am not snobbish about my code. If it works and is solid and maintainable I don't care if I wrote it or not. Some people seem to feel a sense of loss when an LLM writes code for them, because of The Craft or whatever. That's not me; I don't have my identity wr…

I highly relate to this. Code works or it doesn’t. My writing feels a lot more like self expression. I agree that’s harder to “let go” to an agent.

Re: Claude Skills

#366

This is interesting, and I think there are use cases where this feature may make sense. But this is not the feature they should or could have built, at least for Claude Code. CC already had a feature very similar to this -- subagents (or agents-as-tools). Like Skills, Subagents have a metadata description that allows the model to choose to use them in the right moment. Like Skills, Subagents can have their own instru…

These are good points and I generally agree with you.

My guess is that, as I understand it, Anthropic’s belief is that subagents are usually not the proper tool for most tasks. In their guides and videos about proper use of subagents, they seem to really try to steer you toward “workflows” rather than subagents.

Maybe it’s time they rethink the overall strategy so that each new concept doesn’t have to be its own distinct feature (skills, plugins, marketplaces, subagents, etc).

https://www.anthropic.com/engineering/building-effective-age...

Re: Claude Skills

#367
With these patterns emerging, does anyone know how local LLMs are faring?

It seems to me that by combining MCP and "skills", we are adopting LLMs to be more useful tools; with MCP we restrict input and output when dealing with APIs so that the LLM can do what it is good at; translate between languages - in this case from English to various json subsets - and back.

And with skills we're serializing and formalizing prompts/context - narrowing the search space.

So that "summarize q1 numbers" gets reduced to "pick between these tools/MCP calls and parameterize on q1" - rather than the open ended task of "locate the data" and "try to match a sequence of tokens representing numbers - and generate tokens that look like a summary".

Given that - can we get away with much stupider LLMs for these types of use cases now - vs before we had these patterns?

Re: Claude Skills

#368
post #269

I’m kind of in stitches over this. Claude’s “skills” are dependent upon developers writing competent documentation and keeping it up to date…which most seemingly can’t even do for actual code they write, nevermind a brute-force black box like an LLM. For those few who do write competent documentation and have well-organized file systems and the risk tolerance to allow LLMs to run roughshod over data, sure, there’s so…

LLMs reward developers who can write. Maybe that's one of the reasons so many developers are pushing back against them!

I think this can’t be overstated and I see it my day-to-day working with developers on AI enablement.

If you are good a writing, documenting, planning? etc. - basically all the stuff in the SDLC that isn’t writing code, you’ll probably be much more effective at using LLMs for coding.

Re: Claude Skills

#369

I’m kind of in stitches over this. Claude’s “skills” are dependent upon developers writing competent documentation and keeping it up to date…which most seemingly can’t even do for actual code they write, nevermind a brute-force black box like an LLM. For those few who do write competent documentation and have well-organized file systems and the risk tolerance to allow LLMs to run roughshod over data, sure, there’s so…

I always find it hilarious and painfully ironic that Anthropic can't even keep Claude Code's docs up to date. I don't know how much to read into it, but it is a modern marvel of process failure. The team is obviously doing a lot of cool things very rapidly, so I don't want to be too negative, but ... please just ask Claude to review your own docs before you merge a change.

Not saying you’re wrong, but can you cite a couple of examples?

Re: Claude Skills

#370

I’m kind of in stitches over this. Claude’s “skills” are dependent upon developers writing competent documentation and keeping it up to date…which most seemingly can’t even do for actual code they write, nevermind a brute-force black box like an LLM. For those few who do write competent documentation and have well-organized file systems and the risk tolerance to allow LLMs to run roughshod over data, sure, there’s so…

>and if you’re training an agent for this specific task anyway, you’re effectively locking yourself to that specific LLM in perpetuity rather than a replaceable or promotable worker. That's ONE of the long games that are currently played, and is arguably their fallback strategy: The equivalent of vendor lock-in but for LLM providers.

From my IT POV, that’s what this is all about. It’s why none of these major players produce locally-executable LLMs (Mistral, Llama, and DeepSeek being notable exceptions), it’s why their interfaces are predominantly chat-based (to reduce personal skills growth and increase dependency on the chatbot), it’s why they keep churning out new services like Skills and Agents and “Research”, etc.

If any of these outfits truly cared about making AI accessible and beneficial to everyone, then all of them would be busting hump to distill models better to run on a wider variety of hardware, create specialized niches that collaborate with rather than seek to replace humans, and promote sovereignty over the AI models rather than perpetual licensing and dependency forever.

No, not one of these companies actually gives a shit about improving humanity. They’re all following the YC playbook of try everything, rent but never own, lock-in customers, and hope you get that one lucrative bite that allows for an exit strategy of some sort while promoting the hell out of it and yourself as the panacea to a problem.

Post reply on HN