The Skill You Wrote for Claude Code Now Runs in Codex Too. Agent Skills Quietly Became a Portable Standard — Here's the Build-vs-Lock-In Call.
A skill you write for Claude Code (a folder with a SKILL.md, some instructions, maybe a script or two) now runs inside OpenAI's Codex. Same format. Codex loads Agent Skills in its CLI, its IDE extension, and its app, and OpenAI maintains an official catalog of them. The format Anthropic introduced for Claude became the thing everyone builds against.
That sounds like a boring interoperability update. For a solo operator, it's actually a decision point about where you put your time, because the hours you spend encoding a workflow into a skill just stopped being a bet on one vendor.
What a skill is, and why portability changes the math
An Agent Skill is a small, self-contained package: a markdown file that tells the agent how to do a specific job, plus optional scripts and resources it can call. Think of it as a repeatable procedure you hand the agent instead of re-explaining every session: "here's exactly how we deploy," "here's how we format a client report," "here's the checklist for a new post."
Until recently, that procedure was locked to whichever agent you wrote it for. Write it for Claude, and switching to Codex meant rewriting it. That lock-in was quiet but real: the more workflow you encoded into one vendor's format, the more it cost to leave.
Now the same skill loads in both. For someone running a one-person shop, that's the first time your tooling investment survives a vendor switch. If Codex ships a cheaper plan next quarter, or Claude regresses on the model you rely on, your accumulated workflows come with you. You're moving a config, not rebuilding your process.
I've felt the other side of this. I have skills I built early that are effectively welded to one agent, and every time I consider switching I do the math on re-encoding them and stay put. That's lock-in doing its job. A portable format removes that particular tax.
The part nobody's putting in the announcement
A portable skill format is also a portable attack surface.
A skill can carry scripts. When an agent loads one, it's loading instructions, and potentially code, that will run with your agent's permissions, against your repo, with your credentials in the environment. The same standardization that lets your skill run everywhere lets a malicious skill run everywhere too. This isn't hypothetical: fake skills have already slipped past scanners, and "it passed the marketplace check" is not the same as "it's safe."
The failure mode is familiar to anyone who's watched npm. A useful-looking package, a postinstall script, a CI runner with cloud credentials in scope, and now the thing you installed to save an afternoon is exfiltrating secrets. Skills are npm packages for your agent's behavior, and they run in a context that usually has more access than a random dependency does.
So treat them like dependencies you actually audit. Read the skill before you install it. It's a markdown file and a couple of scripts, this takes minutes. Pin versions instead of pulling latest. Be especially wary of anything that wants to run shell commands or touch credentials. The convenience of a giant skill marketplace is real, and so is the cost of installing thirty things you never read.
The build decision
Here's where I land for a solo operator: write skills for the handful of workflows you actually repeat, and don't build a "skills platform."
The workflows worth encoding are the ones you do weekly and do the same way each time: your deploy sequence, your content formatting, your client-onboarding checklist, your test-and-lint pass. Those are worth the 30 minutes to turn into a skill, because you'll run them a hundred times and now they survive a vendor change.
What's not worth it is treating skills as a product surface: building elaborate skill hierarchies, publishing a marketplace, over-engineering something that's meant to be a repeatable note with a script attached. The value is in the boring, personal automation, not in the infrastructure around it.
And write your own for anything sensitive. The five skills that touch your deploys and your credentials should be five files you wrote and understand, not five installs from a catalog. Save the marketplace for the low-stakes stuff.
The honest take
I could be wrong about how durable this portability is. "Standard adopted across vendors" has a way of fracturing the moment one vendor decides differentiation matters more than interoperability. OpenAI and Anthropic are competitors, and a format that's identical today can grow vendor-specific extensions that quietly re-lock you. If Codex skills start depending on Codex-only features, the portability I'm celebrating gets thin fast.
But even discounting for that, the direction is good for the little guy. For most of the last two years, the agent tooling you built was a hostage to your vendor choice. Right now, today, a skill you write runs in more than one place, and that's a hedge you didn't have last quarter.
Use it deliberately. Encode the five workflows you repeat, write the sensitive ones yourself, audit anything you install like it's a dependency with root (because it roughly is) and skip the urge to build a platform. The whole point of a portable skill is that it's small enough to move and simple enough to read. Keep it that way.
Author
Lukas
@lukcombinator