Codex Skills in Practice

Codex skills are small instruction packs that teach Codex how to do a specific kind of work. They are not magic plugins. A skill is closer to a documented workflow: when the task matches the skill, Codex reads the instructions and follows the steps.

That distinction matters. A good skill does not replace judgment. It reduces repeated explanation.

In this post, I will use a real example: asking Codex to add a visual asset to a blog post.

The example request

Imagine I am writing a post about deploying a Hugo site to Cloudflare Pages. I want a hero image that looks like a clean dashboard screenshot, but I do not want to design it by hand.

The request could be:

Create a clean hero image for this post about Cloudflare Pages.
Save it in the repo and reference it from the Markdown file.

Without a skill, Codex has to infer the workflow from scratch. Should it create SVG? Should it call an image tool? Should it edit the Markdown first? Should it ask a follow-up question?

With a skill, the path is more direct.

The important part is that Codex announces the skill it is using and why. In this case, the task needs a bitmap-style visual asset, so the image generation skill is a good fit.

What the skill contributes

A useful skill usually answers four questions:

• When should this workflow be used?
• What files or tools should Codex prefer?
• What should Codex avoid?
• What should the final output look like?

For image work, the skill might say:

• use the image generation tool for raster images
• reuse existing assets when the repo already has them
• do not use the image tool for code-native SVG or icons
• after generation, do not add unnecessary commentary

Those rules sound small, but they remove ambiguity. Codex can spend more effort on the actual task instead of deciding the basic operating procedure.

The workflow

Here is the practical flow I expect:

First, Codex reads the request. Then it checks whether any available skill clearly matches the work. If a skill applies, Codex opens the skill instructions, follows the workflow, edits the repo, and verifies the result.

The user does not need to mention the skill every time. If the task clearly matches, Codex can pick it. But naming the skill can help when the request is broad:

Use the imagegen skill to create a diagram for this article.

That is especially useful when multiple approaches are possible.

What makes a good skill

A good skill is narrow. It should not say “be better at frontend work” or “write high quality code”. Those are goals, not workflows.

A good skill says something like:

When creating a new blog illustration, first inspect the existing image style.
Prefer assets under static/images/posts/<slug>/.
Use concise alt text.
Reference the image from the Markdown post.
Verify that the final path works in Hugo.

That is concrete. It tells Codex where to look, where to write, and what quality check matters.

Where skills help most

Skills are most useful for work that repeats:

• creating blog images
• writing release notes
• adding test fixtures
• generating API client examples
• preparing incident reports
• scaffolding a known project structure

They are less useful for one-off reasoning tasks. If I ask, “Why is this Go program deadlocking?”, I want Codex to read the code and reason from the facts. A skill may still help with debugging style, but it should not force a checklist onto a problem that needs investigation.

A realistic before and after

Before a skill, I might write:

Create an image for the article. It should match the existing site style.
Put it in static/images/posts/cloudflare-pages/.
Use SVG only if it is a diagram. Otherwise use a generated bitmap.
Update the Markdown and make sure the path is correct.

After a skill, I can write:

Add a demonstration image to this article.

The second request works because the repeated context lives in the skill.

The main lesson

Codex skills are useful when they encode local taste and repeated process. They are not a substitute for reading the repo. The best skills make Codex more consistent by giving it a good default path.

My rule of thumb:

If I have explained the same workflow three times, it probably deserves a skill.

Start small. Write one skill for one workflow. Let it earn its place by saving you from repeating instructions.