What useful Claude Code Skills have you made so far?
Claude Skills are awesome, maybe a bigger deal than MCP
291–300 of 383 posts
Re: Claude Skills are awesome, maybe a bigger deal than MCP
#292We're doing something like this internally. Our monorepo context files were much too big, so we built a progressive tree of fragments to load up for different tasks. I am struck by how much these kinds of context documents resemble normal developer documentation, but actually useful and task-oriented. What was the barrier to creating these documents before? Three theories on why this is so different: 1) The feedback…
It is primarily a principal agent problem, with a hint of marshmallow test. If you are a developer who is not writing the documents for consumption by AI, you are primarily writing documents for someone who is not you; you do not know what this person will need or if they will ever even look at them. They may, of course, help you, but you may not understand that, have the time, or discipline. If you are writing them…
I think it's not at all a marshmellow test; quite the opposite - docs used to be written way, way in advance of their consumption. The problem that implies is twofold. Firstly, and less significantly, it's just not a great return on investment to spend tons of effort now to maybe help slightly in the far future.
But the real problem with docs is that for MOST usecases, the audience and context of the readers matter HUGELY. Most docs are bad because we can't predict those. People waste ridiculous amounts of time writing docs that nobody reads or nobody needs based on hypotheses about the future that turn out to be false.
And _that_ is completely different when you're writing context-window documents. These aren't really documents describing any codebase or context within which the codebase exists in some timeless fashion, they're better understood as part of a _current_ plan for action on a acute, real concern. They're battle-tested the way docs only rarely are. And as a bonus, sure, they're retainable and might help for the next problem too, but that's not why they work; they work because they're useful in an almost testable way right away.
The exceptions to this pattern kind of prove the rule - people for years have done better at documenting isolatable dependencies, i.e. libraries - precisely because those happen to sit at boundaries where it's both easier to make decent predictions about future usage, and often also because those docs might have far larger readership, so it's more worth it to take the risk of having an incorrect hypothesis about the future wasting effort - the cost/benefit is skewed towards the benefit by sheer numbers and the kind of code it is.
Having said that, the dust hasn't settled on the best way to distill context like this. It's be a mistake to overanalyze the current situation and conclude that documentation is certain to be the long-term answer - it's definitely helpful now, but it's certainly conceivable that more automated and structured representations might emerge, or in forms better suited for machine consumption that look a little more alien to us than conventional docs.
Re: Claude Skills are awesome, maybe a bigger deal than MCP
#293Earlier quoted context omitted.
> How the hell can you predict they will "take off even more" when the feature is accessible for barely 24 hours at this point? That's what a prediction IS. If I waited until the feature had proven itself it wouldn't be much of a prediction. The feature has also been live for more than 24 hours. I reverse-engineered it a week ago: https://simonwillison.net/2025/Oct/10/claude-skills/ - and it's been invisibly powering…
> That's what a prediction IS. If I waited until the feature had proven itself it wouldn't be much of a prediction. No, that's merely guessing mate. Predictions are, at least in modern meaning, based on at least some data and some extrapolation model that more or less reliably predicts the development of your known dataset into future (uknown) values. I don't see you presenting either in your post, so that's not pred…
Wrong
Re: Claude Skills are awesome, maybe a bigger deal than MCP
#294> Over time the limitations of MCP have started to emerge. The most significant is in terms of token usage: GitHub’s official MCP on its own famously consumes tens of thousands of tokens of context, and once you’ve added a few more to that there’s precious little space left for the LLM to actually do useful work.
Supabase MCP really devours your context window. IIRC, it uses 8k for its search_docs tool alone, just on load. If you actually use search_docs, it can return >30k tokens in a single reply.
Workaround: I just noticed yesterday that Supabase MCP now allows you to choose which tools are available. You can turn off the docs, and other tools. [0]
If you are wondering why you should care, all models get dumber as the context length increases. This happens much faster than I had expected. [1]
Re: Claude Skills are awesome, maybe a bigger deal than MCP
#295One idea I'm toying with right now: My company has some internal nodejs libraries, some of which are quite large (think: codegen API library, thousands of types). When a new version is published: task claude code to distill the entire library down to a skill, then bundle that in with the npm package. Then when the package is installed, postinstall a script that copies the skill from the dependency to the parent proje…
Maybe the skill could have references to the code. Like if everything else fails it can look at the implementation.
Intuitively it feels like if you need to look at the implementation to understand the library then the library is probably not well documented/structured.
I think the ability to look into the code should exist but shouldn't be necessary for the majority of use cases
Re: Claude Skills are awesome, maybe a bigger deal than MCP
#296They're completely different things. MCP is a standardised lightweight integration interface and skills are dynamic rules.
You could also say horse carriages and cars are very different things, yet one replaced the other.
MCP lets agents do stuff. Skills let agents do stuff. There's the overlap.
Re: Claude Skills are awesome, maybe a bigger deal than MCP
#297[flagged]
I'm not. Here are my disclosures: https://simonwillison.net/about/#disclosures And if my disclosures aren't enough for you, here's the FTC explaining how it would be illegal for an AI vendor to pay someone to write something like this without both sides disclosing the relationship: https://www.ftc.gov/business-guidance/resources/ftcs-endorse...
While it's very honest of you to disclose in full your various affiliations to the LLM vendors, and it does look like you're not being paid by them - the reason they are inviting you for the early previews and all that is precisely because they either expect or assume you won't go to critical on them. And that shows in your writing to be honest. I'd assume the same in their place. So yeah, not paid obviously, but it seems indirectly incentivised to not be as critical as one could be...
Re: Claude Skills are awesome, maybe a bigger deal than MCP
#298Earlier quoted context omitted.
Your LLMs get rid of comments? Mine add them incessantly.
I know this is highly controversial, but I now leave the comments in. My theory is that the “probability space” the LLM is writing code in can’t help but write them, so if i leave them next LLM that reads the code will start in the same space. Maybe it’s too much, but currently I just want the code to be right and I’ve let go of the exact wording of comments/variables/types to move faster.
Similar logic, but hard disagree on keeping comments that are exactly what the following code does.
They are useful to the LLM in writing the code (which comes after).
But when it comes to an LLM reading that code later its just a waste of context.
For humans its a waste of screen space.
A comment should only explain what the following thing does if its hard to parse for some reason.
Otherwise it should add information: why something is as it is, I.e. some special case, add breadcrumbs to other bits of the code etc.
I wish these coding agents had a post step to remove any LLMish comments they added during writing, and I want linters that flag these.
Re: Claude Skills are awesome, maybe a bigger deal than MCP
#299Earlier quoted context omitted.
Depends which definition of RAG you're talking about. RAG was originally about adding extra information to the context so that an LLM could answer questions that needed that extra context. On that basis I guess you could call skills a form of RAG, but honestly at that point the entire field of "context engineering" can be classified as RAG too. Maybe RAG as a term is obsolete now, since it really just describes how w…
I’d rather say you can use skills to do RAG by supplying the right tools in the skill (“here’s how you query our database”). Calling the skill system itself RAG is a bit of a stretch IMO, unless you end up with so many skills that their summaries can’t fit in the context and you have to search through them instead. ;)
All skills are RAG, a subset of skills can add more RAG.
Re: Claude Skills are awesome, maybe a bigger deal than MCP
#300What's the difference between skills and slash commands? Skills are picked up and selected implicitly by the chat? Anything else?