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.
Skills Officially Comes to Codex
101–110 of 133 posts
Re: Skills Officially Comes to Codex
#102I 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…
Re: Skills Officially Comes to Codex
#103Earlier 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".
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
#104Earlier 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
Re: Skills Officially Comes to Codex
#105Re: Skills Officially Comes to Codex
#106Something 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…
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
#107I 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
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
#108Earlier 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!
Re: Skills Officially Comes to Codex
#109Earlier 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".
Re: Skills Officially Comes to Codex
#110one 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?