# Claude Projects vs Claude Skills: which one you actually need

**Author:** John Morabito (Founder, /winston)
**Published:** September 19, 2026
**Reading time:** 11 minutes
**Canonical:** https://www.winstondigitalmarketing.com/playbooks/claude-projects-vs-claude-skills/

Claude Projects and Claude Skills make the same promise from the outside: set the thing up once, stop repeating yourself. They keep that promise at different layers, and choosing wrong is how a team ends up with a workspace nobody else can use, or a folder of carefully written files for a job that gets run twice a year.

A Claude Project is a workspace. It holds standing instructions, the reference files you keep coming back to, and the chats that belong to one ongoing effort. Anything you start inside it inherits that background, so you stop pasting the brief into every new conversation.

A Claude Skill is a package. It is a folder containing a SKILL.md instruction file plus whatever scripts and reference files the job needs, and Claude pulls it in when a task matches the description you gave it. It travels, so the same folder runs in Claude Code, in the Agent SDK, and in the app, and it produces the same shape of output no matter who invoked it.

One question settles most cases. Ask what you are actually tired of rebuilding. If the answer is context, the background a conversation needs before it can say anything useful, you want a Project. If the answer is a procedure, the steps you want executed the same way every time, you want a Skill.

## What a Claude Project actually is

You create a Project inside Claude.ai, give it a set of instructions, and upload the files it should have on hand. Every chat you start in that Project reads those instructions and can draw on those files, and the chats stay grouped together instead of scattering through your history. That is the whole feature.

What a Project buys you is continuity. A body of work that runs for weeks has a lot of background that does not change: who the client is, what you already decided, which three documents everyone keeps referring to, what the house style is. Without a workspace, that background gets re-established at the top of every conversation, badly and slightly differently each time. With one, it is already there.

The constraint that matters is that a Project is configured in a user interface and lives inside the app. There is no folder to export, no file to put under version control, and nowhere for a script to run.

## What a Claude Skill actually is

A Skill is a directory. The required piece is SKILL.md, which carries two things: a description telling Claude when this Skill applies, and the procedure itself. Alongside it you can put scripts for the steps that have to come out the same way every run, and reference files the model reads when the procedure calls for them. Claude reads the description, decides the task matches, loads the Skill, and follows it.

