Live data from Hacker News

Skills Officially Comes to Codex

developers.openai.com

101–110 of 133 posts

Re: Skills Officially Comes to Codex

#101
post #86

People are really misunderstanding Skills, in my opinion. It's not really about the .md file. It's about the bundling of code and instructions. Skills assume a code execution environment.

You could already pre-approve an executable and just call that from your prompt. The context savings by adding/indexing metadata and dynamically loading the rest of the content as-needed is the big win here IMHO.

Re: Skills Officially Comes to Codex

#102

I already was doing something similar on a regular basis. I have many "folders"... each with a README.md, a scripts folder, and an optional GUIDE.md. Whenever I arrive at some code that I know can be reused easily (for example: clerk.dev integration hat spans frontend and backend both), I used to create a "folder" of the same. When needed, I used to just copy-paste all the folder content using my https://www.npmjs.co…

For some reason, what you said here just explains what skills are in an eil5 way that I finally can understand

Re: Skills Officially Comes to Codex

#103
post #84
post #72

Earlier quoted context omitted.

There’s nothing super special about it, it’s just handy if you have some instructions that you don’t need the AI to see all the time, but that you’d like it to have available for specific things. Maybe you have a custom auth backend that needs an annoying local proxy setup before it can be tested—you don’t need all of those instructions in the primary agents.md bloating the context on every request, a skill would let…

Thanks. I think I could use skills as "instructions I might need but I don't want to clutter AGENTS.md with them".

Yes exactly. Skills are just sub agents.md files + an index. The index tells the agent about the content of the .md files and when to use them. Just a short paragraph per file, so it's token efficient and doesn't take much of your context.

Poor man's "skills" is just manually managing and adding different .md files to the context.

Importantly every time you instruct the agent to do something correctly that it did incorrectly before, you ask it to revise a relevant .md file/"skill", so it has that correction from now on. This is how you slowly build up relevant skills. Things start out as sections in your agents.md file, and then graduate to a separate file when they get large enough.

Re: Skills Officially Comes to Codex

#104

Earlier quoted context omitted.

but that's same for MCP and tools, no?

Yes. Infact you can serve each Skill as a tool exposed via MCP if you want. I did the same to make Skills work with Gemini CLI (or any other tool that supports MCP) while creating open-skills. 1. Open-Skills: https://github.com/BandarLabs/open-skills

Interesting. Skills on MCP makes a lot of sense in some contexts.

Re: Skills Officially Comes to Codex

#105
This seems great and all, but to my surprise the default $plan skill in Codex prefers to writing plan files to ~/.codex/plans. Is this intentional, or an idiosyncrasy of my particular instance of Codex? Every agent tool I've ever seen before puts planning documentation in the repo folder itself, not in a global user directory. Why this weird decision?

Re: Skills Officially Comes to Codex

#106
post #63

Something that’s under-emphasized and vital to understand about Skills is that, by the spec, there’s no RAG on the content of Skill code or markdown - the names and descriptions in every skill’s front-matter are included verbatim in your prompt, and that’s all that’s used to choose a skill. So if you have subtle logic in a Skill that’s not mentioned in a description, or you use the skill body to describe use-cases no…

Honestly the index seems as much a liability as a boon. Keeping the context clean and focused is one of the most important things for getting the best out of lmms. For now I prefer just adding my md files to the context whenever I deem them relevant.

Skills are much simpler than mcps, which are hopelessly overengineered, but even skills seem unnecessarily overengineered. You could fix the skill index taking up place in the context, by just making it a tool available to the agent (but not an mcp!).

Re: Skills Officially Comes to Codex

#107
post #97
post #89

I don't understand how skills are different than just instructing your model to read all the front-matters from a given folder on your filesystem and then decide if they need to read the file body.

That is basically what it is tho. One difference is the model might have been trained/fine-tuned to be better at "read all the front-matters from a given folder on your filesystem and then decide..." compared a model with those instructions only in its context. Also, does your method run scripts and code in any kind of sandbox or other containment or do you give it complete access to your system? #yolo

Not my method really, just a comparison. I didn't know about the sandbox.

I see there might be advantages. The manual alternative could be tweaked further though. For example you might make it hierarchical.

Or you could create an "howTo" MCP with more advanced search capabilities. (or a grandma MCP to ask advice to after a failure)

Interesting topic, I guess has found a real best practice, everybody is still exploring.

Re: Skills Officially Comes to Codex

#108
post #45

Earlier quoted context omitted.

Skills are the matrix scene where neo learns kungfu. Imagine they are a database of specialized knowledge that can an agent can instantly tap into _on demand_. The key here is “on demand”. Not every agent or convention needs to know kung fu. But when they do, a skill is waiting to be consumed. This basic idea is “progressive disclosure” and it composes nicely to keep context windows focused. Eg i have a metabase skil…

Could you explain more about your metabase skill and how you use it? We use metabase (and generally love it) and I’m interested to hear about how other people are using it!

Its really just some rules around auth, some precached lookups (eg databases with ids and which to use), and some explanations around models and where to find them. Everything else it pretty much knows on it own.

Re: Skills Officially Comes to Codex

#109
post #84
post #72

Earlier quoted context omitted.

There’s nothing super special about it, it’s just handy if you have some instructions that you don’t need the AI to see all the time, but that you’d like it to have available for specific things. Maybe you have a custom auth backend that needs an annoying local proxy setup before it can be tested—you don’t need all of those instructions in the primary agents.md bloating the context on every request, a skill would let…

Thanks. I think I could use skills as "instructions I might need but I don't want to clutter AGENTS.md with them".

Yes but also because skills are a semi special construct, agents are both better at leveraging them when needed and you can easily tap into them explicitly (eg “use the PR skill to open a PR”)

Re: Skills Officially Comes to Codex

#110
post #34

one thing that I am missing from the specification is a way to inject specific variables into the skills. If I create let's say a postgres-skill, then I can either (1) provide the password on every skill execution or (2) hardcode the password into my script. To make this really useful there needs to be some kind of secret storage that the agent can read/write. This would also allow me as a programmer to sell the skil…

I have no clue how you’re running your agents or what you’re building, but giving the raw password string to a the model seems dubious? Otherwise, why not just keep the password in an .env file, and state “grab the password from the .env file” in your Postgres skill?

That’s exactly what I do.
Post reply on HN