The 7 skills I actually use every day with AI coding agents

My favourite Codex skills for building software.

If you spend any time in AI engineering circles online, you’ll quickly get the impression that being productive with coding agents requires hundreds of skills, dozens of MCP servers, an insane workflow, and a wall of plugins blinking at you whenever you open your terminal.

I don’t think that’s true. In fact, I think it’s actively unhelpful.

The longer I work with these tools, the more convinced I am that you just need a small number of high-quality skills to handle the vast majority of your day-to-day work.

It took me a while to actually internalise it, because the gravitational pull is always toward more. More tools. More skills. More configuration. More cleverness.

In this post I’ll share the skills I enjoy using most day to day building software.

I made a full video here:

Managing Skills

One of the biggest headaches I found with skills is having markdown files scattered all over my filesystem. Every coding agent seems to keep skills in a different place. The solution is to use this CLI which makes managing and updating skills easy.

https://github.com/vercel-labs/skills

1. spec. Get clear before you write code

If I had to pick one skill that’s done more for the quality of my output than any other, it would be this one.

The idea is straightforward. You come to the agent with a rough idea, usually a couple of sentences, sometimes a paragraph if I’m being generous, and the skill produces a proper spec. What we’re building. Why. The relevant existing code in the repo. The data model. The requirements. The constraints.

This is simple the “think before you code” principal for agents.

The first draft is almost never right, and that’s exactly the point. You sit with it. You read through carefully. You correct the things the agent misunderstood. You make the implicit assumptions explicit. By the time you’re done iterating, you and the agent are genuinely aligned on what’s being built, and every micro-decision you’ve nailed down is one fewer decision the agent has to guess at later.

The cost is maybe twenty minutes up front. The saving is hours of rework on the other side.

2. plan. Break the work into shippable chunks

Once the spec is solid, I run plan to break it into discrete tasks.

I never, and I really mean never, ask an agent to build an entire feature in a single shot. It rushes. It cuts corners. The diff becomes impossible to review, and you end up either rubber-stamping work you haven’t really understood or unpicking the whole thing.

Smaller chunks fix all of that. Each task is reviewable. Each task is shippable. Each task is something you can actually course-correct on before the next one starts.

I push the tasks straight to Linear or GitHub Issues. The tracker doesn’t really matter. Having one does. Trying to manage agent work through a folder of markdown files is a special kind of pain I don’t recommend.

3. explain-visually. Turn anything into a rich HTML explainer

There was a post on X recently that went pretty viral about the “unreasonable effectiveness of HTML” as an output format for agents. The argument is roughly: markdown is the lazy default, but HTML is a much richer medium. Better for diagrams, better for layout, better for the way humans actually consume information.

I took that idea and turned it into a skill. You point it at a repo, an architecture, a PR, a concept, anything really, and it produces a properly designed HTML page. Cheat sheets. Diagrams. Structured explanations.

I’m a visual learner, and this has quietly become one of the skills I use most often. When I’m onboarding to an unfamiliar codebase, I run this first. When I want to understand a concept properly, I run this. The output is the kind of thing that would take a person hours to put together.

4. clarify. For when you’re rambling

Most of the prompts I write now are dictated. I talk to my agents. It’s just faster.

The problem is that voice dictation produces messy prompts. Half-formed thoughts. Contradictions. Vague references (”the thing”, “that script”, “you know, that bit we did earlier”). An agent trying to act on that is going to do something, but probably not what you wanted.

The clarify skill is the fix. It interviews you one question at a time, walks down the decision tree, and turns your ramble into a tight, self-contained optimised prompt. The difference between what goes in and what comes out is genuinely night-and-day.

5. address-pr-feedback. My favourite of the seven

This one has changed how I work more than any of the others, and it’s almost embarrassingly simple.

I used to do most of my code review locally. It was slow, and honestly, I wasn’t great at it on my own work. So I changed the loop. Now the agent pushes the branch, and I rely on automated reviewers (Copilot, Codex, Claude) to comment on the PR. Then address-pr-feedback pulls every comment down, judges which are valid, fixes what needs fixing, pushes the changes, and replies to each reviewer noting the commit that resolved their comment.

The crucial part is that it doesn’t blindly accept feedback. It evaluates each comment on its merits. Bad suggestions get pushed back on. Good ones get implemented. And replying to reviewers (even AI ones, but especially humans) is just good practice.

6. refactor. Always do a second pass

The first version of code an agent writes is almost always fine. Workable. Functional. But almost never the best version.

The refactor skill is the second pass I run on anything significant. Simpler logic. Less duplication. Fewer lines saying the same thing twice. It’s a small skill in terms of what it does, but compounded across every change I ship, it’s one of the biggest quality multipliers in my whole workflow.

The lesson buried in here is broader than the skill itself. Never blindly accept the first output. There’s almost always something to improve. The agents themselves know this. They’re often perfectly happy to tighten their own work when you ask.

You just have to ask.

7. design-doc. Think clearly before you build

For anything with real architectural weight (a new service, a significant refactor, a decision that’s going to be expensive to undo), I write a design doc before the spec.

A spec is for the agent. A design doc is for humans. For you. For the teammate you’ll loop in. For the senior engineer reviewing the approach before code gets written. Context and scope. Goals and non-goals. Architecture diagrams. APIs. Storage. Trade-offs. The kind of structured thinking that companies like Google and Amazon have built into their engineering culture for good reason. The cost of changing code in production is enormous, and a few hours of thinking up front is dirt cheap by comparison.

Agents help us write code. They don’t help us think clearly. Design docs do.

Get The Skills Free

All seven skills are open and free. They’re linked from the video that goes with this post. Grab whichever ones look useful, ignore the rest, fork them and make them yours.

Thanks for reading.

Owain