Skills over prompts: encode how you work once

If you find yourself typing the same instructions into an agent every week, you are paying the same tax over and over. “Write a plan first.” “Check the browser before you say it works.” “Don’t use that phrasing.” Each prompt is small. Repeated across every session, they add up to most of the steering you do.

A skill moves that steering out of the chat and into a file the agent loads when the work calls for it. A prompt tells an agent what to do this time. A skill tells it how to do a kind of work every time.

This is the second post in a series on working with agents. The first covers the developer’s agent stack. The third covers how I work with agents every day.

What a skill actually is

A skill is a packaged set of instructions for one kind of task, with a description that tells the agent when to use it. A test-driven development skill says how to write a failing test first. An architecture skill says to settle types and module boundaries before writing code. A review skill says how to run several models over the same diff and compare what they find.

The agent reads the description, decides the skill applies, and loads the full instructions only then. That keeps the context small until the skill is needed.

The useful property is consistency. The fifth time you do a kind of work, the agent follows the same method it followed the first time, without you restating it.

Adapt before you author

I mostly adapt skills other people wrote rather than write my own. That is a deliberate choice. Good skill sets already encode the practice of people who thought hard about one kind of work. My job is to pick the ones that match how I want to work and configure them.

Three sets changed my work the most:

• pstack, for engineering judgment. It puts architecture before code, runs parallel attempts at the same task, sends a diff to several models for review, and cuts generic AI phrasing from prose.
• BMAD, for larger features. It runs a feature through spec, stories, and build, so the work stays coherent across many sessions.
• Writing skills. Humanizer removes the patterns that make text read as machine-written. An STE100-style rewrite removes ambiguity from text that other agents or non-native readers have to parse.

Adapting is real work. I set which model plays which role in the skills I use. Implementation, judgment, and review can each run on a different model, and reviews can go to a panel of models. That configuration lives in one file, so changing my mind about a model is a one-line edit, not a new habit.

Keep skills where every tool can read them

My skills live in one folder that more than one agent tool reads. When I switch from one coding agent to another, the method comes with me. Skills tied to a single tool are a quiet form of lock-in. If moving tools means re-teaching your workflow, your workflow lives in the wrong place.

Skills and repository rules do different jobs

Skills are not the fix for every agent mistake. One of the most common failures I see is an agent that writes working code that ignores how the codebase does things. A skill cannot fix that, because the conventions are specific to the repository.

The split I use:

• Skills encode how to do a kind of work: planning, testing, reviewing, writing. They travel with you across projects.
• Repository rules encode how this codebase works: layers, patterns, test setup, what reviewers reject. They travel with the code across people.

When an agent makes the same mistake twice, ask which kind it is. If it is about method, it belongs in a skill. If it is about this codebase, it belongs in the repository rules. I covered the second half in building an agent harness.

What a lead should do

A team where every engineer has a private skill set has the same problem as a team where every engineer has a private build script. It works for each person and nobody can help anybody else.

Pick a shared base: a small set of skills for planning, testing, review, and writing, plus the MCP servers everyone needs. Put them where the whole team’s tools can load them. Let people add their own on top. Then the default way of working with agents is the same across the team, and improvements to it reach everyone at once.

Start with your most repeated prompt

Look at what you typed into your agent this week. Find the instruction you gave more than twice. That is your first skill. Before writing it yourself, look for an existing skill that already does it well, and adapt that one.