Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Skills Officially Comes to Codex

developers.openai.com

Post reply on HN
Print view View original

21–30 of 133 posts

Re: Skills Officially Comes to Codex

#21

Post by coldtea »

mikaelaast wrote: post #8

Are we sure that unrestricted free-form Markdown content is the best configuration format for this kind of thing? I know there is a YAML frontmatter component to this, but doesn't the free-form nature of the "body" part of these configuration files lead to an inevitably unverifiable process? I would like my agents to be inherently evaluable, and free-text instructions do not lend themselves easily to systematic evalu…

>doesn't the free-form nature of the "body" part of these configuration files lead to an inevitably unverifiable process?

The non-deterministic statistical nature of LLMs means it's inherently an "inevitably unverifiable process" to begin with, even if you pass it some type-checked, linted, skills file or prompt format.

Besides, YAML or JSON or XML or free-form text, for the LLM it's just tokens.

At best you could parse the more structured docs with external tools more easily, but that's about it, not much difference when it comes to their LLM consumption.

Re: Skills Officially Comes to Codex

#22

Post by greymalik »

rdli wrote: post #18

This is great. At my startup, we have a mix of Codex/CC users so having a common set of skills we can all use for building is exciting. It’s also interesting to see how instead of a plan mode like CC, Codex is implementing planning as a skill.

I’m probably missing it, but I don’t see how you can share skills across agents, other than maybe symlinking .claude/skills and .codex/skills to the same place?

Re: Skills Officially Comes to Codex

#23

Post by coldtea »

mikaelaast wrote: post #12
Etheryte wrote: post #9

Earlier quoted context omitted.

The modern state of the art is inherently not verifiable. Which way you give it input is really secondary to that fact. When you don't see weights or know anything else about the system, any idea of verifiability is an illusion.

Sure. Verifiability is far-fetched. But say I want to produce a statistically significant evaluation result from this – essentially testing a piece of prose. How do I go about this, short of relying on a vague LLM-as-a-judge metric? What are the parameters?

Would a structured skills file format help you evaluate the results more?

Re: Skills Officially Comes to Codex

#25

Post by Frost1x »

andybak wrote: post #20

Skills, plugins, apps, connectors, MCPs, agents - anyone else getting a bit lost?

In my opinion it’s to some degree an artifact of immature and/or rapidly changing technology. Basically not many know what the best approach is, all the use cases aren’t well understood, and things are changing so rapidly they’re basically just creating interfaces around everything so you can change flow in and out of LLMs any way you may desire.

Some paths are emerging popular, but in a lot of cases we’re still not sure even these are the long term paths that will remain. It doesn’t help that there’s not a good taxonomy (that I’m aware of) to define and organize the different approaches out there. “Agent” for example is a highly overloaded term that means a lot of things and even in this space, agents mean different things to different groups.

Re: Skills Officially Comes to Codex

#29

Post by rdli »

greymalik wrote: post #22
rdli wrote: post #18

This is great. At my startup, we have a mix of Codex/CC users so having a common set of skills we can all use for building is exciting. It’s also interesting to see how instead of a plan mode like CC, Codex is implementing planning as a skill.

I’m probably missing it, but I don’t see how you can share skills across agents, other than maybe symlinking .claude/skills and .codex/skills to the same place?

Nothing super-fancy. We have a common GitHub repo in our org for skills, and everyone checks out the repo into their preferred setup locally.

(To clarify, I meant that some engineers mostly use CC while others mostly use Codex, as opposed to engineers using both at the same time.)

Post reply on HN