alt Hacker NewsOpenAI are quietly adopting skills, now available in ChatGPT and Codex CLI
Comments
It’s crazy how Anthropic keeps coming up with sticky “so simple it seems obvious” product innovations and OpenAI plays catch up. MCP is barely a protocol. Skills are just md files. But they seem to have a knack for framing things in a way that just makes sense.
A public warning about OpenAI's Plus chat subscription as of today.
They advertise 196k tokens context length[1], but you can't submit more than ~50k tokens in one prompt. If you do, the prompt goes through, but they chop off the right-hand-side of your prompt (something like _tokens[:50000]) before calling the model.
This is the same "bug" that existed 4 months ago with GPT-5.0 which they "fixed" only after some high-profile Twitter influencers made noise about it. I haven't been a subscriber for a while, but I re-subscribed recently and discovered that the "bug" is back.
Anyone with a Plus sub can replicate this by generating > 50k tokens of noise then asking it "what is 1+1?". It won't answer.
[1] https://help.openai.com/en/articles/11909943-gpt-52-in-chatg...
I had a bunch of fun writing about this one, mainly because it was a great excuse to highlight the excellent news about Kākāpō breeding season this year.
(I'm not just about pelicans.)
I'm not sure if I have the right mental model for a "skill". It's basically a context-management tool? Like a skill is a brief description of something, and if the model decides it wants the skill based on that description, then it pulls in the rest of whatever amorphous stuff the skill has, scripts, documents, what have you. Is this the right way to think about it?
From a purely technical view, skills are just an automated way to introduce user and system prompt stuffing into the context right? Not to belittle this, but rather that seems like a way of reducing the need for AI wrapper apps since most AI wrappers just do systematic user and system prompt stuffing + potentially RAG + potentially MCP.
This is great that Codex CLI is adding skills - but it would be far more useful if the CLI looked first in the project (the directory where I've launched codex) `.codex/skills` directory and THEN the home directory .codex dir. The same issue exists for prompts.
This is a clever abstraction. Reminds me of how tool_use worked in earlier Claude versions - defining a schema upfront and letting the model decide when to call it.
Has anyone tested how well this works with code generation in Codex CLI specifically? The latency on skill registration could matter in a typical dev workflow.
@simonw Thank you for always setting alt text in your images. I really appreciate it.
If anyone wants to use skills with any other model or tool like Gemini CLI etc. I had created open-skills, which lets you use skills for any other llm.
Caveat: needs mac to run
Bonus: it runs it locally in a container, not on cloud nor directly on mac
1. Open-Skills: https://GitHub.com/BandarLabs/open-skills
we just released Anthropic's Skills talk for those who want to find more info on the design thinking / capabilities: https://www.youtube.com/watch?v=CEvIs9y1uog&t=2s
This is killing me with complexity. We had agents.md and were supposed to augment the context there. Now back to cursor rules and another md file to ingest.
I think the future is likely one that mixes the kitchen-sink style MCP resources with custom skills.
Services can provide an MCP-like layer that provides semantic definitions of everything you can do with said service (API + docs).
Skills can then be built that combine some subset of the 3rd party interfaces, some bespoke code, etc. and then surface these more context-focused skills to the LLM/agent.
Couldn’t we just use APIs?
Yes, but not every API is documented in the same way. An “MCP-like” registry might be the right abstraction for 3rd parties to expose their services in a semantic-first way.
Is there a fundamental difference between a skill and a tool or could I just make a terse skill and have that be used in the same way as a tool?
This is nice, but that it goes into its vendor specific .codex/ folder is a bit of a drag.
I hope such things will be standardized across vendors. Now that they founded the Agentic AI Foundation (AAIF) and also contributed AGENTS.md, I would hope that skills become a logical extension of that.
https://www.linuxfoundation.org/press/linux-foundation-annou...
The skills approach is great for agents and LLMs but I feel agents have to become wider in the context they keep and more proactive in the orchestration.
I have been running Claude Code with simple prompts (eg 1) to orchestrate opencode when I do large refactors. I have also tried generating orchestration scripts instead. Like, generate a list of tasks at a high level. Have a script go task by task, create a small task level prompt (use a good model) and pass on the task to agent (with cheaper model). Keeping context low and focused has many benefits. You can use cheaper models for simple, small and well-scoped tasks.
This brings me to skills. In my product, nocodo, I am building a heavier agent which will keep track of a project, past prompts, skills needed and use the right agents for the job. Agents are basically a mix of system prompt and tools. All selected on the fly. User does not even have to generate/maintain skills docs. I can get them generated and maintained with high quality models from existing code in the project or tasks at hand.
1 Example prompt I recently used: Please read GitHub issue #9. We have phases clearly marked. Analyze the work and codebase. Use opencode, which is a coding agent installed. Check `opencode --help` about how to run a prompt in non-interactive mode. Pass each phase to opencode, one phase at a time. Add extra context you think is needed to get the work done. Wait for opencode to finish, then review the work for the phase. Do not work on the files directly, use opencode
My product, nocodo: https://github.com/brainless/nocodo
> It took just over eleven minutes to produce this PDF,
Incredibly dumb question, but when they say this, what actually happens?
Is it using TeX? Is it producing output using the PDF file spec? Is there some print driver it's wired into?
Does anybody have examples of life-changing skills? I can't quite understand how they're useful, yet...
It is interesting that they are relying on visual reading for document ingestion instead of OCT. Recently I read an article which says Handwriting recognition has matured, and I'm beginning to think this is the approach they are takingwirh HAndwiting recognition.
Hasn’t ChatGPT been supporting skills with a different name for several months now through “agent”?
They gave it back then folders with instructions and executable files iirc
Does this mean I can point to a code snippet and a link to the related documentation and the coding agent refer to it instead of writing "outdated" code?
Some frameworks/languages move really fast unfortunately.
Curious if anyone has applied this "Skills" mindset to how you build your tool calls for your LLM agents applications?
Say I have a CMS (I use a thin layer of Vercel AI SDK) and I want to let users interact with it via chat: tag a blog, add an entry, etc, should they be organized into discrete skill units like that? And how do we go about adding progressive discovery?
@simonw: Any particular reason you stopped releasing "llm" regularily? I believe the last release was done in summer. Neither gpt-5.1 nor gpt-5.2 have been added. Are you about to give up on that project? Is it time to search for another one?
I also have an open issue since months, which someone wrote a PR for (thanks") a few weeks ago.
Are you still comitted to that project?
It seems to me that skills are:
1. A top level agent/custom prompt
2. Subagents that the main agent knows about via short descriptions
3. Subagents have reference files
4. Subagents have scripts
Anthropic specific implementation:
1. Skills are defined in a filesystem in a /skills folder with a specific subfolder structure of /references and /scripts.
2. Mostly designed to be run via their CLI tool, although there's a clunky way of uploading them to the web interface via zip files.
I don't think the folder structure is a necessary part of skills. I predict that if we stop looking at that, we'll see a lot of "skills-like" implementations. The scripting part is only useful for people who need to run scripts, which, aside from the now built in document manipulating scripts, isn't most people.
For example, I've been testing out Gemini Enterprise for use by staff in various (non-technical) positions at my business.
It's got the best implementation of a "skills-like" agent tool I've seen. Basically a visual tree builder, currently only one level deep. So I've set up the "<my company name> agent" and then it has subagents/skills for thing like marketing/supply chain research/sysadmin/translation etc., each with a separate description, prompt, and knowledge base, although no custom scripts.
Unfortunately, everything else about Gemini Enterprise screams "early alpha, why the hell are you selling this as an actual finished product?".
For example, after I put half a day into setting up an agent and subagents, then went to share this with the other people helping me to test it, I found that... I can't. Literally no way to share agents in a tool that is supposedly for teams to use. I found one of the devs saying that sharing agents would be released in "about two weeks". That was two months ago.
Mini rant over... But my point is that skills are just "agents + auto-selecting sub-agents via a short description" and we'll see this pattern everywhere soon. Claude Skills have some additional sandboxing but that's mostly only interesting for coders.
(Minor grammar note: "OpenAI are" -- it should say "OpenAI is" -- because "OpenAI" is a name and therefore singular.)
Welcome to the world of imitation of value and semantics.
Something important to keep in mind is the way skills work shouldn't be assumed to be the same and work in the same way.
Can or should skills be used for managing the documentation of dependencies in a project and the expertise in them?
I’ve been playing with doing this but kind of doesn’t feel the most natural fit.
Totally unrelated but what’s up with the word “quietly”? Its usage seems to have gone up 5000%, essentially overnight, as if there’s a contagion. You see the word in the New York Times, in government press releases, in blogs. ChatGPT 5.1 itself used the word in almost every single response, and no amount of custom instructions could get it to stop. That “Google Maps of London restaurants” article that’s going around not only uses the word in the headline, but also twice in the closing passage alone, for example. And now Simon, who’s an excellent writer with an assertive style, has started using it in his headlines. What’s the deal? Why have so many excellent writers from a wide range of subjects suddenly all adopted the same verbal tic? Are these writers even aware that they’re doing it?
[dead]
[dead]
It’s impressive how every iteration tries to get further from pretending actual AGI would be anywhere close when we are basically writing library functions with the worst DSL known to man, markdown-with-english.
[dead]
[dead]
LLMs need prompts. Prompts can get very big very quickly. The so called "skills", which exist in other forms in other platforms outside of Anthropic and OpenAI, are simply a mechanism to extend the prompt dynamically. The tool (scripts) that are part of the skill are no different then simply having the tools already installed in the OS where the agent operates.
The idea behind skills is sound because context management matters.
However, skills are different from MCP. Skills has nothing to do with tool calling at all!
You can implement your own version of skills easily and there is absolutely zero need for any kind of standard or a framework of sorts. They way to do is to register a tool / function to load and extend the base prompt and presto - you have implemented your own version of skills.
In ChatBotKit AI Widget we even have our own version of that for both the server and when building client-side applications.
With client-side applications the whole thing is implemented with a simple react hook that adds the necessary tools to extend the prompt dynamically. You can easily come up with your own implementation of that with 20-30 lines of code. It is not complicated.
Very often people latch on some idea thinking this is the next big thing hoping that it will explode. It is not new and it wont explode! It is just part of a suite of tools that already exist in various forms. The mechanic is so simple at its core that practically makes no sense to call it a standard and there is absolutely zero need to have it for most types of applications. It does make sense for coding assistant though as they work with quite a bit of data so there it matters. But skills are not fundamentally different from *.instruction.md prompt in Copilot or AGENT.md and its variations.