Skills All the Way Down: How I Used Codex to Build a Repeatable Content System
Most writeups about AI workflows skip the part that matters. They jump from idea to polished result and leave out the messy middle where the system gets built, breaks, gets patched, and slowly becomes worth trusting.
This is the candid version of what I actually did.
I did not sit down and tell Codex to “write me a great article and go publish it.” I built a small stack of skills in sequence. First, I prompted Codex to create a skill that could scrape my X bookmarks. Then I prompted Codex to create another skill that could take source material, write an article, create social posts, and use Buffer to publish them. After a real run, I prompted Codex to update those skills with whatever lessons we learned from actually using them.
That sequence turned out to be the real story. The leverage did not come from one clever prompt. It came from turning repeated behavior into reusable instructions, then improving them after a real run.
The first problem was not writing. It was capture.
My X bookmarks had become a holding area for useful links, half-finished thoughts, and ideas I meant to revisit later. That works as temporary memory, but it fails as a system. Bookmarks pile up, context disappears, and eventually the whole thing becomes another unread queue.
So the first skill I had Codex build was a bookmark capture workflow. Its job was simple: open the live X bookmarks timeline, extract the bookmarked post and the surrounding context, summarize what was actually there, persist the result somewhere stable, and clear the bookmark so the system would not keep reprocessing the same input.
That immediately improved the quality of the workflow. Instead of treating bookmarks like an infinite inbox, I had a pipeline. Raw material came in. Structured notes came out. The pile stopped growing invisibly.
Once the capture layer existed, the next question became obvious: how do I turn that material into output without manually rebuilding the same steps every time?
That led to the second skill. This one had to do more than write. It needed to decide what the source of truth was, draft a coherent article, create or update the article in Leaf Lane, produce social copy for X, Instagram, and Facebook, handle image creation, use Buffer to queue the posts, and log the result so the next run would not blindly repeat the same angle.
That was the point where the workflow became a process. One skill produced structured source material, and another turned it into a publishable asset and distribution package.
At that stage I would not call it automated. It was not automated so much as operational enough to fail usefully.
And that is exactly what happened.
The most valuable prompt in the whole process was probably the least glamorous one: update the skills with any lessons we learned during the last run.
On paper, the write-and-publish workflow looked clean. In practice, the live run exposed the details that only show up when an agent touches real interfaces and real content:
- Buffer needed media attached per network after customizing the post, not just once globally
- image descriptions had to be added per network before scheduling would enable
- “Next Available” in Buffer was not the submit action, just the scheduling mode selector
- Instagram’s first comment field was not reliably available in the composer state we hit
- Leaf Lane blog content rendered best when stored as clean plain text with intentional paragraph breaks, not markdown-heavy formatting
None of those lessons are dramatic, which is exactly why they matter. They are the kind of operational details that quietly determine whether a system is dependable or annoying. If you do not feed those lessons back into the workflow, you are not really building capability. You are just having one-off successful sessions and hoping the next run behaves the same way.
A better prompt might improve one run. A better skill improves the next ten.
That is the shift I think people miss. The valuable part is not just that the agent can produce output. The valuable part is that the workflow can improve after every run.
You stop asking only, “How do I get the agent to do this task right now?” and start asking better questions:
- what should become reusable?
- what should be remembered?
- what should be logged?
- what should be tightened before the next run?
That is where the compounding behavior starts.
I do not want to oversell any of this. Even with skills, this is not push-button excellence. You still need judgment about which tasks deserve their own skill, when a workflow is stable enough to abstract, how much freedom the agent should have, which parts need explicit guardrails, and what “done” should mean in practice. You also need the discipline to keep the skills honest. If a skill becomes vague or bloated, it stops being useful.
The best mental model I have found is simple: treat skills like procedures for an agent.
Once you have a few reliable skills, the next step is to layer them. A capture skill gathers source material. An article skill turns source material into a draft. A publishing skill handles CMS state, metadata, images, and publish status. A social skill tailors distribution by channel. A review pass records what happened and updates the system with what you learned.
From there, scheduling becomes the obvious next move. If a workflow is stable enough, you should not have to remember to run it manually every time. You can schedule recurring skill-driven work in Codex through automations, and the same basic pattern applies in Claude-based setups anywhere recurring agent runs are supported in your environment.
That changes the human role. The job becomes defining the right skills, composing them into the right chains, reviewing the output, and feeding the lessons back into the system.
Build the machine. Inspect the machine. Improve the machine.
The important pattern here is not simply that AI can write. It is that small reusable skills can turn one-off prompting into a repeatable system that improves with every run. At that point, you are not just using an assistant. You are building a machine.