Because a Skill is files, everything you already know how to do with files applies. It goes in a repository. Changes to it get reviewed. Two people get identical copies. You can test it against a known input and see whether the output is what you expected. The full build guide, including which workflows are worth packaging first and how to split instructions from scripts from references, is in [Claude Skills for SEO teams](https://www.winstondigitalmarketing.com/playbooks/claude-skills-for-seo-teams/).

The constraint here runs the opposite direction. A Skill has no memory. It does not know what you discussed last week, does not accumulate a history of the account, and starts from its own files every time it runs. That is a feature when you want consistency and a problem when the job genuinely depends on what came before.

## The question that decides it: context or procedure

Most of the confusion comes from the overlap. Both let you write standing instructions. Both let you attach files. So people look at the two feature lists, see the same two items at the top of each, and read the difference as one of degree. The difference is in what kind of thing you are trying to reuse.

**Context** is the background that has to be true for the work to make sense. The brand voice guide. The client's product catalog. The strategy you agreed on in March and keep having to restate. The transcript of the kickoff call. None of that is a set of steps. It is the situation the steps happen in.

**Procedure** is a sequence with a defined output. Take this keyword export, cluster it by intent, check it against the live sitemap, flag the cannibalization, and hand back a mapping table. There is a first step, a last step, and a right answer about what the result should look like.

The fastest test I know: try to write the thing down as a numbered list that ends in a specific artifact. If it comes out as a list, it is a procedure and belongs in a Skill. If what you produce instead reads like a briefing document, it is context and belongs in a Project.

There is a second test worth running when the first one is ambiguous. Ask whether the value depends on somebody remembering to apply it. A rule that only works when the person at the keyboard recalls that it exists is a procedure that has not been written down yet.

| Dimension | Claude Project | Claude Skill |
|---|---|---|
| What it is | A workspace with shared instructions and files | A folder of instructions, scripts, and references |
| What it reuses | Context | Procedure |
| Where it lives | Inside Claude.ai | Any Claude runtime that loads Skills |
| How you build it | Configured in the app | Written as files |
| Version controlled | No | Yes, it is a directory |
| Can run scripts | No | Yes |
| Groups your chats | Yes, that is the point | No |
| How it starts | You work inside it | Claude loads it when the task matches |
| Sharing | Whoever can open the workspace | Copy the folder anywhere |
| Best when | An ongoing effort needs the same background | A repeatable job needs the same steps |

## Running both, which is the normal case

The framing as a versus question is a search habit more than a real fork. On any account we run for longer than a month, both exist and they do different jobs.

The Project carries the account. Brand voice, what we have shipped, the findings from the audit, the current quarter's priorities, the things this client has asked us never to do. That is context, it changes slowly, and it needs to be present in every conversation about the account.

The Skills run the jobs. Keyword mapping, the on-page rewrite, the monthly report. Each one is the same artifact produced the same way, so each one is a procedure with a folder of its own. You work inside the Project, ask for the deliverable, and the Skill fires because the task matched its description. The Project supplies who this is for. The Skill supplies how it gets made.

> The two failure modes are mirror images. A Project whose instructions have grown into two thousand words of numbered steps is a Skill that never got written, and the steps drift because nothing enforces them. A Skill stuffed with one client's specifics is a Project in the wrong clothes, and it becomes useless the moment you try it on a second account.

## What does not transfer between them

Four things people expect to carry across, which do not.

- **A Project does not travel.** There is no export, no folder, no file that represents it. The instructions and the uploads live in the app. If you decide the same setup should run somewhere else, you rebuild it by hand and hope you remember everything that was in it.
- **A Skill does not remember.** Every invocation starts from the files in the folder and nothing else. If the job needs to know what was decided in last month's call, that knowledge has to be written into a file the Skill reads, or supplied by the Project it is running inside.
- **Chat history is not a knowledge base.** This one catches people. After enough conversations in a Project it starts to feel as though the model knows the account, and then a new chat proves it does not, at an inconvenient moment. Instructions and uploaded files are what carry reliably. If a decision matters, write it into a document rather than trusting that it was mentioned somewhere.
- **Scripts have nowhere to live in a Project.** Every workflow has a few steps that have to come out exactly right rather than close enough: parsing an export, deduplicating a list, validating a block of markup, checking that the numbers add up. Those steps want code, and only one of these two formats has a place to put code.

## Why a Skill outlives the person who wrote it

The strongest argument for the Skill format has little to do with any one person's productivity. It is about who owns the capability.

A Project is shaped by whoever set it up, and the reasoning behind its instructions stays in that person's head. The instructions say what to do and almost never say why. When that person moves on, the Project keeps working in the sense that it still loads, and nobody left can tell you whether the rule on line four is load-bearing or a workaround for something that got fixed a year ago. So it either gets followed superstitiously or deleted, and both of those are losses.

A Skill is a file. Someone who was not in the room can read it, question a step, propose a change, and have that change reviewed the way any other change gets reviewed. You can run it against a known input and check whether the output is still right. You can look at its history and see when a rule was added. That is the difference between a capability a company owns and one it is renting from an employee, and it is the same argument that makes a shared [prompt library for a marketing team](https://www.winstondigitalmarketing.com/playbooks/prompt-library-for-marketing-teams/) worth the effort, applied one layer up the stack. You can diff a Skill. There is nothing to diff in a Project.

## When a Project is the right answer and stays the right answer

None of the above means everything should become a Skill. Plenty of work is genuinely context-shaped, and forcing a procedure onto it produces rigid output and wasted afternoons.

- Research that runs over weeks, where each session asks a different question of the same material.
- One client account, one book, one investigation. A single ongoing effort whose value is that everything stays together.
- Any work where the output is a different shape every time. If you cannot describe the artifact in advance, there is no procedure to write.
- Anything you will run four times total. Writing a Skill costs real time, and a job that infrequent will never pay it back.

Building a Skill for a job you do twice is a hobby, and it is worth saying so out loud before the afternoon disappears into it.

## Promoting a Project to a Skill

The migration runs in one direction in practice. Teams prototype inside a Project, find out what the work actually requires, and then package the parts that turned out to be repeatable. Four signals tell you it is time.

1. You have typed the same correction into three separate chats. An instruction you keep reissuing belongs somewhere permanent.
2. Someone else produced the deliverable and it came back wrong. That is proof the procedure lives in your head rather than anywhere a colleague can reach.
3. There is a step that must never be skipped. A compliance review, a fact-verification pass, a check against a rule list. Gates belong in a procedure that runs them, not in a reminder somebody might scroll past.
4. The volume went up. Producing the thing once, interactively, is a conversation. Producing it forty times this month is a process with a conversation stapled to the front.

The migration itself is mostly sorting. Open the Project instructions and split them into two piles: the sentences that read like steps, and the sentences that read like background. The steps become a numbered procedure in SKILL.md. The bulky reference material moves into a references folder so the main file stays short enough to be followed. Anything that has to be exact becomes a script. What is left in the Project is what should have been there from the start, which is context.

If the comparison you are actually running crosses platforms rather than staying inside Claude, the feature-level breakdown against OpenAI's packaging format is in [Custom GPTs vs Claude Skills](https://www.winstondigitalmarketing.com/playbooks/custom-gpts-vs-claude-skills/), and the four-question version with worked examples is in the [custom GPT vs Claude Skill decision tree](https://www.winstondigitalmarketing.com/playbooks/custom-gpt-vs-claude-skill-decision-tree/).

## Where to start

If you are setting this up from scratch, the order that wastes the least time:

1. Make a Project for each body of work you return to weekly. Put the background in it and nothing else. This costs an hour and removes the re-explaining tax immediately.
2. Work in it for a few weeks and pay attention to what you repeat. The corrections you keep retyping are the specification for your first Skill, written for free by the work itself.
3. Build one Skill, for the job you do most often and care about most. One is enough to learn the format, and it is the only honest way to find out whether the procedure you thought you had is actually a procedure.
4. Put it where the team can reach it. A Skill on one laptop has the same failure mode as a Project.
5. Go back to the Project instructions and delete whatever the Skill now handles. Leaving both copies in place is how the two versions start disagreeing.

Most teams get stuck between steps two and three, because writing the first Skill means admitting the procedure was never as defined as it felt. That discomfort is the useful part. Whatever you cannot write down clearly enough for a model to follow is also the part a new hire has been guessing at.

Packaging this work properly, including deciding which jobs deserve a Skill and which should stay conversations, is what our [custom GPTs and Skills service](https://www.winstondigitalmarketing.com/services/ai-marketing/custom-gpts-and-skills/) does with clients.

## Frequently asked questions

### What is the difference between a Claude Project and a Claude Skill?

A Claude Project is a workspace inside Claude.ai that holds standing instructions, uploaded reference files, and the chats belonging to one ongoing effort, so every conversation you start there inherits the same background. A Claude Skill is a folder containing a SKILL.md instruction file plus any scripts and reference files the job needs, which Claude loads when a task matches the description you wrote for it. The Project is where context lives. The Skill is where procedure lives. A Project is configured in the app and stays there. A Skill is a set of files, so it can be version controlled, reviewed, copied, and run in Claude Code or the Agent SDK as well as in the app.

### Can a Claude Project run scripts or call external tools?

No. A Project gives Claude instructions and files to read, and that is the whole surface. There is nowhere in a Project for a script to live, which matters more than it sounds, because every workflow has a few steps that have to be exact rather than approximately right. Parsing an export, deduplicating a list, validating a schema block, checking a total. Those steps belong in code, and the Skill format has a place to put code while the Project format does not. If your workflow has a step you would be uncomfortable seeing a model improvise, that step is telling you to build a Skill.

### Do Claude Skills replace Claude Projects?

No, and teams that treat them as competing options usually end up with worse versions of both. They solve different problems. A Skill has no memory of what happened last week and no way to accumulate the history of an account, because every invocation starts from its files. A Project has no way to guarantee that a sequence of steps runs in order, because it only supplies background. The common setup is a Project that carries the context for one client or one body of work, with Skills invoked inside it to run the repeatable jobs. The Project supplies the who and the what. The Skill supplies the how.

### Can my team share a Claude Skill?

Yes, and this is the strongest practical argument for building one. Because a Skill is a directory of plain files, you can put it in a repository, review changes to it the way you review code, and give everyone the same copy. Two people running the same Skill get the same procedure, and when the procedure turns out to be wrong you fix it in one place. A Project is shared only in the sense that people in the same workspace can open it, and nothing about it explains why it was set up the way it was. That difference decides whether a capability belongs to the company or to whoever built it.

### When should I turn a Claude Project into a Skill?

Watch for four signals. You have typed the same correction into three separate chats, which means the instruction belongs somewhere permanent. Someone else on the team produced the same deliverable and it came back wrong, which means the procedure was never written down. There is a step that must never be skipped, such as a compliance check or a verification pass, which needs a procedure rather than a reminder. Or the volume went up, because doing the job once interactively is a conversation and doing it forty times is a process. When you migrate, pull the parts of your Project instructions that read like steps into a numbered procedure in SKILL.md, move the reference material into a references folder, and leave the genuine background behind in the Project.