Support for SKILL.md files

[carterworks]

What feature would you like to see?

https://www.anthropic.com/engineering/equipping-agents-for-the-real-world-with-agent-skills

Of course, I can just tell codex to read the SKILL.md file, but a more automatic indexing of the name and description from the frontmatter would be nice, too.

Additional information

At its simplest, a skill is a directory that contains a SKILL.md file. This file must start with YAML frontmatter that contains some required metadata: name and description. At startup, the agent pre-loads the name and description of every installed skill into its system prompt.

This metadata is the first level of progressive disclosure: it provides just enough information for Claude to know when each skill should be used without loading all of it into context. The actual body of this file is the second level of detail. If Claude thinks the skill is relevant to the current task, it will load the skill by reading its full SKILL.md into context.

As skills grow in complexity, they may contain too much context to fit into a single SKILL.md, or context that’s relevant only in specific scenarios. In these cases, skills can bundle additional files within the skill directory and reference them by name from SKILL.md. These additional linked files are the third level (and beyond) of detail, which Claude can choose to navigate and discover only as needed.
…
Skills can also include code for Claude to execute as tools at its discretion.

[patrickp2]

Right now codex cli lacks the ability to encapsulate a 'skill' into it's own context. Currently the industry have solved this with sub agents, or Claudes recent 'skills' addition.

Say I have an agent that I want to access various analytic tools like Google Analytics, Google Search Console, Git etc. Right now there are a few ways to allow codex cli to have do this. I can:

• Add them as mcps (with full api wrapper), but this pollutes the context when not all requests need to use these features
• Add api wrappers as code that the cli can run. This works but unfortunately once pulled into the main context it persists there. It's also a bit slower because codex will need to take many steps to understand how to achieve this goal.
• Create MCP's that are coordinators/sub agents of their own that then use their an agent workflow + tools to achieve access to the api. E.g. I can use an MCP that takes in an analytics question then uses an OpenAI Agents SDK workflow to make the API requests and return the output back to codex cli. This works great but involves a separate API key, development etc, so it's not optimal.

The optimal solution would be a native way to separate context for domain specific tasks (e.g. sub agents / skills). That way I can hand over a question to a domain specific sub agent or skill feature, and it can complete the request without bloating context, and it's easy to develop, while also not needed external api keys / agent sdks.

Would love to see this in codex cli!

[obra]

I put together a first prototype of a Codex CLI bootstrap for skills today. It requires adding a couple of lines to AGENTS.md, but GPT5-Codex really likes to follow instructions. ;)

https://blog.fsck.com/2025/10/27/skills-for-openai-codex/

[dave1010]

I made a tool and GitHub Action that does something similar, automatically compiling the skills and adding them to AGENTS.md, for use by any agent: https://github.com/dave1010/skills-to-agents

skills-to-agents is effective, even if it's not the optimal solution of having first class support for Skills in Codex.

More info: https://dave.engineer/blog/2025/11/skills-to-agents/

[mahdialibi]

Here another claude-to-codex skills

https://www.robert-glaser.de/claude-skills-in-codex-cli/