On July 23, 2026, OpenAI turns Skills on by default for every Enterprise ChatGPT workspace. It’s a big rollout, and it’s easy to read as another round in the model war: whichever company packages a reusable instruction set best wins the quarter. That reading misses what’s actually happening. OpenAI isn’t shipping a rival to Anthropic’s Agent Skills. It’s adopting the same open format Anthropic published in December 2025, the one that already runs across Claude Code, Cursor, Gemini CLI, and dozens of other tools. The packaging war didn’t have a winner. It just ended.
That should change how you think about the AI skills your team is building right now. A skill’s value was never about which harness ran it. It’s about whether the person who wrote it actually knew what they were doing, and got that judgment down before moving on to the next task. Skills are still harnessed. Just not to a tool anymore.
The packaging war is over
Anthropic shipped Claude Skills on October 16, 2025: folders of instructions, scripts, and reference material that Claude could load into a task on demand. Two months later, Anthropic did something more consequential than the feature itself. It opened the format as a public standard, so any AI harness could read the same file.
The adoption curve moved fast:
- October 2025: Claude Skills launches across Claude.ai, Claude Code, and the API.
- December 2025: Anthropic publishes Agent Skills as an open, cross-platform standard.
- May 2026: a single install command already supports the format across more than 40 agent harnesses, including Cursor, Codex, and Gemini CLI.
- July 23, 2026: OpenAI turns Skills on by default for every Enterprise ChatGPT workspace, running on that same open format.
Ten months from one company’s feature to an industry default. If you were betting on packaging as your moat, that bet is over. A skill written for Claude Code now runs, unmodified, in Cursor, Codex, or ChatGPT. The container stopped being a competitive question.
From one company's feature to an industry default in under ten months.
What a portable file doesn’t fix
Portability answers one question: can the same file run in more than one place? It says nothing about whether the file is any good.
Even the standard’s own documentation admits as much: the format “adds value only when skills need to cross tool or team boundaries.” One review of thousands of published skills found roughly one in eight had critical issues: missing edge cases, broken assumptions, instructions that worked in the demo and nowhere else. None of that is a packaging failure. A universal container holding a thin, half-finished instruction set is still thin and half-finished. It just fails the same way on every harness now, instead of failing quietly on just one.
A May 2026 paper on automated skill generation put it plainly: actionable knowledge tied to a person or role usually lives in messy, heterogeneous traces, not clean instructions, and there’s still no standard workflow for turning those traces into something a team can inspect, correct, and reuse. That’s not a format problem. Portability is what you get for free once you adopt a standard. It was never the hard part.
Even OpenAI is racing toward the real problem
OpenAI’s own answer to that gap is instructive, because it’s aimed at the actual bottleneck instead of the container. Codex’s Record & Replay feature, shipped June 18, 2026, lets someone demonstrate a workflow once on their Mac. Codex watches, works out what the person was trying to do, and drafts a skill from it: what the workflow is for, what inputs it needs, and how to check the result.
That’s real progress. The skill stores intent rather than a sequence of clicks, so it still works when the screen looks slightly different next time. But look at what it’s still capturing: what a person did. Not why they’d do something else if the case were slightly off. Record someone filing an expense report ten times and you’ll get a skill that files expenses. You won’t get the exception where it needs a manager’s sign-off first, unless that exact case happened to occur during the recording.
That’s not a knock on OpenAI. It’s the honest shape of the problem. Even a company racing to solve capture, from inside a model lab, with a screen-recording tool built for exactly this purpose, still ends up with the what and not the why. Getting the why means asking the question the recording can’t ask: what would you have done differently here, and when. And if the model running the recording happens to be sharp enough to guess right on its own, nobody will notice the gap until the workflow moves to a harness that guesses wrong.
The skill was never about the harness
That’s why the packaging war ending changes the argument instead of settling it. A skill’s value was never harnessed to the tool that happened to run it. It’s harnessed to whoever wrote it, and to how much of their actual judgment they got down before moving on to the next task.
Here’s the part that’s easy to miss. A skill can look complete for months without anyone writing its judgment calls down anywhere, because the harness running it quietly covers for the gap. A capable model reasons its way past the exception even though the file never mentions it. Nobody edits the skill, because nothing visibly breaks. That isn’t evidence the knowledge got captured. It’s evidence the harness was doing the capturing’s job in real time, invisibly, on every run, and taking that judgment with it the moment the skill moves anywhere else.
That’s the part portability doesn’t protect. Move the same file to a different harness, a different model underneath, a different set of defaults and guardrails, and the exception that used to get handled just stops happening. The file didn’t change. What the previous harness was quietly covering for did. The question worth asking about any skill your team runs today isn’t whether the file would survive a move to a new harness. It’s whether the judgment behind it would.
The fix isn’t a smarter harness. It’s writing the actual reasoning down, the exception itself and why it applies, so the skill doesn’t depend on whichever harness happens to be sharp enough to infer it this time. That’s different work than writing the skill in the first place. It means asking why the exception exists, not just noting that it exists, and getting the answer into the file before the harness that used to quietly cover for it is gone.
We’ve made versions of this argument before. That general-purpose agents miss the reasoning that matters most because they assume they already understand the domain (Why Knowledge Capture Fails). This is the skills-shaped version of the same point.
The file didn't change. What the last harness was covering for did.
What this changes for an AI portfolio right now
For a Chief AI or VP AI running a portfolio of AI projects, the practical shift is where you spend your evaluation time. Stop scoring vendors and harnesses on which one has the best skill system. That axis is converging to parity, quickly, across the whole industry, and it’ll keep converging every time another lab adopts the same open standard.
Spend that time instead on the question the packaging layer can’t answer: does your organization have a repeatable way to get real judgment out of your best people and written down somewhere durable, something a new hire can read, a reviewer can audit, and that still works after the next harness ships? If the honest answer is a folder of prompts someone wrote once, that’s the gap worth closing, regardless of which harness ends up running the result.
The container got solved for you, for free, this week. What’s inside it is still entirely your problem.