Claude Skills Explained: A Saved Way of Doing a Task

The distinction in one line: a project holds what Claude should know; a skill holds how a task should be done. Knowledge versus procedure. And that is why ready-made skills exist for Excel, Word, PowerPoint and PDF - working with files is a procedure, not knowledge.

The difference, in a table

They do not compete - they complement. A project holding your price list and a skill that knows how to produce a well-structured spreadsheet together give you what neither gives alone.

Why this matters for file work

Producing real files is not a matter of understanding - it is a matter of executing correctly: the workbook structure, the heading formatting, how a spreadsheet with several sheets is saved.

That is exactly what a packaged skill contains, which is why the result is consistent rather than improvised on each request.

And what that changes for you as a user: usually nothing to do. The request is the same request - "return a spreadsheet with these columns" - and the procedure loads by itself. Knowing it exists mainly changes the expectation: ask for a file, not for text.

When it is worth creating your own

The test is narrow: a task done repeatedly, the same way, with the same steps.

Suits it:

• Cleaning a monthly export from the same system - same columns, same corrections.
• Producing a report in a fixed structure clients are used to.
• Extracting the same fields from the same kind of document.

Does not suit it:

• A task that varies each time - a good request is better.
• Something done once or twice. The procedure will cost more than it saves.
• Knowledge rather than procedure - that belongs in a project. "Our clients are accountants" is not a procedure.

The common mistake: packaging a procedure before it has settled. If you are still changing the approach each time, there is nothing to package - do it manually a few times and see what genuinely recurs.

What to know first

1. A saved procedure also performs the error inside it

This is the important point. If the procedure contains a wrong assumption - a column that was added to the export, a date in the wrong format - it will perform that error with perfect consistency every time.

And that is more dangerous than a one-off mistake, because after a few runs people stop checking.

What to do: the same check as always - one row against the source, and a count of rows in versus rows out. Even after the procedure is "proven".

2. Sources change

A procedure built around a particular export breaks when the system changes that export. Vendors change columns without notice.

The tell: the result looks right but one column is empty. So it is worth checking after every update to the system you export from.

3. Someone else's skill is code you are running

The same judgement as any add-on you install: who wrote it, and what it does.

An official skill for document work and a skill someone sent as a link are not the same decision. If the source is unclear, that is the answer.

What it is not

• It is not automation. A skill does not start itself - someone starts a conversation. It improves what happens in the conversation rather than removing the need for one.
• It does not replace connecting to systems. A procedure knows how to process; it does not fetch the data.
• It is not knowledge about your business. That goes back to a project.

The practical order

1. Start with a good request. Most tasks are solved that way.
2. If it recurs, put the knowledge in a project.
3. If the steps are identical every time, it is a candidate for a skill.
4. If it needs to run without you asking, that is automation - and none of these three.

That order matters. People skip to step 3 and build a procedure for a task that has not settled - exactly the same mistake as automating a process you cannot write as a list of steps.