Where and How: A Plain-Language Guide to Projects, Instructions, and Skills

Most people start using AI the same way: open a chat, ask a question, get an answer, close the tab. That works for one-off tasks. But the moment you catch yourself pasting the same background into a new chat for the third time, you've hit the limit of chat. Every new conversation starts from zero.

Three features fix that: Projects, Instructions, and Skills. They might sound technical, but they aren't. They're closer to how you'd onboard a new colleague: here's where the documents live, here are the house rules, and here's exactly how we do this task every week. It’s only once you’ve given that information to your new colleague that you can actually offload work to them.

The Workshop

We recently helped run a two-day AI workshop for a contract manufacturer in a regulated industry. Day one was for senior leadership. Day two was a four-hour, hands-on session for managers, and it had a simple promise: by the end of the afternoon, every person would leave with a Project and a Skill they built themselves and could use on Monday.

The rules for the day mattered as much as the tools. Everyone worked from training files or approved, non-confidential documents. Nothing built that day would touch a quality record. And for every answer Claude gave, the habit was the same: open the source and check it.

Most of the afternoon was people building on their own laptops. We taught one idea, they tried it, and we moved on. Here's what we taught.

Projects: Where the Work Lives

A Project is a workspace for one area of work. It holds three things:

1. Instructions. How Claude should work in this space: who the reader is, what format to use, and what the red lines are. You write them once.

2. Reference files. The approved documents it works from, such as templates, past examples, or explainers.

3. Chats. Every conversation inside the Project starts already knowing the instructions and the files. No more pasting the same background over and over.

The rule of thumb we gave managers: use a Project when you keep coming back to the same documents for the same kind of work. Projects can also be shared, which is where they really pay off. Share one with your team, and everyone starts from the same sources and the same rules.

We showed three examples drawn from the client's own workflows:

Business development: proposals drafted from approved past proposals and capability statements.
Training: plain-language explainers for new hires, built from approved procedures. A training aid, never a substitute for the procedure itself.
Regulatory: a reading room of public regulatory guidance that answers with page numbers, so every answer can be checked.

Instructions: The House Rules

Instructions are the most important part of a Project, and the part people tend to rush. They're a good prompt made permanent. Every chat in the Project follows them without you having to repeat yourself.

We gave managers a fill-in-the-blanks template:

You are helping the [team] with [workflow]. Use the files in this Project as the source of truth. Always: [format, length, tone]. If something is not in the files, say "Not in source." Never: [your red lines]. If you are unsure, ask me a question instead of guessing.

Two lines in that template do most of the work. "If something is not in the files, say 'Not in source'" makes gaps visible instead of invented. "Ask me a question instead of guessing" turns a confident wrong answer into a quick clarifying question.

There's also a shortcut. If you've already written a strong prompt for the task, give it to Claude and ask it to turn the prompt into Project instructions.

Then test it. We had everyone ask their Project three questions their team actually asks, and then run a short loop on each answer: 1. Validate. Open the file. Is the answer really there? 2. Refine. Wrong format or tone? Fix the instructions, not the answer. 3. Prove. Ask Claude to quote the line in the file that supports its answer. If it answers from outside the files, tighten the instructions and ask again.

"Fix the instructions, not the answer" was the line that stuck. Editing one answer fixes one chat. Editing the instructions fixes every chat after it. That's why one of our "done" criteria was that you'd changed your instructions at least once.

Skills: How a Task Gets Done

If a Project is a place, a Skill is a recipe. It's a written-down way of doing one task, such as a weekly status report, a first-pass review checklist, or a process you explain to every new hire. Claude follows it the same way every time.

The key difference is that you go to a Project, but a Skill comes to you. Once it's switched on, Claude picks it up in any chat when the task comes up. You just ask for the weekly status report, and the Skill brings the steps and the format.

The test for whether something should be a Skill is simple: can you describe what a good result looks like? If yes, it can be a Skill.

A good Skill has six parts:

Name: short and clear, like "Weekly client status update."
When to use it: the request that should trigger it.
Steps: what Claude does, in order.
Output format: sections, length, tone.
Checks: what to verify before finishing. This is where a team's quality mindset goes.
One good example: what a great result looks like.

You don't have to write a Skill from scratch. In the workshop, people described how they do the task today, pasted in a good past example with anything confidential removed, and asked Claude: "Help me turn this into a Skill I can download. Ask me what you need to know." Then came the step we wouldn't let anyone skip: read every line. Fix what's wrong, and delete what you don't understand. Never switch on a Skill you haven't read, including your own.

The last step was to test it in a fresh chat with new input and check whether it followed the steps and the checks.

Sharing a Skill takes a little more discipline than sharing a Project. Test it on three different inputs and with a colleague. Name one owner who keeps it current, with a version line at the top. Share it with your team first, while organization-wide Skills go through an approved route and are published by an admin. Then review it every 90 days: is it still right? Update it or retire it.

Project Is Where. Skill Is How.

That one sentence was the distinction we most wanted the room to leave with. When people weren't sure which one to build, we gave them two questions:

Do I keep coming back to the same documents? Build a Project.
Do I keep doing the same steps? Build a Skill. The best setups use both. In the last build of the afternoon, managers opened the Project they'd built and asked for the task their Skill was written for. The check was simple: the format should come from the Skill, and the facts should come from the Project's files. Then they swapped laptops with a neighbour to see whether someone else could get a similar result from their setup. If they could, the setup worked. If they couldn't, the instructions or the Skill still had a gap.

The Bigger Lesson

None of these features requires technical skill. A Project is a well-organized folder with clear house rules. A Skill is the checklist you'd hand a new teammate. Writing good instructions is the same work as writing a good process document. Most managers already know how to do all three; they just hadn't pointed that knowledge at an AI assistant before.

The bigger shift is what happens to a team's know-how. When the way a task gets done lives in one person's head, the team depends on that person. When it lives in a shared Project and a reviewed Skill, anyone on the team can do the task the same way, and the AI can help them do it. The goal we set for the room wasn't to finish the afternoon with something impressive. It was to build one thing small enough to use on real, approved work the following week. Built in an afternoon and used for two weeks is how it sticks.