How to use AI coding skills: less typing, fewer bugs, repeatable results

You’re not teaching the agent to be clever. You’re teaching it to work the way you already do, once, so you never have to teach it again.

TL;DR: A skill is a small markdown file that tells a coding agent how to do one job your way. It can carry the instructions, point at other docs, or point at a script that already lives in your repo. The slash command is shorthand for “here are the instructions, do it.” The payoff is determinism: you type less, and a non-deterministic agent starts doing the job the same way every time.

What you lose without skills

Start a session with no skills and the agent is guessing. It doesn’t know where your tickets live, how your database is laid out, or how you like a feature planned.

So it asks, or it assumes, and you burn the first few thousand tokens re-explaining yesterday’s conventions. Switch from Claude Code to Codex and you start again from nothing.

Skills fix that. The knowledge stops living in your head and starts living in the repo, where the agent reads it fresh every time. With them you get:

• Fewer tokens burned. The conventions are already written down, so you don’t pay to explain them again every session.
• Work done faster. Less back-and-forth, less re-planning, less correcting the same drift.
• Fewer bugs, more determinism. The agent does the job the same way every time, and the parts handed to scripts run the same way every time.

What a skill is made of

A skill is just a file, written in plain English. There’s nothing technical to it. If you can explain a job to another person, you can write one. Most of the time you don’t even write it yourself, you get the agent to draft it and then fix the parts it got wrong.

This is a complete skill. It stress-tests a plan by interrogating you about it before you build, and comes from Matt Pocock’s public collection:

---
name: grilling
description: Grill the user relentlessly about a plan or design. Use when the user wants to stress-test a plan before building, or uses any 'grill' trigger phrases.
---

Interview me relentlessly about every aspect of this plan until we reach a shared understanding. Walk down each branch of the design tree, resolving dependencies between decisions one-by-one. For each question, provide your recommended answer.

Ask the questions one at a time, waiting for feedback on each question before continuing. Asking multiple questions at once is bewildering.

If a *fact* can be found by exploring the codebase, look it up rather than asking me. The *decisions*, though, are mine, put each one to me and wait for my answer.

Do not enact the plan until I confirm we have reached a shared understanding.

That’s the whole file. (Source.) Every skill has the same shape. The top is a name and a description, and the description is the part that decides when the agent reaches for it, from a trigger word or a plain mention in a sentence. Everything after it is the body: what to do, written in plain language, with the rules and gotchas that matter.

They also chain. One line can pull in several at once: load /ticket 1234 and check /live world 5, then write a /spec for it, which loads the work, reads the live data behind it, and plans it.

A skill can just send the agent somewhere else

The steps don’t have to live inside the skill. A skill can do one of a few things, and this is where they get powerful:

• Spell out the steps itself. The instructions are right there in the file.
• Send the agent to read something you already wrote. “The rules for this are in that document, go read it and follow it.”
• Tell the agent to run a tool you already have. A script is a small program someone already wrote that does the job the exact same way every time. The skill just says: run that.
• Call another skill. A planning skill can hand off to the grilling skill once it has a draft. They chain together, so you build big workflows out of small pieces instead of one giant file.

Think of the slash command as a shortcut. Instead of typing out the instructions again, you type /live and the agent goes and does the thing you already described once.

That third option is the important one. An AI agent is unpredictable. Ask it to do the same job twice and it’ll do it two different ways. But a tool that already exists isn’t guessing, it runs the same way every time. So every time a skill points the agent at a tool instead of letting it improvise, the result stops being a gamble and starts being repeatable. You type less, and you get the same outcome every time.

And call your skills yourself. Don’t sit back and hope the agent notices it should use one. Remember the skills you have and name them: when you want grilling, type /grill. An agent will sometimes reach for one on its own, but that’s not what they’re built for. You know the job needs it, so you’re the one who calls it.

A full session, start to finish

One feature, end to end, through a dozen skills. The replies below are made up to keep it short.

The session turns on a few small moves:

• The frontend was built with no skill, on purpose. It works, but it drifts, and the review against frontend-conventions and style is what catches the missing mobile scrollbar.
• The fix is one line. Updating the style skill so it never happens again is the move that matters.
• The session doesn’t end at the commit. The last two lines are where the skills get better.

Do’s and don’ts

Do:

• Write a skill the second time you do a task. Rough is fine.
• Push the fiddly, must-be-exact work into a script, and have the skill call it.
• Make the description precise. It decides when the skill fires.
• Chain skills in one command: load, read, plan in a single line.
• Point at existing docs and scripts instead of copying their contents in.
• After a session, ask the agent what to add, remove, or update, then commit it.
• Gate risky skills. A live-data skill should be read-only by default.

Don’t:

• Don’t skip the write-down step because it’s “just this once.” Once becomes weekly.
• Don’t let the agent improvise something a script already does. That’s where drift comes from.
• Don’t stuff one skill with five jobs. One skill, one job.
• Don’t leave conventions in a prompt you’ll lose. Prompts don’t persist across sessions.
• Don’t build a screen without the conventions skill and hope it matches. It won’t.
• Don’t trust a test the agent wrote against existing code. Ask for the red light first.

---

Inselnova is a browser strategy game built this way. Play here.