Turn Your Workflow Into a Claude Skill

I used to start every project by re-explaining myself. Same conventions, same folder structure, same testing rules, same "please don't add a dependency for that" — typed again, slightly differently, in a fresh session. It worked, and it was completely wasted effort.

A skill fixes that. It is a folder with instructions in it that the model loads when the task matches. You write your process down once and it shows up every time it is relevant, in every project, without you remembering to paste anything.

What actually belongs in a skill

The mistake is treating a skill like documentation. Documentation describes what exists. A skill prescribes what to do. If a line does not change an action, it is decoration.

The skills that earn their place in my setup all have the same shape:

• A trigger — a plain description of when this applies, written the way I would say it out loud. This is the part the model matches against, so vague triggers get ignored.
• A sequence — the actual order of operations, numbered. Not "consider testing" but "run the suite before you report done, and paste the failing output if it fails."
• The non-obvious constraints — the things a competent stranger would get wrong. Every project has three or four of these and they are the entire value of the skill.
• A definition of done — what must be true before the work is handed back.

Everything else is padding.

Write the trigger like a sentence, not a keyword

The single biggest improvement I made to my own skills was rewriting the descriptions. I started with keyword soup:

description: builds, deploys, ships, release, production

That matches nothing cleanly because it reads like nothing. What works is a description that names the situation:

description: Run the full release process for this project — build,
smoke-test the preview, regenerate the production zip. Use when asked
to "ship it", "build the final zip", or prepare a deploy.

Now the trigger contains the words I actually use when I want that outcome. Selection stops being a lottery.

Keep the body short enough to be read

There is a real temptation to write everything down. Resist it. A skill that runs to two thousand words competes with the task for attention, and the instructions at the bottom get the least of it.

My rule is that the core file stays under roughly 150 lines. Anything longer than that gets split: the sequence stays in the main file, and reference material — a long checklist, an API table, an example config — moves into a separate file the model can open only when it needs it. Progressive disclosure applies to instructions exactly as it applies to interfaces.

Encode the arguments you keep having

The best test for whether something belongs in a skill is simple: have I corrected this twice? If I have, it goes in.

Real examples pulled straight from mine:

• Never introduce a state management library for a screen with four fields.
• On client work, RTL is not a follow-up ticket — build both directions from the first commit.
• Do not report success from a build you did not actually run.
• Prefer editing the existing component over creating a parallel one with 2 at the end of its name.

None of these are clever. All of them are corrections I got tired of typing. That is exactly the bar: a skill is a record of your corrections, promoted to a rule.

They compound

The first skill is worth roughly what it took to write. The fifth one is worth considerably more, because they start covering each other's gaps — the release skill assumes the build skill's conventions, the review skill knows what the build skill guarantees.

After a few months my setup does something I did not plan for: it makes my standards portable. When I hand a project to someone else, the skills go with it, and the rules that were previously in my head are now in a folder they can read. That turned out to be the real return — not the typing I saved, but the fact that my process finally exists outside of me.

If you only build one skill, make it the one for your release process. It is the step you do while tired, at the end of the day, when mistakes are most expensive.

Where to start

Pick the task you have explained most often this month. Write down the trigger, the sequence, and the three things people get wrong. Ship it at 80% — you will fix the rest the next time it misfires, and a mediocre skill that exists beats a perfect one you are still planning.