For me, Codex skills are the best way I have found to handle repetitive work. Instead of explaining a complete workflow every time I start a new task, I can call the skill and give the agent the context, sequence, and expected result.
That saves me a lot of time. It also makes the work more consistent because the important decisions are already part of the workflow.
But a skill does not mean the agent will follow every instruction perfectly. Sometimes it can miss an important part. I still review the result, and when I see a problem, I use it to improve the skill.
I work in the Codex app. OpenAI describes Codex as an AI agent available through the app, CLI, IDE, and web. In this article, I use “the agent” for the system doing the work and “Codex app” for the interface where I manage the task.
Why I wanted more than a saved prompt
A repeated task is rarely just one instruction.
My blog article creation workflow is a good example. Before the agent writes an article, I want it to review the topic bank, check what I have already written, research what people are asking, propose focused topics, interview me, create the draft, review the writing, prepare the visuals, and only then create a WordPress draft.
I could describe all of that in every new conversation. But that would take time, and I would probably explain it slightly differently each time.
A skill gives me a reusable version of the process. It stores more than background information. It stores the order of the work, the files to check, the expected outputs, and the points where the agent needs my approval.
A skill saves me from repeating the workflow. It does not save me from reviewing the result.
I create the workflow through a conversation
I do not normally start by opening a blank SKILL.md file and trying to write the whole skill myself.
I begin by telling the agent in the Codex app what I want in general. Then I ask it to investigate the existing project and any relevant information before asking me questions.
The interview is an important part of my process. I ask the agent to give me one question at a time. Each question normally includes possible directions and a recommendation. That makes it easier for me to react, compare the options, and explain what I actually want.
We brainstorm the answers together. I do not always accept one option exactly as it is written. Sometimes I combine ideas. Sometimes an answer raises another question. The conversation continues until the workflow is clear enough to build.
That is how I created my blog article creation skill. The conversation defined where article ideas should come from, how topics should be tracked, and how the agent should interview me so the draft reflects my own experience. It also defined how the article should sound, what SEO work should happen, what files should be created, when visuals should begin, and how far the agent should be allowed to go in WordPress.
Only after those decisions were clear did the agent turn the conversation into reusable skill files.
I keep different responsibilities in focused skills
I prefer skills that have a specific responsibility. When a skill becomes too large, I find it harder for the agent to follow every part consistently. It also becomes harder for me to know where a future change belongs.
For creating blog articles, I use one skill for the article and another skill for the visuals.
The article skill owns the topic research, interview, writing, SEO, and writing review. Once I have reviewed and approved the article, the visual skill can use the completed context to create the featured image and the SVG diagrams that explain selected sections.
The two skills are connected. The article skill points to the visual skill when the article reaches that stage. But each one still owns a clear part of the work.
This structure also makes maintenance easier. If I want to change the interview or writing style, I know the article skill owns it. If I want to change the featured-image format or visual QA, I know the visual skill owns it.
This is close to the current public guidance. OpenAI recommends keeping a skill focused on one job and making its inputs and outputs explicit. The open Agent Skills guidance describes a skill as a coherent unit of work that should compose well with other skills. It also warns that overly broad skills can make it harder for the agent to identify what matters.
I did not begin with that terminology. I arrived at a similar structure by thinking about how I wanted the work to happen.
A skill can still miss something important
Using a skill does not mean the result is automatically correct.
In one early test, the article workflow knew that it should use topic and role-signal files, but the skill did not explicitly say where those files were. Another task in the Codex app had to infer their locations. I asked the agent to investigate, and we added the exact paths to the workflow.
In another test, I expected the completed article package to include SVG visuals, but they were not present. The visual requirement existed in the wider process, but the wording left too much room for it to be treated as a note instead of a required handoff.
Later, the featured image was created without the article title. The image worked as a diagram, but it did not work as well as a blog cover or social preview. I asked the agent to update the current image and make the title a default requirement in the visual skill.
I do not describe these moments as the agent completely ignoring the skill. Sometimes the instruction is too open. Sometimes a location is implied instead of explicit. Sometimes the definition of complete is not strong enough.
The output shows me where the workflow needs to become clearer.
I improve the skill from the result
I do not audit every line of a skill each time I use it. I look at the result.
If something is missing or wrong, I ask the agent to compare the output with the relevant part of the skill. Then I ask it to identify whether the problem came from the instruction, the supporting reference, the handoff, or the execution.
I normally want two things fixed. The current output needs to be corrected, and the reusable workflow needs to be improved so the same problem is less likely to happen again.
The change should go into the skill that owns that responsibility. A detailed rule may belong in a reference file rather than making the main skill longer. After the update, the agent validates the skill where possible and checks the affected output again.
This is not a perfect testing system. If the agent skips something and the result still looks acceptable, I may not notice it. My process is based on visible review, not a complete compliance audit after every task.
That limitation matters because it keeps the claim honest. Skills improve consistency, but they are not guarantees.
What skills actually save me
The biggest saving is the setup time.
Without a skill, I have to explain the workflow again. I need to describe which files matter, what order to follow, what the output should contain, when the agent should ask me questions, and what it is allowed to change.
With a skill, those decisions are already available. I can call the skill and start closer to the actual work.
The second saving is consistency. The skill gives different tasks in the Codex app the same operating context. One task is less likely to begin with keyword research while another begins with the topic bank, because the intended order is written down.
The third saving is that corrections can compound. If a useful preference stays only inside one conversation, it disappears with that task. When I add it to the skill, it becomes available the next time I use the workflow.
The public guidance follows the same general idea. OpenAI describes skills as reusable workflows that package instructions, resources, and optional scripts. The Agent Skills guidance also recommends refining a skill through real execution, including the corrections made while completing actual tasks.
For me, that is where the real value appears. The skill is not only a prompt I reuse. It becomes a working process that improves as I use it.
My practical rule
I use a skill when the workflow is repetitive enough that I do not want to explain it again.
I create it through a conversation. I ask the agent in the Codex app to investigate, interview me, offer recommendations, and help me make the decisions before writing the final instructions.
I keep responsibilities focused where it makes sense. I call the skill, review the result, and improve the relevant part when real work exposes a gap.
That is the best way I have found to work with Codex on repeatable tasks. It saves time, keeps the context available, and gives the agent a much clearer starting point. I still keep the final judgment.