How to Turn Repeated Work Into an Agent Skill That Actually Works

If a workflow only works because you remember how to steer it, you have not made it reusable. Here is how to turn three completed runs into a skill that can handle the fourth.

I recently posted that I am turning more of my one-off apps into agent skills.

A lot of people liked the compression: App → Skill. Interface → Intent. Maintenance → Reuse.

But that post skipped the hard part. Creating a SKILL.md file is easy. Extracting the right decisions from work you have already done—and proving an agent can repeat them without you—is the actual craft.

This guide is for people who already use Codex, Claude, or another coding agent to do real work and keep encountering the same workflow. You have prompts, scripts, examples, and a process that works when you personally steer it. What you do not have yet is a capability that travels.

By the end, you should be able to take three completed runs and turn them into a skill that can handle the fourth without being told the answer.

The fourth-run test

The open Agent Skills specification defines a skill as a directory containing, at minimum, a SKILL.md file with a name, description, and instructions. Skills can also include scripts, references, assets, and other resources.

That tells you what a valid package looks like. It does not tell you whether the package is useful.

My practical definition is stricter:

A useful skill takes a recurring request, makes the important decisions explicit, uses the right supporting resources, and produces a result you can verify.

The test is not whether the folder validates. The test is whether the skill can take fresh work and preserve the useful behavior.

Start with completed work, not a blank SKILL.md

The easiest way to write a vague skill is to imagine the ideal workflow from scratch.

You remember the clean version. You forget the confusing request, the bad first result, the correction that changed everything, and the check that caught the final mistake. Unfortunately, those are usually the useful parts.

Start with at least three real executions of the same general capability. For each run, preserve:

• the original request;
• the inputs and source material;
• the first result;
• corrections and feedback;
• the final result;
• the checks used to decide that it was done.

Then compare the runs. You are looking for different kinds of material, and they should not all become prose instructions.

This is the central move: do not save the conversation. Extract the parts that should change the next run.

Decide what the skill should own

A skill is not an alternative to every other container. It often coordinates several of them.

A publishing skill might use a script to validate image dimensions and an MCP tool to create a Ghost draft. The skill owns the workflow and judgment. The script owns the exact check. The tool owns access to the external system.

This distinction matters because a giant skill that tries to own everything becomes hard to trigger, expensive to load, and difficult to trust.

Write the output contract before the workflow

Most weak skills begin with a list of steps. I now prefer to begin with the result.

For a social-graphic workflow, “make a good image” is not an output contract. A usable contract might require:

• one selected final image at a stable workspace path;
• verified dimensions and crop;
• exact visible text with no invented words;
• alt text;
• the approved caption;
• the target account and scheduled time;
• a re-fetched publishing record after scheduling.

The contract tells the skill where to stop. It also tells you which steps are necessary and which ones are ceremony.

Write down the inputs, required outputs, permissions, stop conditions, and proof. Then write the workflow that gets there.

Build the smallest useful package

A practical skill can remain simple:

social-graphic-art-direction/
├── SKILL.md
├── references/
│   ├── routing.md
│   ├── review-and-variation.md
│   └── case-study.md
├── scripts/
│   └── verify-image-dimensions.py
└── assets/
    └── approved-layout-template.svg

The important separation is behavioral:

• Description: what the skill does and when it should load.
• Core workflow: decisions and steps required on most runs.
• References: detailed or conditional knowledge.
• Scripts: deterministic work and validation.
• Assets: templates and materials used in the output.
• Output contract: what must be true before the work is complete.

This follows the progressive-disclosure model described by both the Agent Skills specification and OpenAI’s current Codex skills guidance. The agent first sees a skill’s name and description, loads the full SKILL.md when the skill applies, and reads supporting resources only when the current task requires them.

That makes the description load-bearing. This is too vague:

description: Helps make good marketing content.

This gives the agent a real trigger and boundary:

description: Create, critique, vary, select, package, and schedule
  distinctive social graphics for founder posts. Use when a post
  needs a visual concept, production routing, feed-scale review,
  or a verified publishing handoff.

The body should be equally direct. Put the normal path in SKILL.md. Move depth out. Put brittle transformations in code. Do not make the agent reread a manual or reinvent a validator on every run.

Worked example: turning design feedback into a skill

The LinkedIn graphic that started this discussion came from a simple request: make an image for a post called “Turn Apps Into Skills.”

