What Are Claude Skills? A Guide for Amazon and Ecommerce Teams

The review that only works when one person runs it

Somewhere on your team there is a review that only comes out right when one particular person runs it. The Thursday search-term pass. The monthly listing audit. The pre-Q4 budget check that catches the campaign nobody has looked at since spring.

That person knows things that are not written down anywhere. Which terms count as branded and which are competitor conquesting. How many clicks a keyword needs before a week of zero sales means anything. Which SKU families get a different efficiency target because the margin is thinner.

So the review runs when they sit down to run it, and not otherwise. Even when they do run it, the output varies with how they phrased the question that day, so you cannot line up this month's answer against last month's and read the difference as a change in the account.

A Claude skill is a folder of written instructions that gets that knowledge out of one person's head and into something anyone on the team can run the same way. What follows is what a skill actually is, how it differs from a saved prompt, when it is worth the setup cost, and what it takes to get one running against live account data rather than in a chat window.

Quick answer

• What it is. A folder of plain-language instructions that teaches Claude to do one specific task the same way every time. One required file, SKILL.md, written as prose. No code needed to write one.
• How it fires. You do not summon it by name or flip a switch. You ask for the task in normal words, and Claude recognises that one of its installed skills matches, then loads the full instructions.
• What you get back. The Thursday review stops depending on the one person who knows how to run it, and this month's output is comparable to last month's because the logic held still between runs.
• What it can carry. Reference documents such as your branded-term list and your per-SKU efficiency targets, output templates, and scripts for the mechanical steps that should never be left to a model's judgment.
• When it is worth building. The task repeats on a real cadence and the standard is already settled. If the team is still arguing about the approach, a skill only freezes the argument in place.
• The risk to weigh. A bad prompt gives you one bad answer and you notice it. A bad skill applies a wrong standard consistently, in every account, on every run.

How you use a skill

From where you sit, using a skill is close to invisible, which is the point.

You install it once. A skill is a folder, so it gets added to your Claude environment the way you would add any set of files. After that it sits there, dormant, costing nothing until it is needed.

You ask for the task in plain language. You say "run the search-term review on this account" the way you always would, and Claude recognises that one of its installed skills matches what you just asked, and pulls in the full instructions to do it. That recognition is automatic, and it is why the skill's description matters so much, which we come back to below.

You review the output. The skill produces the review to the standard you wrote into it. If it can take an action, that action waits for your approval to begin with. Your job shifts from doing the review to checking it, which is the shift that gives you the time back.

How you create a skill

Creating one is less technical than it sounds, because most of the work is not technical at all.

A skill is a folder with one required file inside it, called SKILL.md. That file has two parts: a short header that names the skill and describes when to use it, and then the instructions themselves, written as plain prose. You write those instructions the way you would brief a capable new hire who has never seen your account: the order of operations, the thresholds, the vocabulary, and what to do when the data is ambiguous. That prose is the skill. There is no code required to write one.

Two things make the real difference between a skill that works and one that does not, and neither is technical:

• The description is the trigger. Claude decides whether to use a skill from its description alone, so that line has to say what the skill does and when to use it, in the words you would use when you want it. A vague description means a skill that never fires. More on this below, because it is the single most common reason a skill sits unused.
• Settling the standard is the work. Writing the file takes an hour. Deciding what the review should do, which terms are protected, what counts as material, when to escalate instead of act, is the part that takes real thought, and it is thought you do once instead of every Thursday.

When you are ready for real examples, Anthropic keeps a public repository of skills at github.com/anthropics/skills and documents the format in its Agent Skills overview.

When a skill is the right tool

A skill is not always the answer. It earns its setup cost when a task is both repeated and settled. The clearest signals:

• You run it often. More than a handful of times, on a real cadence. A genuine one-off is faster to just ask for.
• The standard is decided. You can state out loud how the task should be done. If the team is still arguing about the approach, codifying it only freezes the argument in place.
• The output should not drift. You need this month's result to be comparable to last month's, which a fresh prompt each time cannot promise.
• Someone other than you needs to run it. The knowledge currently lives in one head, and the point is to get it out.

When those are not true, reach for something lighter. A one-off question is a prompt. A standing preference like "always write in this tone" is a custom instruction or project setting. A skill is for a procedure you repeat to a standard you have settled.

The warning that matters: a bad skill is worse than no skill. A bad prompt gives you one bad answer and you notice it. A bad skill applies a wrong standard consistently, in every account, on every run, with the quiet confidence of something written down. The discipline that setup buys you is only worth having once the standard underneath it is right.

Skills versus prompts, custom instructions, and fine-tunes

These four get used interchangeably, and they solve different problems. The short version:

• A prompt is a single instruction in a single conversation. Fastest tool you have, leaves nothing behind.
• A saved prompt library is a set of those, stored somewhere findable. Consistent wording, but a person still has to go get it and paste it.
• A custom instruction or project context is standing context applied to everything in a workspace. Ideal for a tone or a rule, a blunt instrument for a nine-step procedure, because it is always on rather than matched to the task.
• A fine-tune teaches the model new default behaviour by training it on many examples. It needs real training data and engineering, and it shifts how a model behaves across a whole class of task, rather than encoding one team's Thursday review.

A skill sits in the useful middle: it carries a procedure rather than a preference, it brings its own supporting files, it can hand a mechanical step to a script, and it stays inert until the task calls for it.

What else can live in the folder

Most people never need more than SKILL.md. But once a skill grows, three optional subfolders keep that file from turning into a novel, and it is worth knowing they exist.

• references/ holds documents the model should consult: your branded-term list, your per-SKU efficiency targets, your match-type conventions. The model reads them when the task needs them rather than carrying them in every conversation.
• scripts/ holds the deterministic steps, the parts that should never be left to a model's judgment: deduping a report, rolling spend up by campaign, flagging rows below a click threshold before any of it reaches the model.
• assets/ holds templates the output should follow: a summary format, a column spec for a sheet.

The header at the top of SKILL.md carries two required fields, a name and a description, in a short block of structured text called YAML frontmatter. You do not need to know the format in depth; a real example from the repository above shows the shape in a glance. The description is the field that matters, and it earns its own section next.

Why the description decides whether your skill ever runs

Here is the one piece of mechanics worth understanding, because it explains most skills that quietly never work.

When Claude starts up, it reads only the name and description of every installed skill. Not the instructions, not the reference documents, not the scripts. Just those two lines. That is enough for it to know a skill exists and roughly what it covers, without spending attention on skills that are irrelevant right now. When your request matches one, it reads the full SKILL.md and works from there.

So the description works as a trigger rather than as documentation for a human, and it is the only part of the skill the model can see when it decides whether to use it. Write it as a match condition: say what the skill does, and say when to use it in the words a person uses when they want it. "Reviews search-term reports" is weak. "Use when reviewing an Amazon search-term or search query performance report to find wasted spend, harvest candidates, or new negatives. Triggers on 'run the search-term review', 'find wasted spend', 'what should we negative out'" is a description that will fire. If you get one thing right in your first skill, get this right.

A skill an ecommerce operator might build

Take the weekly search-term review, since almost everyone has some version of it.

SKILL.md carries the description that makes it fire (the report types it handles and the phrases someone uses when they want it) and then the procedure: the lookback window, the minimum clicks before a keyword with zero sales counts as evidence, the order of operations, what to escalate rather than decide, and the output format. It says what to do when a term is high-spend and high-conversion but off-brand, because that is the judgment call the whole review turns on.

references/ holds the branded-term and competitor-term lists, the efficiency target per SKU family, and your team's negative keyword match-type conventions. assets/ holds the summary template and the column spec for the bulk sheet. scripts/ holds the aggregation over the raw search terms report export: dedupe, roll spend up by match type and campaign, flag rows below the click threshold before any of it reaches the model.

Nothing exotic. That is the point: the review one person already does well, written down.

A skill still needs somewhere to run

A skill is a set of instructions, so it needs three things before it changes anything about your week: a place to run, a schedule, and access to real account data. Running one by hand in a chat window is still you sitting down to run it, with your exports and your copy-paste. That gets you a better version of the same manual loop rather than a workflow. More on what general-purpose models can and cannot do inside a live ad account: can Claude manage Amazon ads and using LLMs to build Amazon ads workflows.

Qore, our product for turning a review you do by hand into a workflow that runs itself, is where an operator runs skills against live marketplace data. The logic is inspectable and can be locked, so the same inputs return the same output. It runs on a schedule or across an account roster rather than when someone remembers. Q, the assistant inside Qore, helps you draw the skill out in the first place.

On actions, the useful thing to understand is that approval is a setting rather than a permanent state. A new skill starts with every account change held for your sign-off, which is the right default while you are still learning whether its calls match yours. As you watch it run, you tighten the rules until they are conservative enough to trust with the action itself: narrow the scope, raise the thresholds, carve out the cases you always want to see. What is left is the set of changes you would have approved anyway, and letting the skill make those on its own while escalating the rest is the point of having written the standard down. Most teams end up mixing the two inside one skill rather than choosing between them.

The limits. Qore codifies a standard, it does not invent one; if the standard is not settled, that conversation still has to happen. Q helps you shape it and will not decide your strategy. A workflow reads, analyses, and can make an approved change on any account regardless of what runs the bids; if a third-party automation later overwrites that change, the limitation is that tool's, and continuous always-on execution is Qinetix, a separate product. Qore is in open beta; you can sign up here. More in what is Qore.

Start with the task you are tired of repeating

A skill is a folder of instructions the model reads when it is relevant. That is the whole idea, and it stays that simple in practice. The question is rarely whether you could build one. It is whether the task in front of you is repeated enough, and settled enough, to be worth writing down.

Write the description first, as the sentence that should make it fire. Write the procedure the way you would brief a new hire. Move the deterministic step into a script and the documents into references/. Then run it a few times against real data and edit it, because the first version of any skill is wrong in ways you cannot predict from the armchair.

The bottom line for ecommerce teams

• Pick the task you are quietly annoyed about doing again. The weekly search-term review, the listing audit, the budget check. That annoyance is the signal that it is repeated enough to be worth writing down.
• Write the description first. It is the only part Claude sees when deciding whether to use the skill, so it has to read as a match condition rather than a summary.
• Settle the standard before you write the file. The hour of writing is trivial. Deciding your click floor, your protected terms, and your escalation rule is the actual work.
• Split big skills into small ones. If the description needs several "and also" clauses to be accurate, that is two skills.
• Move the deterministic steps into a script. Deduping and rolling spend up by campaign should never depend on a model's judgment.
• A skill in a chat window is still manual work. To change your week it needs a schedule and access to live account data.

For examples before you write your own, the Anthropic skills repository is the best starting point, and AI for Amazon ads covers the wider landscape.