Where does the SKILL.md file live?

It is a markdown file of instructions that Claude Code reads as a skill. The docs describe skills as either reference material or invocable workflows you trigger with a command such as /deploy, and they can be synced from your Claude settings if you are on Claude Code version 2.1.273 or later.

Is a skill just a saved prompt?

No. A prompt is one message; a skill is a file with a name, a description that acts as its trigger, and instructions, which means you can version it in git and, as an organisation owner, provision it for a team. That makes it behave like an SOP.

What if the fix is slightly different for every client?

Then do not package it yet. Use the decision table in the post: if the steps get reordered per account and the inputs are whatever the client happens to have, you will spend more time maintaining the skill than re-solving the problem.

How to turn a repeat client fix into a Claude Code skill in about three hours

A fix you have done twice is a procedure, and a procedure belongs in a file instead of in your head. That is the whole idea here. The repeat work in automation delivery is narrower than it feels: webhook retries, field mapping, duplicate leads, stale tokens, a sync that fails quietly. Each time you re-solve one from a blank page you pay the thinking cost again.

What a skill actually is

The Claude Code docs say a skill is a SKILL.md file containing instructions, and that Claude can load it automatically when it is relevant or you can invoke it directly with /skill-name. The features overview splits them into two shapes: reference material, or invocable workflows triggered with a command like /deploy.

The Claude help centre adds the part most write-ups leave out. Skills work inside Claude Code, you can turn on your own, and an organisation owner can provision them for a team. Sync from Claude settings needs Claude Code version 2.1.273 or later.

So a skill is closer to an SOP than to a prompt. Portable markdown, versionable in git, shareable. That framing is what makes it worth three hours of your time.

Should you package this fix

Use this table before you open an editor. It is the step people skip, and it is the one that saves the afternoon.

Signal	Package it	Leave it
Times you have done the fix	Two or more	Once
The steps	Same order every time	Reordered per account
The inputs	Named fields, named endpoints	Whatever the client happens to have
The check at the end	A thing you can verify	"Looks fine"
Who else needs it	A teammate or future you	Nobody

Three rows on the left and it is worth building. Two or fewer, write a note in your own docs instead.

The three hour budget

These are my estimates, not measured times.

Write the procedure out in plain sentences, from memory, before touching the file format. About 30 minutes.
Create SKILL.md with a name and a description that says when to use it. The description is the trigger, so write it as a condition, not a summary. About 45 minutes.
Add the specifics: field names, endpoints, the order of operations, the failure modes you have already hit. About 30 minutes.
Dry run it on a sandbox or a copy, never a live account. About 30 minutes.
Commit it, then fix the description based on whether Claude actually picked it up. About 25 minutes.

That is about two hours forty, call it three with interruptions.

The arithmetic, on your numbers

Take the minutes the fix costs you from a blank page, multiply by how often it recurred last year, and compare that total to your build budget plus a maintenance hour per quarter. If the first number is smaller, do not build the skill. If it is twice the second, build it this week. No promise in either direction, just your own two numbers.

For scale on what this looks like when you keep going: my internal agent system runs 8 primary agents and 35 sub-agents, and the useful ones are all procedures that earned their file. More on how I structure that work on the blog.

Limitations

I have not tested a packaged fix across a row of unrelated client accounts, so I cannot tell you how often the description misfires in practice. My guess is that the trigger wording is the fragile part, not the steps.

A skill does not carry credentials, account IDs or permissions. Those stay yours to manage per client, and a skill that assumes one account's layout will quietly do the wrong thing in another.

The docs do not promise a skill will be loaded for a given message, only that Claude can load it when relevant. Treat auto-loading as a convenience and the explicit /skill-name call as the reliable path.

And nothing above is verified for n8n or GoHighLevel specifically. The mechanism is documented; the fit with your stack is yours to prove.

My take

The value is not speed on day one, it is that the procedure stops living in your memory. Write the ugly first version, invoke it on the next occurrence, and let the real run tell you which line was vague. Pick the fix you are most tired of and start with step one.