AI for Excel: How to choose between projects, skills, and custom instructions

The first time you open the settings menu of an AI assistant, you are handed a set of choices nobody really prepared you for.

Custom Instructions, Projects, Skills… oh my! 😱 Then there may be some kind of agent workspace for longer jobs, which in Claude is called Cowork. Each one is presented as a way to make you faster, but none of them does a particularly good job explaining when it is the right tool or when it is completely unnecessary.

So most people do what you would expect. They use whichever feature they happen to discover first, and then they use it for everything. The person who finds Custom Instructions ends up with a 1,200-word operating manual in a box that was really meant for a few standing preferences.

That is not a disaster, exactly. It is more like a quiet tax you keep paying every time the assistant has to sort through the wrong kind of context.

The whole thing gets easier once you stop thinking about product features and start thinking about the kind of job you are trying to do.

One note before I get into it: I use Claude, where all four of these exist under the names I am using here. Other assistants use different words for roughly the same ideas, and some do not have all four yet. The names will keep changing. The jobs underneath them probably will not, which is why the jobs are the part worth learning.

Start by asking whether you need an AI feature at all

Before I think about Custom Instructions, Projects, Skills, or Cowork, I ask a more basic question:

Could I write this process down once and have it run correctly every time, with no judgment calls?

If the answer is yes, this may not be an AI problem… it may just be a Power Query problem.

The monthly GL export that arrives in the same shape every month doesn’t need a prompt so much as it needs a refresh button. That work is repeatable, auditable, and inexpensive, and there is a decent chance it will still be running correctly three years from now, long after the model you are using today has been renamed, replaced, or deprecated.

I say this to finance teams fairly often, and you can almost watch the room relax. There is so much pressure right now to put AI somewhere, anywhere, that it can be a relief to hear the boring answer is still the right one for a good share of the work.

AI starts to earn its keep on the parts you have never quite been able to code: the vendor whose dates arrive in six different formats, the export that is almost but never exactly the same shape twice, or the process that mostly follows rules until one weird exception blows the whole thing up.

That is the territory the rest of this post is about.

Custom Instructions are for preferences you want applied every time

Custom Instructions are for the basic choices you want the assistant to carry into any workbook from the beginning.

Maybe you prefer dynamic array functions over legacy formulas. Maybe you want structured references, consistent naming conventions, two decimal places on currency, and absolutely no merged cells. Those are all good candidates because they are lightweight, global preferences that should apply almost everywhere.

The trouble starts when Custom Instructions turn into an essay. Once you are cramming in background material, examples, procedures, exceptions, and reference documents, you are asking that feature to do too much.

At that point, the material is probably one of two things. If it is knowledge the assistant needs to refer to, it belongs in a Project. If it is a process the assistant needs to follow, it belongs in a Skill.

Projects are for the knowledge sources you need again and again

A Project is where you keep the context that needs to be in the room whenever you sit down to do a certain kind of work.

That might be a style guide, a data dictionary, a chart of accounts, last quarter’s deck, or any other material you keep uploading into fresh chats over and over.

That repeated uploading is usually the tell. If you have attached the same three files four times this week, you have already built a Project in your head. You just have not put it in one place yet.

There is one tradeoff here. Projects are often easier to use from the assistant’s main interface than from inside spreadsheet add-ins, so it is worth thinking about where the work will actually happen before you commit a workflow to one.

Even with that limitation, it is usually better than paying the upload tax forever.

Skills are for the process you have never quite been able to automate

This is probably the feature people underuse the most, and it may be my favorite of the four.

A Skill is useful when the work is mostly repeatable, but some part of it has always resisted traditional automation. You know the steps. You have tried to write the rules. There are just enough exceptions that the process never quite holds together.

Cleaning vendor files is the obvious example. Every vendor formats dates however they feel like it, and every month there is one new variation you did not anticipate. You can build the Power Query, and you probably have, but it breaks anyway and you end up fixing the exceptions by hand.

File conversion is another example. So is design work, where you keep having to explain the same fonts, brand colors, layouts, and formatting choices every time you want a deliverable to look like it came from you.

The rough test I use is this: if there are no edge cases at all, go code it. If there is nothing but edge cases, just have a conversation. A Skill lives somewhere in the middle.

An agent workspace is for building several things at once

The fourth category is a little different. Custom Instructions, Projects, and Skills all shape how the assistant works. An agent workspace is more about what gets produced.

You go there when the output is not one answer in a chat window, but a whole set of finished deliverables. Maybe you need the cleaned workbook, the summary deck, the one-page brief, and the email to accounting, all from the same run.

The part that took me a while to see is that the Skills become the plumbing, and the workspace calls them. In other words, skills are the how and Cowork is the what.

Here is what that might look like in one real workflow.

Your Custom Instructions say not to merge cells and to prefer dynamic arrays. Your Project contains the finance style guide and the data dictionary. Your Skill explains how to clean and validate the vendor spend file, including the edge cases. Then the agent workspace runs the vendor file, builds the summary deck, and drafts the email.

Once you see the layers that way, the distinctions become much less abstract.

A quick check before you build any of them

You do not need to design this whole system in advance. Usually, you just need to notice what you are already repeating.

If you keep restating the same preference, that probably belongs in Custom Instructions. If you keep uploading the same files, use a Project. If you keep explaining the same procedure, turn it into a Skill and write it down the way you would brief a capable new colleague who cannot read your mind. When you keep assembling the same larger set of deliverables by hand, that is when an agent workspace starts to make sense.

And if you are paying an AI model to repeat arithmetic or cleanup steps that a refresh button could already handle, go back to Power Query and do not feel bad about it.

The real cost of all this repetition is attention, even though it never appears on an invoice. Product names will change, features will merge, and some will disappear entirely, but the framework should still hold up because it is not really about the features. It is about recognizing the different ways work repeats, changes, and breaks.

I put the full framework into a short guide below so you can keep it nearby.

And if your team is trying to get more out of Excel without sitting through another generic feature tour, that is the kind of work I do at Stringfest Analytics: