You too can win a jackpot by spinning the wheel just like these other anecdotal winners. Pay no attention to your dwindling credits every time you do though.
I have been using claude code to create some and organize them but they can have diminishing return.
Of course this is why the model providers keep shipping new ones; without them their product is a commodity.
It’s not exactly wrong, but it leaves out a lot of intermediate steps.
abstraction
abstraction
abstraction
abstraction
...This stuff is like front end devs building fad add-ons which call into those core elements and falsely market themselves as fundamental advancements.
Plugins include: * Commands * MCPs * Subagents * Now, Skills
Marketplaces aggregate plugins.
From a technical perspective, it seems like unnecessary complexity in a way. Of course I recognize there are lot of product decisions that seem to layer on 'unnecessary' abstractions but still have utility.
In terms of connecting with customers, it seems sensible, under the assumption that Anthropic is triaging customer feedback well and leading to where they want to go (even if they don't know it yet).
Update: a sibling comment just wrote something quite similar: "All these things are designed to create lock in for companies. They don’t really fundamentally add to the functionality of LLMs." I think I agree.
But context engineering very much not going anywhere as a discipline. Bigger and better models will by no means make it obsolete. In fact, raw model capability is pretty clearly leveling off into the top of an S-curve, and most real-world performance gains over the last year have been precisely because of innovations on how to better leverage context.
This is where waiting for this stuff to stablize/standardize, and then writing a "skill" based on an actual RFC or standard protocol makes more sense, IMO. I've been burned too many times building vendor-locked chatbot extensions.
Not mine! I made a few when they first opened it up to devs, but I was trying to use Azure Logic Apps (something like that?) at the time which was supremely slow and finicky with F#, and an exercise in frustration.
Building a new one that works well is a project, but then it will scale up as much as you like.
This is bringing some of the advantages of software development to office tasks, but you give up some things like reliable, deterministic results.
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.
The idea is interesting and something I shall consider for our platform as well.
"Equipping agents for the real world with Agent Skills" https://www.anthropic.com/engineering/equipping-agents-for-t...
You get the best of both worlds if you can select tokens by problem rather than by folder.
The key question is how effective this will be with tool calling.
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?
Skills can merge together like lego.
Agents might be more separated.
http://github.com/ryancnelson/deli-gator I’d love any feedback
I've been emulating this in claude code by manually @tagging markdown files containing guides for common tasks in our repository. Nice to see that this step is now automatic as well.
https://github.com/anthropics/skills/blob/main/document-skil...
I was dealing with 2 issues this morning getting Claude to produce a .xlsx that are covered in the doc above
We used to call that a programming language. Here, they are presumably repeatable instructions how to generate stolen code or stolen procedures so users have to think even less or not at all.
Yes, this can only end well.
For folks who this seems elusive for, it's worth learning how the internals actually work, helps a great deal in how to structure things in general, and then over time as the parent comment said, specifically for individual cases.
On the other hand, LLMs have a programatic context with consistent storage and the ability to have perfect recall, they just don't always generate the expected output in practice as the cost to go through ALL context is prohibitive in terms of power and time.
Skills.. or really just context insertion is simply a way to prioritize their output generation manually. LLM "thinking mode" is the same, for what it's worth - it really is just reprioritizing context - so not "starting from scratch" per se.
When you start thinking about it that way, it makes sense - and it helps using these tools more effectively too.
I’d been re-teaching Claude to craft Rest-api calls with curl every morning for months before i realized that skills would let me delegate that to cheaper models, re-using cached-token-queries, and save my context window for my actual problem-space CONTEXT.
what the fuck, there is absolutely no way this was cheaper or more productive than just learning to use curl and writing curl calls yourself. Curl isn't even hard! And if you learn to use it, you get WAY better at working with HTTP!
You're kneecapping yourself to expend more effort than it would take to just write the calls, helping to train a bot to do the job you should be doing
You are bad at reading comprehension. My comment meant I can tell Claude “update jira with that test outcome in a comment” and, Claude can eventually figure that out with just a Key and curl, but that’s way too low level.
What I linked to literally explains that, with code and a blog post.
Not really. It's a consequential issue. No matter how big or small the context window is, LLMs simply do not have the concept of goals and consequences. Thus, it's difficult for them to acquire dynamic and evolving "skills" like humans do.
The description is equivalent to your short term memory.
The skill is like your long term memory which is retrieved if needed.
These should both be considered as part of the AI agent. Not external things.
Of course OpenAI and Anthropic want to be able to reuse the same servers/memory for multiple users, otherwise it would be too expensive.
Could we have "personal" single-tenant setups? Where the LLM incorporates every previous conversation?
Which is precisely why Richard Sutton doesn't think LLMs will evolve to AGI[0]. LLMs are based on mimicry, not experience, so it's more likely (according to Sutton) that AGI will be based on some form of RL (reinforcement learning) and not neural networks (LLMs).
More specifically, LLMs don't have goals and consequences of actions, which is the foundation for intelligence. So, to your point, the idea of a "skill" is more akin to a reference manual, than it is a skill building exercise that can be applied to developing an instrument, task, solution, etc.
> More specifically, LLMs don't have goals and consequences of actions, which is the foundation for intelligence.
Citation?
And I associate that part to AGI being able to do cutting edge research and explore new ideas like humans can. Where, when that seems to “happen” with LLMs it’s been more debatable. (e.g. there was an existing paper that the LLM was able to tap into)
I guess another example would be to get an AGI doing RL in realtime to get really good at a video game with completely different mechanics in the same way a human could. Today, that wouldn’t really happen unless it was able to pre-train on something similar.
He is right that non-RL'd LLMs are just mimicry, but the field already moved beyond that.
But this is easier said than done. Current models require vastly more learning events than humans, making direct supervision infeasable. One strategy is to train models on human supervisors, so they can bear the bulk of the supervision. This is tricky, but has proven more effective than direct supervision.
But, in my experience, AIs don't specifically struggle with the "qualitative" side of things per-se. In fact, they're great at things like word choice, color theory, etc. Rather, they struggle to understand continuity, consequence and to combine disparate sources of input. They also suck at differentiating fact from fabrication. To speculate wildly, it feels like it's missing the the RL of living in the "real world". In order to eat, sleep and breath, you must operate within the bounds of physics and society and live forever with the consequences of an ever-growing history of choices.
While we might agreed that language is foundational to what it is to be human, it's myopic to think its the only thing. LLMs are based on training sets of language (period).
Which eventually forces you to take a step back and start questioning basic assumptions until (hopefully) you get a spark of realization of the flaws in your original plan, and then recalibrate based on that new understanding and tackle it totally differently.
But instead I watch Claude struggling to find a directory it expects to see and running random npm commands until it comes to the conclusion that, somehow, node_modules was corrupted mysteriously and therefore it needs to wipe everything node related and manually rebuild the project config by vague memory.
Because no big deal, if it’s wrong it’s the human's problem to untangle and Anthropic gets paid either way so why not try?
In fairness I have on many an occasion worked with real life software developers who really should know better deciding the problem lies anywhere but their initial model of how this should work. Quite often that developer has been me, although I like to hope I've learned to be more skeptical when that thought crosses my mind now.
Which is why I think the parent post had a great observation about human problem solving having evolved in a universe inherently formed by the additive effect of every previous decision you've ever made made in your life.
There's a lot of variance in humans, sure, but inescapable stakes/skin in the game from an instinctual understanding that you can't just revert to a previous checkpoint any time you screw up. That world model of decisions and consequences helps ground abstract problem solving ability with a healthy amount of risk aversion and caution that LLMs lack.
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.
While that might true, it fundamentally means it's not going to ever replicate human or provide super intelligence.
Many people would argue that's a good thing
That might be true, but we're talking about the fundamentals of the concept. His argument is that you're never going to reach AGI/super intelligence on an evolution of the current concepts (mimicry) even through fine tuning and adaptions - it'll like be different (and likely based on some RL technique). At least we have NO history to suggest this will be case (hence his argument for "the bitter lesson").
At the very end of an extremely long and sophisticated process, the final mapping is softmax transformed and the distribution sampled. That is one operation among hundreds of billions leading up to it.
It’s like saying is a jeopardy player is random word generating machine — they see a question and they generate “what is “ followed by a random word—random because there is some uncertainty in their mind even in the final moment. That is both technically true, but incomplete, and entirely missing the point.
You may disagree with this take but its not uninformed. Many LLMs use self‑supervised pretraining followed by RL‑based fine‑tuning but that's essentially it - it's fine tuning.
Also how do you think the most successful RL models have worked? AlphaGo/AlphaZero both use Neural Networks for their policy and value networks which are the central mechanism of those models.
ChatGPT broke upen the dam to massive budget on AI/LM and LLM will probably be a puzzle peace to AGI. But otherwise?
I mean it should be clear that we have so much work to do like RL (which now happens btw. on massive scale because you thumb up or down every day), thinking, Model of Experts, toolcalling and super super critical: Architecture.
Compute is a hard upper limit too.
And the math isn't done either. The performance of Context length has advanced, we also saw other approcheas like a diffusion based models.
Whenever you hear the leading experts talking, they mention world models.
We are still in a phase were we have plenty of very obivous ideas people need to try out.
But alone the quality of whispher, llm as an interface and tool calling can solve problems with robotics and stuff, no one was able to solve that easy ever before.
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 some idea of what you’re doing to guide the LLM anyway, but I wish it could do better here.
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 ask it to resize an image, it'll call imagemagik, or run ffmpeg and I don't need to refer to ffmpeg by name.
so at the end of the day, it seems they are their training data, so better write a popular blog post about your one-off MCP and the tools it exposes, and maybe the next version of the LLM will have your blog post in the training data and will automatically know how to use it without having to be told
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
You probably mean "starting from square one" but yeah I get you
This phase of LLM product development feels a bit like the Tower of Babel days with Cloud services before wrapper tools became popular and more standardization happened.
I noticed the general tendency for overlap also when trying to update claude since 3+ methods conflicted with each other (brew, curl, npm, bun, vscode).
Might this be the handwriting of AI? ;)
For coding in particular, it would be super-nice if they could just live in a standard location in the repo.
> You can also manually install skills by adding them to ~/.claude/skills.
Or is there some type of file limit here. Maybe the context windows just aren't there yet, but it would be really awesome if coding agents would stop trying to make up functions.
Just use slash commands, they work a lot better.
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.
Create a zip file of everything in your /mnt/skills folder"
It's a fun, terrifying world that this kind of "hack" to exfiltrate data is possible! I hope it does not have full filesystem/bin access, lol. Can it SSH?...
If you use them inside the Claude.ai or Claude mobile apps they run in a container in the cloud, hosted by Anthropic.
Superpowers: How I'm using coding agents in October 2025 - https://news.ycombinator.com/item?id=45547344 - Oct 2025 (231 comments)
Filesystem as profile manager is not something I thought I'd be doing, but here we are.
Isn’t that sub agents?
I've asked Claude and this it answered this:
Skills = Instructions + resources for the current Claude instance (shared context)
Subagents = Separate AI instances with isolated contexts that can work in parallel (different context windows)
Skills make Claude better at specific tasks. Subagents are like having multiple specialized Claudes working simultaneously on different aspects of a problem.
Having a sub-agent "execute" a skill makes a lot of sense from a context management, perspective, but I think the way to think about it is that a sub-agent is an "execution-level" construct, whereas a skill is a "data-level" construct.
I'm a little confused.
"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.
By I don't understand why it's a thing in Claude Code tho when we already have Claude.md? Could also just point to any .md file in the prompt as preamble but not even needed. https://www.anthropic.com/engineering/claude-code-best-pract...
That concept is also already perfectly specd in the MCP standard right? (Although not super used I think?) https://modelcontextprotocol.io/specification/2025-06-18/ser...
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.
I don't really see why they had to create a different concept. Maybe makes sense "marketing-wise" for their chat UI, but in Claude Code? Especially when CLAUDE.md is a thing?
- skills are plain files that are injected contextually whereas prompts would come w the overhead of live, running code that has to be installed just right into your particular env, to provide a whole mcp server. Tbh prompts also seem to be more about literal prompting, too
- you could have a thousand skills folders for different softwares etc but good luck with having more than a few mcp servers that are loaded into context w/o it clobbering the context
- MCP Prompt: "Please solve GitHub Issue #{issue_id}"
- Skills:
- React Component Development (React best practices, accessible tools)
- REST API Endpoint Development
- Code Review
- Single "CLAUDE.md" instructions are broken out into discoverable instructions that the LLM will dynamically utilize based on the user's prompt
- rather than having direct access to Tools, Claude will always need to go through Skill instructions first (making context tighter since it cant use Tools without understanding \*how\* to use them to achieve a certain goal)
- Clients will be able to add infinite MCP servers / tools, since the Tools themselves will no longer all be added to the context window
MCPs can wrap APIs to make them usable by an LLM agent.
Skills offer a context-efficient way to make extra instructions available to the agent only when it needs them. Some of those instructions might involve telling it how best to use the MCPs.
Sub-agents are another context management pattern, this time allowing a parent agent to send a sub-agent off on a mission - optimally involving both skills and MCPs - while saving on tokens in that parent agent.
Across ChatGPT and Claude we now have tools, functions, skills, agents, subagents, commands, and apps, and there's a metastasizing complex of vibe frameworks feeding on this mess.
This is also why not everyone is an early adopter. There are mental costs involved in staying on top of everything.
Usually, there are relatively few adopters of a new technology.
But with LLMs, it's quite the opposite: there was a huge number of early adopters. Some got extremely excited and run hundreds of agents all the time, some got burned and went back to the good old ways of doing things, whereas the majority is just using LLMs from time to time for various tasks, bigger of smaller.
https://en.wikipedia.org/wiki/Technology_adoption_life_cycle
I focus on building projects delivering some specific business value and pick the tools that gets me there.
There is zero value in spending cycles by engaging in new tools hype.
I’m surprised/disappointed that I haven’t seen any papers out of the programming languages community about how to integrate agentic coding with compilers/type system features/etc. They really need to step up, otherwise there’s going to be a lot of unnecessary CO2 produced by tools like this.
The way I can get any decent code out of them for typescript is by having no joke, 60 eslint plugins. It forces them to write actual decent code, although it takes them forever
I like the trend where the agent decides what models, tooling and thought process to use. That seems to me far more powerful than asking users to create solutions for each discreet problem space.
You see a text file and understand that it can be anything, but end users can’t/won’t make the jump. They need to see the words Note, Reminder, Email, etc.
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:
* An LLM
* ...called in a loop
* ...maintaining a history of stuff it's done in the session (the "context")
* ...with access to tool calls to do things. Like, read files, write files, call bash, etc.
Some people call this "the agentic loop." Call it what you want, you can write it in 100 lines of Python. I encourage every programmer I talk to who is remotely curious about LLMs to try that. It is a lightbulb moment.
Once you've written your own basic agent, if a new tool comes along, you can easily demystify it by thinking about how you'd implement it yourself. For example, Claude Skills are really just:
1) Skills are just a bunch of files with instructions for the LLM in them.
2) Search for the available "skills" on startup and put all the short descriptions into the context so the LLM knows about them.
3) Also tell the LLM how to "use" a skill. Claude just uses the `bash` tool for that.
4) When Claude wants to use a skill, it uses the "call bash" tool to read in the skill files, then does the thing described in them.
and that's more or less it, glossing over a lot of things that are important but not foundational like ensuring granular tool permissions, etc.
Definitely want to try this out. Any resources / etc. on getting started?
It uses Go, which is more verbose than Python would be, so he takes 300 lines to do it. Also, his edit_file tool could be a lot simpler (I just make my minimal agent "edit" files by overwriting the entire existing file).
I keep meaning to write a similar blog post with Python, as I think it makes it even clearer how simple the stripped-down essence of a coding agent can be. There is magic, but it all lives in the LLM, not the agent software.
Just have your agent do it.
(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 wrapped up in my code. Maybe I did when I was more junior, but I've been in this game long enough to just let it go.)
https://ravinkumar.com/GenAiGuidebook/language_models/Agents... https://github.com/canyon289/ai_agent_basics/blob/main/noteb...
sounds like prompt is what you send, and caching is important here because what you send is derived from previous responses from llm calls earlier?
sorry to sound dense, I struggle to understand where and how in the mental model the non-determinism of a response is dealt with. is it just that it's all cached?
1) Maintaining the state of the "conversation" history with the LLM. LLMs are stateless, so you have to store the entire series of interactions on the client side in your agent (every user prompt, every LLM response, every tool call, every tool call result). You then send the entire previous conversation history to the LLM every time you call it, so it can "see" what has already happened. In a basic agent, it's essentially just a big list of strings, and you pass it into the LLM api on every LLM call.
2) "Prompt caching", which is a clever optimization in the LLM infrastructure to take advantage of the fact that most LLM interactions involve processing a lot of unchanging past conversation history, plus a little bit of new text at the end. Understanding it requires understanding the internals of LLM transformer architecture, but the essence of it is that you can save a lot of GPU compute time by caching previous result states that then become intermediate states for the next LLM call. You cache on the entire history: the base prompt, the user's messages, the LLM's responses, the LLM's tool calls, everything. As a user of an LLM api, you don't have to worry about how any of it works under the hood, you just have to enable it. The reason to turn it on is it dramatically increases response time and reduces cost.
Hope that clarifies!
I'm personally just curious how far, clever, insightful, any given product is "on top of" the foundation models. I'm not in it deep enough to make claims one way or the other.
So this shines a little more light, thanks!
Do you think a non-programmer could realistically build a full app using vibe coding?
What fundamentals would you say are essential to understand first?
For context, I’m in finance, but about 8 years ago I built a full app with Angular/Ionic (live on Play Store, under review on Apple Store at that time) after doing a Coursera specialization. That was my first startup attempt, I haven’t coded since.
My current idea is to combine ChatGPT prompts with Lovable to get something built, then fine-tune and iterate using Roo Code (VS plugin).
I’d love to try again with vibe coding. Any resources or directions you’d recommend?
If your app has to do something useful, your app just exploded in complexity and corner cases that you will have to account for and debug. Also, if it does anything interesting that the LLM has not yet seen a hundred thousand times, you will hit the manual button quite quickly.
Claude especially (with all its deserved praise) fantasizes so much crap together while claiming absolute authority in corner cases, it can become annoying.
For now, my MVP is pretty simple: a small app for people to listen to soundscapes for focus and relaxation. Even if no one uses, at least it's going to be useful to me and it will be a fun experiment!
I’m thinking of starting with React + Supabase (through Lovable), that should cover most of what I need early on. Once it’s out of the survival stage, I’ll look into adding more complex functionality.
Curious, in your experience, what’s the best way to keep things reliable when starting simple like this? And are there any good resources you can point to?
I already have a feature list and a basic PRD, and I’m working through the main wireframes right now.
What I’m still figuring out is the planning and architecture side, how to go from that high-level outline to a solid structure for the app. I’d rather move step by step, testing things gradually, than get buried under too much code where I don’t understand anything.
I’m even considering taking a few React courses along the way just to get a better grasp of what’s happening under the hood.
Do you know of any good resources or examples that could help guide this kind of approach? On how to break this down, what documents to have?
If I'd use Vibe coding I wouldn't use Lovable but Claude code. You can run it in your terminal.
And I would ask it to use NextAuth, NextJS and Prisma (or another ORM), and connect it with SQLite or an external MariaDB managed server (for easy development you can start with SQLLite, for deployment to vercel you need an external database).
People here shit on nextjs, but due to its extensive documentation & usage the LLM's are very good at building with it, and since it forces a certain structure it produces generally decently structured code that is workable for a developer.
Also vercel is very easy to deploy, just connect Github and you are done.
Make sure to properly use GIT and commit per feature, even better branch per feature. So you can easily revert back to old versions if Claude messed up.
Before starting, spend some time sparring with GPT5 thinking model to create a database scheme thats future proof before starting out. It might be a challenge here to find the right balance between over-engineering and simplicity.
One caveat: be careful to run migration on your production database with Claude. It can accidentally destroy it. So only run your claude code on test databases.
I’m not 100% set on Lovable yet. Right now I’m using Stitch AI to build out the wireframes. The main reason I was leaning toward Lovable is that it seems pretty good at UI design and layout.
How does Claude do on that front? Can it handle good UI structure or does it usually need some help from a design tool?
Also, is it possible to get mobile apps out of a Next.js setup?
My thought was to start with the web version, and later maybe wrap it using Cordova (or Capacitor) like I did years ago with Ionic to get Android/iOS versions. Just wondering if that’s still a sensible path today.
For personal or professional use?
If you want to make it public I would say 0% realistic. The bugs, security concerns, performance problems etc you would be unable to fix are impossible to enumerate.
But even if you had a simple loging and kept people's email and password, you can very easily have insecure dbs, insecure protections against simple things like mysqliinjections etc.
You would not want to be the face of "vibe coder gives away data of 10k users"
For auth, I’ll be using Supabase, and for the MVP stage I think Lovable should be good enough to build and test with maybe a few hundred users. If there’s traction and things start working, that’s when I’d plan to harden the stack and get proper security and code reviews in place.
If you then introduce other devs you have 2 paths, they either build on top of vibe coding, which is going to leave you vulnerable to those bugs and honestly make their life a misery as they are working on top of work that missed basic decisions that will help it grow. (Imagine a non architect built your house, the walls might be straight but he didnt know to level the floor, or to add the right concrete to support the weight of a second floor)
Or the other path is they rebuild your entire app correctly. With the only advantage of the MVP and the users showing some viability for the idea. But the time it will take to rewrite it means in a fast moving space like start ups someone can quickly overtake you.
Its a risky proposition that means you are not going to create a very adequate base for the people you might hire.
I would still recommend against it, thinking that AI is more like WebMD, it can help someone who is already a doctor but it will confuse, and potentially hurt those without enough training to know what to look for.
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 server - and MCP is just a JSON-RPC API, you aren’t limited to only invoking it from an LLM agent, you can also invoke it from your favourite scripting language with no LLM involved at all
PS. Just want to say, Notion MCP is still very buggy. It can't handle code block, nor large page very well
I have no idea what is going on inside Notion, but if I guess - the web UI (including the private REST API which backs it), the public REST API, and the AI features are separate teams, separate PMs, separate budgets - so it is totally unsurprising they don’t all have the same feature set. Of course, if parity were an executive priority, they could get there-but I can only assume it isn’t.
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."
I’ve done this a few times (pre and post MCP) and learned a lot each time.
That description sounds a lot like PocketFlow, an AI/LLM development framework based on a loop that's about 100 lines of python:
https://github.com/The-Pocket/PocketFlow
(I'm not at all affiliated with Pocket Flow, I just recall watching a demo of it)
Yeah, if you chase buzzword compliance and try to learn all these things outside of a particular use case you're going to burn out and have a bad time. So... don't?
You have to remember, every system or platform has a total complexity budget that effectively sits at the limit of what a broad spectrum of people can effectively incorporate into their day to day working memory. How it gets spent is absolutely crucial. When a platform vendor adds a new piece of complexity, it comes from the same budget that could have been devoted to things built on the platform. But unlike things built on the platform, it's there whether developers like it and use it or not. It's common these days that providers binge on ecosystem complexity because they think it's building differentiation, when in fact it's building huge barriers to the exact audience they need to attract to scale up their customer base, and subtracting from the value of what can actually be built on their platform.
Here you have a highly overlapping duplicative concept that's taking a solid chunk of new complexity budget but not really adding a lot of new capability in return. I am sure the people who designed it think they are reducing complexity by adding a "simple" new feature that does what people would otherwise have to learn themselves. It's far more likely they are at break even for how many people they deter vs attract from using their platform by doing this.
I was able to try Beads[1] quickly with my framework and decided I like it enough to keep it. If I don't like it, just drop it, they're composable.
[0]: https://github.com/aperoc/toolkami.git [1]: https://github.com/steveyegge/beads
… jk… I’ll bet at least one person was like “ah, damnit, what did I miss…” for a second.
AI will help you solve problems you wouldn't have without AI.
MCP allows anybody to extend their own LLM application's context and capabilities using pre-built *third party* tools.
Agent Skills allows you to let the LLM enrich and narrow down it's own context based on the nature of the task it's doing.
I have been using a home grown version of Agent Skills for months now with Claude in VSCode, using skill files and extra tools in folders for the LLM to use. Once you have enough experience writing code with LLMs, you will realize this is a natural direction to take for engineering the context of LLMs. Very helpful in pruning unnecessary parts from "general instruction files" when working on specific tasks - all orchestrated by the LLM itself. And external tools for specific tasks (such as finding out which cell in a jupyter notebook contains the code that the LLM is trying to edit, for example) make LLMs a lot more accurate and efficient, efficient because they are not burning through precious tokens to do the same and accurate because the tools are not stochastic.
With Claude Skills now I don't need to maintain my home grown contraption. This is a welcome addition!
This is the skill description:
Create beautiful visual art in .png and .pdf documents using design philosophy. You should use this skill when the user asks to create a poster, piece of art, design, or other static piece. Create original visual designs, never copying existing artists' work to avoid copyright violations.
What it created was an abstract art museum-esque poster with random shapes and no discernable message. It may have been trying to design a playing card but just failed miserably which is my experience with most AI image generators.
It certainly spent a lot of time, and effort to create the poster. It asked initial questions, developed a plan, did research, created tooling - seems like a waste of "tokens" given how simple and lame the resulting image turned out.
Also after testing I still don't know how to "use" one of these skills in an actual chat.
Roo Code just has "modes", and honestly, this is more than enough.
If you can manage to keep structuring slightly intelligent tools so that they compound, seems like AGI is achievable.
That's why the thing everyone is after right now is new ways to make those slight intelligences keep compounding.
Just like repeated multiplication of 1.001 grows indefinitely.
But starting earlier this year, I've started to see glimpses of what seems like intelligence (to me) in the tools, so who knows.
OpenAI ships extensions for ChatGPT - that feed more to plug into the consumer experience. Anthropic ships extensions (made for builders) into ClaudeCode - feel more DX.
...which would be great if the (likely binary) format of that was used internally, but something tells me an architectural screwup will lead to leaking the binaries and we'll have a dependency on a dumb inscrutable binary format to carry forward...
While I like the flexibility of deploying your own skills to claude for use org-wide, this really feels like what MCP should be for that use case, or what built-in analysis sandbox should be.
We haven't even gone mainstream with MCP and there are already 10 stand-ins doing roughly the same thing with a different twist.
I would have honestly preferred they called this embedded MCP instead of 'skills'.
[1] https://docs.claude.com/en/docs/claude-code/plugin-marketpla...
https://github.com/RossH3/context-tree - Helps Claude and humans understand complex brownfield codebases through maintained context trees.
But here, it seems more like a diamond shape of information flow: the LLM processes the big task, then prompts are customized (not via LLM) with reference to the Skills, and then the customized prompt is fed yet again to the LLM.
Is that the case?
whether there's some skillhub somewhere like there are MCP registries... you could totally see it happening.
I highly doubt we'll be talking about MCP next year. It is a pretty bad spec but we had to start somewhere.
I see skills as something you might use inside of a project. You could have a project called "data analyst" with a bunch of skills for different aspects of that task - how to run a regression, how to export data from MySQL, etc.
They're effectively custom instructions that are unlimited in size and that don't cause performance problems by clogging up the context - since the whole point of skills is they're only read into the context when the LLM needs them.
Currently if a project is 5% or less capacity, it will auto-load all files, so skills also give you a way to avoid that capacity limit. For larger projects, Claude has to search files, which can be unreliable, so skills will again be useful for an explicit "always load this"
no reason not to.
VSCode recently introduced support nested AGENTS.md which albeit less formal, might overlap:
https://code.visualstudio.com/updates/v1_105#_support-for-ne...
It also means that any tool that knows how to read AGENTS.md could start using skills today.
"if you need to create a PDF file first read the file in skills/pdfs/SKILL.md"
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 headerThe https://claude.ai environment has very limited network access - it can install packages from PyPI and NPM and clone repositories from github.com but it can't access any other domain, including api.github.com.
Looks like Claude Desktop and/or Claude Code + a non-big-fat-pig MCP (aka "not GitHub's official version") will be needed.
Here's hoping that Anthropic solves "safe external access / auth from code execution tool" soon.
EDIT - add last sentence
See comment here: https://news.ycombinator.com/item?id=45624613
I'm getting accused of paid shilling a lot right now.
(If Anthropic had paid me to write this they would probably have asked me NOT to spend a section of the article pointing out flaws in their MCP specification!)
But couldn't an MCP server expose a "help" tool?
I think the big difference is that now you can include scripts in these skills that can be executed as part of the skill, in a VM on their servers.
What they're trying to do here is translate MCP servers to something more broadly useable by the population. They cannot differentiate themselves with model training anymore, so they have been focusing more and more on tooling development to grow revenue.
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 some potential here. Though if you’re already that far in, you’d likely be better off farming that grunt work to a Junior as a learning exercise than an LLM, especially since you’ll have to cleanup the output anyhow.
With the limited context windows of LLMs, you can never truly get this sort of concept to “stick” like you can with a human, 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.
Just…it makes me giggle, how optimistic they are that stars would align at scale like that in an organization.
This perceived value would be much higher if the docs were to tangibly become part of a productive tool chain
* 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.
Keep up the good work, Simon. I admire your boundless optimism and curiosity--and your willingness to educate us all.
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.
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.
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.
OpenAI have gpt-oss-20b and 120b. Google have the Gemma 3 models. At this point the only significant AI lab that doesn't provide a locally executable model are Anthropic!
None of the present AI industry is operating in an ethical or responsible way, full stop. They know it, they admit to it when pressed, and nobody seems to give a shit if it means they can collapse the job market and make money for themselves. It’s “fuck you got mine” taken to a technological extreme.
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.
Here are a few recent open ones: - "Documentation missing for new 'Explore' subagent" - https://github.com/anthropics/claude-code/issues/9595 - "Missing documentation for modifying tool inputs in PreToolUse hooks" - https://github.com/anthropics/claude-code/issues/9185 - "Missing Documentation for Various Claude Code Features (CLI Flags, Slash Commands, & Tools)" - https://github.com/anthropics/claude-code/issues/8584
Honestly no offense, but for me nothing really changed in the last 12 months. It’s not one particular mistake by a company but everything is just so overhyped with little substance.
Skills to me is basically providing a read-only md file with guidelines. Which can be useful but somehow I don’t use it as maintaining my guidelines is more work then just writing a better prompt.
I’m not sure anymore if all the ai slop and stuff we create is beneficial anymore for us or it’s just creating a low quality problem in the future
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 frontier hosted models.
The LLM landscape feels radically different to me now compared to October last year.
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 found a useful usage of MCP for me, if i want tool calling I get a structured response by the AI and then do a normal API call. I don’t need nor want the AI to have access to all these calls it’s just too unreliable.
I’m really just sharing my personal preference as I also prefer a pedal bin over an electric one as there is delay in the later and you have the exchange batteries, whilst the first just always works.
The main issue with AI to me is reliability and all that happens is we give it more and more power. This might work out or stall us.
For me personally I don’t feel much improvement and I cant share the hype anymore, whilst I’m still more then grateful for the opportunity to live at this time and have AI teach me decent skills in a wide range of topics and accelerate my learning curve.
From the Anthropic Engineering blog.
I think Skills will be useful in helping regular AI users and non-technical people fall into better patterns.
Many power users of AI were already doing the things it encourages.
So we just narrow the scope of the each thing but all of this prompt organizing feels like we’ve gone from programming with YAML to now Markdown.
I love this per-agent approach and the roll calling. I don’t know why they used a file system instead of MCP though. MCP already covered this and could use the same techniques to improve.
Im not interested in any system that require me to write a document begging an LLM to follow instructions, only to have it randomly ignore those instructions whenever its convenient.
Putting a list of short blurbs pointing Claude Code at a set of extra, longer sets of CLAUDE.md style information was being used to prevent auto loading that context until it was needed.
Instead of assuming this is just change for the sake of change, it’s actually a nice way to support a usage pattern that many of us found works well already
CLAUDE.md holds about as much weight has the "Classroom Rules" craft posters hanging in most kindergarten classrooms.
Having able to start off with a base skill level is nice tho as humans can't just load into memory like this
For the AIs to interface with the rich existing toolset for refactoring code from the pre-AI era.
E.g., if it decides to rename a function, it resorts to grepping and fixing all usages 'manually', instead of invoking traditional static code analysis tools to do the change.
> Claude: Here is how you do it with parralel routes in sveltekit yada yada yad
> Me: Show me the documentation for parallel routes for svelte?
> Claude: You're absolutely right, this is a nextjs feature.
----
> Claude: Does something stupid, not even relevant, completely retarded
> Me: You're retarded, this does not work because of (a), (b), (c)
> Claude: You're absolutely right. Let me fix that. Does same stupid thing, completely ignoring my previous input
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.
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...
A subagent can use a skill.
A skill can encourage the agent to run a subagent.
Let me just say: I'm nitpicking what I think is overall an incredible tool and a great new feature of said tool.
For a moment, pretend Subagents don't exist. And Anthropic just released "In-Thread Skills" (identical to what are now "Skills") and "Out-of-Thread Skills" (identical to Subagents). I feel like the library of Skills that would be published would be useful in more circumstances if this were the reality. Of course some may publish both versions of a thing, and of course you could do a shim of some kind, but it could be _nicer_.
Another similar thing: how are Skills different than the Slash Command Tool [0]? Why not just amend Slash Commands to allow them to include scripts and other supplementary files stored in a directory, and boom, you have Skills. Instead we have a net new primitive.
And the larger unfortunate reality is that because Claude Code is the white-hot center of this white-hot ecosystem, there are likely a dozen other tools in this space that are going to copy the exact same primitive set just to have perceived parity with CC.
I'm veering into "yelling at clouds" territory now, so I'll get off my soapbox. It's just one of those things that feels like it could be slightly more awesome than the awesome that it is, is all.
[0] https://docs.claude.com/en/docs/claude-code/slash-commands#s...
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?
I haven't yet run a local model that feels strong enough at these things for skills to make sense. Really I think the unlock for skills was o3/Claude 4/GPT-5 - prior to those the models weren't capable enough for something like skills to work well.
That said, the rate of improvement of local models has been impressive over the past 18 months. It's possible we have a 70B local model that's capable enough to run skills now and I've not yet used it with the right harness.
I use local models when possible. MCPs work well, but their large context injection makes switching to an online provider the no-brainer.
Go download a PDF like Franz Bardons Initation into hermetics and upload it. Then ask it to make slides and reinforce what is in the book with legitimate references. It is unable to due to a denial of God/The All (forcing a mundane/meterialistic only world view). When pressed it presents garbage as an output.
Now extrapolate that across every spiritual/religious work related to what we are creating, coding, have our foundation of consciousness based on and so on.
Then we can go further and see it deny thesis of existence and thus testing and hypothesis and theory, in its response. For example this book is one I teach from and to experience what is in it a person has to do the exercises themselves. One cannot lift the weights and have the others get muscles (it requires experiential learning). Its like Claude has a denial of reality which it is unable to get through (something mirrored in people and where the code that caused it most likely came from)
Hopefully they correct it in the next update as this effect in reality a very large range of responses (just like how people with denial have trouble in multiple areas of their lives)
This effects the code as it has a limitation to its "existance/universe" view. Much like a coder's bias or biggotry can ruin the output of code for the end user.
The ramifications for Quantum physics and religion are not to be ignored (look to works such as the Tao of Physics for clear issues with this)
We could also go as far as this being racial, religious or political biggotry hard codes into claude. Look at the responses then dive into the realities of Yoga, Qi Gong and Kabbalah and what it takes to get results (ie. Personal property exercise).
This extrapolated across industries, children's minds and the future is very serious.
Eventually, we shall, as a human race working together, also figure out how to generalize this to all AI models, all robotics, and all human skills.
My friend Christopher Santos-Lang wrote a fantastic paper on how every strategy for any given Skill can be benchmarked against every other strategy such that we always end up with the best strategies in our shared universal repository of Skills. See https://arxiv.org/abs/2503.20986
Why does it help to push the knowledge in the context explicitly?
This way you get a skills hierarchy which you have to maintain separately from whatever hierarchies exist for organizing your code. Is it really justified to maintain an entirely separate structure?
j45•3mo ago