The first approach used a deterministic editorial layout. It rendered correctly and looked designed. It also communicated the wrong thing. We were applying grids, ratios, and asymmetry because they were available—not because they explained the transformation in the post.

The useful visual sentence turned out to be much simpler: a dense stack of application interfaces and maintenance machinery compresses into one reusable SKILL.md dossier.

Image generation handled that metaphor better than the layout system. We generated several meaningfully different concepts, but the first image remained the strongest. Later, when we created diagrams for this article, we made a different mistake: the images matched the theme but did not reduce the reader’s work. They were branded atmosphere pretending to be explanation.

Those failures gave us useful rules:

• State the visual relationship before choosing a production method.
• Use image generation for a singular metaphor-led object.
• Use deterministic layout for exact diagrams, charts, and repeatable systems.
• Review the actual artifact at full size and intended consumption size.
• Vary the concept, not merely the palette or crop.
• Keep a strong anchor visible; newer does not mean better.
• Treat explicit human selection as the result.
• Verify persisted external state after scheduling.

Just as important, the visual style did not become a universal rule. Warm paper, black ink, and the dossier metaphor belonged to one post. The skill kept the decisions that should survive the next assignment.

A weak version of the skill would have looked like this:

description: Makes great social graphics.

1. Read the post.
2. Make a polished visual.
3. Iterate until it looks good.

That package has no clear trigger, no production decision, no quality test, and no definition of done. The repaired skill starts by extracting the non-generic claim, names one visual sentence, routes the work to generation or deterministic layout, inspects the real output, creates only meaningful variants, preserves the selected asset, and verifies the publishing handoff.

The difference is not better prompt writing. The difference is that the second version preserves the decisions that made the work succeed.

Give it a fresh fourth run

Do not test the skill by replaying the example that created it. That only proves the skill can imitate its calibration case.

Give it raw work from the same general class without explaining the desired answer. Then run five checks:

Trigger test

Try requests that should and should not activate the skill. If it loads for every broad marketing task, the description is too vague.

Fresh-work test

Use a new input and withhold the path you expect. The skill should make the important decisions, not wait for you to leak them.

Boundary test

Give it work that should be handled by a plain instruction, a script, a tool, or an app. A good skill routes the work instead of trying to absorb the whole system.

Failure test

Remove a required file, create conflicting inputs, or make verification fail. The skill should stop safely, explain what is missing, and preserve external state.

Output test

Inspect the real artifact against the output contract. Do not accept the agent’s summary as proof that the file, draft, schedule, or external record is correct.

The Skill Distillation Protocol

1. Collect three real executions of the capability.
2. Name the recurring request and the result worth preserving.
3. Compare the requests, corrections, failures, final artifacts, and completion checks.
4. Separate recurring decisions, fixed rules, variable inputs, conditional knowledge, deterministic work, and external tools.
5. Write the output contract and stop conditions.
6. Package the smallest useful trigger, workflow, references, scripts, and assets.
7. Forward-test the skill on a fresh fourth run without leaking the answer.
8. Turn each failure into the smallest rule or resource that would improve the next run.

You do not need three runs because three is mathematically special. You need enough evidence to distinguish the workflow from the accident of one successful conversation.

Keep the app when the interface is doing real work

The original post argued for moving useful capability closer to the agent runtime. It did not mean every interface should disappear.

Keep the app when people need to collaborate, inspect or edit shared state, understand what the system is doing, grant approval, manage permissions, or exercise direct control. In those cases, the interface is part of the capability.

But if the interface only collects parameters an agent can already infer from a request, it may be accidental maintenance.

This is where my own behavior has changed since I spent hundreds of hours building small AI apps. Building the interface was often the fastest way to discover the workflow. Once the workflow is understood, the interface does not always deserve to survive.

The folder is the beginning, not the proof

A prompt can improve one interaction. A script can make one transformation reliable. A tool can provide access. An app can give a person control. A skill coordinates the pieces around a recurring intent.

That is why designing around the agent that must use the capability matters—and why better prompting alone is not the same thing as packaging reusable work.

If the skill cannot take a fresh fourth request and preserve the useful behavior, you have a folder. Keep working.

I write guides for people using agents to do real work: practical methods, experiments, and the knowledge structures that make the work hold together. Subscribe here if that is useful to you.

Sources: the Agent Skills specification, OpenAI’s current guide to building skills, and OpenAI’s overview of Skills in ChatGPT.