[dead]
Claude Skills
411–420 of 443 posts
Re: Claude Skills
#412Earlier quoted context omitted.
12 months ago we didn't have Claude Code or Codex CLI - in fact the whole category of "coding agents" was very thin. The only "reasoning" model was the o1 preview. We didn't have MCP, but that wasn't a big deal because the models were mostly pretty weak at tool calling anyway. The DeepSeek moment hadn't happened yet - the best available open weights models were from Mistral and Llama and were nowhere close to the fro…
In October we had Aider, which is more useful to me then Claude Code, as it allows more targeted changes and faster switching between models, modes and into my personal typing. Not just Claude Code, but all these tools are just better in generating more slop, which is generating more effort in your codebase in the future. Making it less agile, harder to maintain and harder to extend without breaking. I still haven’t…
[dead]
Re: Claude Skills
#413Earlier quoted context omitted.
what makes it more likely that claude would read these .md files then?
It includes both the file names and a configurable description string. That’s where you put the TLDR of when to use each skill.
This improves it a great deal but at a certain point, maybe 60-80% of the way it can start fading.
Re: Claude Skills
#414Earlier quoted context omitted.
I disagree. You wrap this up in a container / runtime spec. + package index and suddenly you’ve got an agent that can dynamically extend its capabilities based upon any skill that anybody has shared. Instead of `uv add foo` for Python packages you’ve got `skill add foo` for agent skills that the agent can run whenever they have a matching need.
Fundamentally you're getting hyped over a framework to append text to your prompt ?
that's pretty reductive. it's an interesting shift in thinking how to work with these tools.
whether there's some skillhub somewhere like there are MCP registries... you could totally see it happening.
Re: Claude Skills
#415Earlier quoted context omitted.
Just went to the comments searching for a comment like yours and I'm surprised it seems to be the only one calling this out. My take on this is also that "Skills" is just detailed documentation, which like you correctly point out, basically never exist for any project. Maybe LLM skills will be the thing that finally makes us all write detailed documentation but I kind of doubt it.
I think part of the reason developers are resistant to writing docs is because the perceived value is very low. This perceived value would be much higher if the docs were to tangibly become part of a productive tool chain
I generally find the aversion to documentation comes from one of three places:
* A belief that sufficient documentation means their job is at risk (which, to be fair, is 100% correct in this Capitalist hellscape - ask me how I know first-hand)
* It’s irrelevant since the code will change again in a short amount of time
* A fierce protection over one’s output, sometimes manifesting as a belief that nobody but you could ever understand what you created
Sure, sometimes there’s wholly incompetent developers who can’t even tell you their own dependencies, but I’d like to believe they’re still the exception rather than the rule. As for the value proposition, collaborators and cooperators understand the immense value of good, thorough documentation; those who don’t see the value, at least in my experience, are often adversarial instead of cooperative.
Re: Claude Skills
#416Earlier quoted context omitted.
There is an acquisition cost of researching and developing the LLM, but the running cost should not be classified as a wage, hence cost of labor is zero.
Don't call it "free labor" at all then? Regardless, running an LLM is usually not free.
I wouldn’t be able to express the embedded irony if I didn’t use this oxymoron.
On the one hand, AI doesn’t classify as labor in a traditional sense, even though some aspire to replace labor with AI.
On the other hand, if it classified as labor under some new definition, it isn’t free when you consider the external costs of outsourcing basic brain activity, as an individual and as a society.
Re: Claude Skills
#417Earlier quoted context omitted.
That's where my confusion is. How is this pattern similar to MCP? Can it also authenticate against 3rd party apis, similar to MCP?
If you want to call a third party API from a skill you can use instructions like this: To access the GitHub API, use curl to make requests to api.GitHub.com and pass the GITHUB_API_KEY environment variable in the Authorization: Bearer header
The "everything is a prompt" thing is interesting, but do we lose some deterministic behavior of MCP plumbing and execution for when the LLM simply doesn't want to follow the 'rules' and possibly hallucinates while processing the skill prompt? How do we make it consistent?
Re: Claude Skills
#418Earlier quoted context omitted.
It's a false dichotomy. LLMs are already being trained with RL to have goal directedness. He is right that non-RL'd LLMs are just mimicry, but the field already moved beyond that.
Explain something to me that I've long wondered: how does Reinforcement Learning work if you cannot measure your distance from the goal? In other words, how can RL be used for literally anything qualitative?
RL works great on verifiable domains like math, and to some significant extent coding.
Coding is an interesting example because as we change levels of abstraction from the syntax of a specific function to, say, the architecture of a software system, the ability to measure verifiable correctness declines. As a result, RL-tuned LLMs are better at creating syntactically correct functions but struggle as the abstraction layer increases.
In other fields, it is very difficult to verify correctness. What is good art? Here, LLMs and their ilk can still produce good output, but it becomes hard to produce "superhuman" output, because in nonverifiable domains their capability is dependent on mimicry; it is RL that gives the AI the ability to perform at superhuman levels. With RL, rather than merely fitting its parameters to a set of extant data it can follow the scent of a ground truth signal of excellence. No scent, no outperformance.
Re: Claude Skills
#419Earlier quoted context omitted.
Skills are cool, but to me it's more of a design pattern / prompt engineering trick than something in need of a hard spec. You can even implement it in an MCP - I've been doing it for a while: "Before doing anything, search the skills MCP and read any relevant guides."
I disagree. You wrap this up in a container / runtime spec. + package index and suddenly you’ve got an agent that can dynamically extend its capabilities based upon any skill that anybody has shared. Instead of `uv add foo` for Python packages you’ve got `skill add foo` for agent skills that the agent can run whenever they have a matching need.
Exactly! I don't think Skills is a new algorithm but it's definitely a new paradigm of organizing your prompt. Essentially, dynamic context assembling with stuff crossing user boundaries which. They even mention that they are working on skill sharing across teams in an organization. You can take this expand to global user base sharing things with each other in an agent.
Re: Claude Skills
#420Earlier quoted context omitted.
I think part of the reason developers are resistant to writing docs is because the perceived value is very low. This perceived value would be much higher if the docs were to tangibly become part of a productive tool chain
I generally find the aversion to documentation comes from one of three places: * A belief that sufficient documentation means their job is at risk (which, to be fair, is 100% correct in this Capitalist hellscape - ask me how I know first-hand) * It’s irrelevant since the code will change again in a short amount of time * A fierce protection over one’s output, sometimes manifesting as a belief that nobody but you coul…
[dead]