At 9:13 on Sunday night, Codex finished a job that had taken just under 25 minutes. It had researched Omarchy Linux, built a Gemini Notebook with 39 usable sources, generated a long overview and a debate, downloaded both audio files, created artwork, published the episodes, and checked the finished RSS feed.

At 9:40, after looking over the result, I asked a follow-up question:

Could we create a skill to do this workflow in the future?

At 9:44, Codex had turned the run into a reusable Codex skill.

Four minutes later, I had a folder containing 268 lines spread across four files. Of those, 148 were code. The four minutes were real. They were also the least important number in the story.

The earlier 25-minute run had already done the design work. Codex had made dozens of small decisions about sources, filenames, task IDs, audio formats, feed metadata, and the point at which an episode counted as published. The skill captured those decisions before the conversation disappeared into my history.

I wrote about the complete system in How I Built a NotebookLM Podcast With an Audience of One. This is the part that happened afterward, when one successful run turned into something I could invoke again.

The prompt was the easy part

My original Omarchy request described the result I wanted. I asked for recent authoritative sources, interviews, Wikipedia background, and YouTube material. I wanted a long overview and a separate debate, both downloaded and published with suitable metadata and artwork.

That was enough for one run. Codex could decide which sources belonged in the notebook, how the overview should differ from the debate, how to name the downloaded files, and how to call my uploader as it encountered each problem.

Saving that prompt would preserve what I typed. It would not preserve any of those decisions.

The next run would still have to work out what counted as a usable source, which identifiers connected one operation to the next, what metadata belonged in the feed, and which external changes it was allowed to make. Maybe it would make the same choices. Maybe it would not. That is closer to rerunning an experiment than reusing a process.

This is the distinction I care about now. A prompt describes the outcome. A skill preserves the procedure, including the decisions that are easy to overlook after a successful run.

Four files were enough

The official OpenAI documentation describes a skill as a directory with a required SKILL.md file and optional scripts, references, templates, and other resources. My podcast publisher ended up with this structure:

notebooklm-podcast-publisher/
  SKILL.md
  agents/
    openai.yaml
  references/
    workflow.md
  scripts/
    Publish-PodcastEpisode.ps1

SKILL.md is 29 lines. The workflow reference is 87. The PowerShell publication script is 148. The four-line openai.yaml file supplies the name, description, and default invocation shown in the app.

That is 268 lines in total. The split is almost even. There are 120 lines of instructions and metadata, and 148 lines of PowerShell. The reusable workflow is almost as much written judgment as automation.

The description at the top of the skill does more work than its four lines suggest:

name: notebooklm-podcast-publisher
description: Research a current topic, build a source-rich NotebookLM notebook,
  generate long overview and debate audio, create artwork, and publish verified
  podcast episodes. Use for the complete research-to-podcast workflow, not
  ordinary NotebookLM questions or standalone feed edits.

The second sentence keeps an ordinary question about Gemini Notebook from becoming a public podcast episode. That seems like a useful distinction.

I normally invoke it explicitly:

Use $notebooklm-podcast-publisher to research [topic] and publish an overview and debate.

Codex can select the skill when a request clearly matches it, but I prefer being explicit when a task will create notebooks, generate files, and publish something publicly.

Some decisions belong in English

The short SKILL.md file establishes the rules that apply to every run. Use current research. Prefer primary sources. Use notebooklm-py to work with Gemini Notebook. Retain exact artifact IDs. Publish episodes one at a time. Leave channel-level podcast metadata alone unless I ask to change it.

The longer reference file handles the decisions that need more explanation. A useful notebook for this podcast needs official documentation, recent interviews, independent reporting, technical background, and credible disagreement. The skill suggests roughly 20 to 40 usable sources, but it values source quality and viewpoint coverage more than a fixed count.

The reference also explains the difference between the two programs. The overview should cover the subject broadly. The debate needs a concrete proposition and a serious case on both sides.

A script can add URLs and wait for them to finish processing. It cannot decide whether the notebook has enough firsthand material or whether a proposition is worth forty minutes of argument. I could turn that judgment into scoring rules, but then I would be maintaining a brittle research rubric for a podcast with one listener.

English is the better tool for that part of the job.

The word “latest” is a bug waiting to happen

The workflow crosses several external operations:

Notebook ID
  -> ready source set
  -> overview task ID
  -> debate task ID
  -> overview artifact ID
  -> debate artifact ID
  -> downloaded files
  -> published media URLs

The skill retains those identifiers and uses them explicitly. It does not ask Gemini Notebook for the latest artifact and hope that “latest” still refers to the file created by this run.

This is not deep computer science. It is exactly the sort of dull detail that separates a repeatable workflow from one that works until two things finish in the wrong order. Natural language is useful for deciding what the debate should be about. An exact ID is better for deciding which audio file to publish.

Publication is also where I wanted regular code. Publish-PodcastEpisode.ps1 accepts the local audio and artwork paths along with the episode metadata. It determines the MIME types, checks that remote API calls use HTTPS, asks the uploader to inspect the audio, uploads the files, reads the resulting feed, and returns the verified episode.

The script does not choose the subject or the sources. Codex makes those decisions from the instructions. The script takes the finished editorial decision and performs the same API work every time.

The boundaries are equally plain. The skill does not delete episodes or replace the podcast title, author, artwork, or category. It only creates a notebook or publishes an episode when I explicitly ask for that work. If I ask a question about Gemini Notebook, I do not want the answer to include a surprise public episode.

The second run mattered more than the first

The Omarchy run proved that Codex could complete the workflow once. That was useful, but it did not prove that I had captured it.

The next day I invoked the new skill with a different request. I wanted a current assessment of the software job market based on my experience and the Atlanta region. It produced a 34-source notebook, a 37-minute overview, and a 38-minute debate.

Later I used it to research AI development methods such as OpenSpec and BMAD. That run created a 40-source notebook, a 45-minute overview, and a 35-minute debate.

Neither request repeated the Omarchy instructions. I supplied a subject and the angle I cared about. The skill handled the research, generation, download, publication, and final checks.

Those later runs are better evidence than the first one. A successful run proves that the agent can finish a job. A successful run with different input proves that I preserved enough of the process to use it again.

When I would bother creating another skill

I would not turn every useful prompt into a skill. Some tasks are one-off, and some are simple enough that a saved prompt contains everything worth keeping.

I now look for a task I have completed successfully once and expect to repeat with different input. A skill becomes worthwhile when that task crosses several tools, carries identifiers or files between steps, changes external systems, or mixes editorial judgment with mechanical work.

If the task only needs a better sentence, I save the prompt. If it has a procedure and some state that must survive between tools, I consider a skill.

At 9:44, it looked as though Codex had created one in four minutes. A more accurate account is that the 25-minute Omarchy run supplied the raw material and the next four minutes packaged it.

The skill itself is private. It knows about my uploader API and the conventions of my podcast feed. Publishing the raw files would mostly give someone else a collection of broken assumptions presented as a reusable tool.

That does not reduce its value to me. It is a small piece of long-tail bespoke software, built for a job I actually repeat. I built a podcast with an audience of one. It seems appropriate that the software publishing it has the same target market.

AI assistance disclosure: OpenAI Codex assisted with research and drafting. I reviewed and verified the final article before publication.