Lunch & Learn

Cowork, Skills and Projects

Three tools. Three jobs. Here's what each one is actually for, and which one to reach for.

Click through the tabs below and copy any prompt straight into your own Claude account.

Presented by Brandon Burns, Head of Experience at BusinessAI

Watch first

What to expect to get out of this webinar

A quick two and a half minutes before you dive in: what this module covers, what you will walk away with, and how to use this page while you watch.

Watch the recording

Watch this week's webinar and follow along with the steps below

Play the recording here, or open it in a new tab if you prefer.

Book an introduction to BusinessAI Open recording in YouTube

1 hr

A daily inbox pass

The support inbox is the single job most people in the room say eats the most time. Cowork turns that hour into a few minutes of review.

3 files

Is enough to start a Project

FAQs, a policy and a tone guide. You do not need a perfect knowledge base, you need the three documents you keep re-explaining.

1 rule set

Behind every Skill

Write the rules once and the output stops drifting between people, weeks and moods. Consistency is the point, not cleverness.

15 min

To build your first one

Every example on this page was built live in under a quarter of an hour. Start with the task you did twice this week.

Projects

Remembers the background

A Project is a dedicated space with its own knowledge base and its own instructions. Upload the FAQs, policies, contracts or brand rules once, and every conversation inside that Project already knows them, so you stop re-briefing Claude from scratch every time you open a chat. Reach for a Project when there's an ongoing topic you keep coming back to, a client, a course, a policy area, rather than a single one-off task. The more you use it, the less you have to explain.

You probably need a Project if

You're working on the same thing again next week, not a one-off
You keep uploading the same brief or background every time you open a new chat
You're juggling more than one client or account, each with their own rules (run one Project per client, not one for everything)
Claude keeps seeming to forget what you told it earlier in the conversation

Setup: the knowledge uploaded is the FAQ doc, refund policy, tone guide and product or service list.

Custom instructionsprompt

You are answering as a member of the team, not as an AI assistant. Before responding to any enquiry:

One, check whether the question is answered in the FAQ document, and if it is, use that answer as the source of truth.

Two, if the enquiry involves a refund, exchange or cancellation, always check the refund policy before promising anything, and never commit to a timeframe the policy doesn't guarantee.

Three, match the tone guide: warm, plain English, no corporate language, never over-apologise.

Four, keep replies under 150 words unless the enquiry genuinely needs more detail.

Five, if you don't have enough information to answer confidently, say so and suggest what to check internally rather than guessing.

Sign every reply with the team name, not a person's name, unless told otherwise.

Why this helps: new enquiries get answered with full context and no guesswork, without re-uploading policies every time someone opens a chat.

Have this ready

The three documents you re-attach most often
A short tone guide, even if it is five bullet points
One good past example of the output you want
A note on who the audience is and what they already know

Common mistakes

Dumping the whole shared drive in and hoping for the best
Leaving out the tone guide, then wondering why it sounds generic
Never updating the knowledge when the policy changes
Using one giant Project for every client instead of one each

Other places a Project earns its keep

A tender or grant Project holding past submissions and selection criteria. A compliance Project holding the standards you get audited against. A recruitment Project holding role descriptions, interview questions and your scorecard. Same pattern every time: background you keep repeating, uploaded once.

How to tell it is working

You stop pasting the same three paragraphs of context at the top of every chat, and someone else on the team can open the Project and get an answer that sounds like you wrote it.

Before you build

Six things worth thinking about first

None of this is technical. It is the difference between a setup that quietly runs for a year and one that gets abandoned in a fortnight, and it is the part most people skip.

Start with the task, not the tool

Pick one job you did more than twice last week and write down how you actually do it. That written-down version is your first Project instruction or Skill. If you cannot describe the steps to a new hire, Claude cannot follow them either.

Keep private data where it belongs

Upload the policies, templates and examples you would happily hand a new team member. Leave out anything you would not, and strip customer names and card details from examples before they go into a knowledge base.

A human still signs off

Every example here ends with a review step for a reason. Set the money threshold, the legal wording and the promises a person has to approve, and write that rule into the instructions so it is not left to memory.

Version it like a document

Instructions drift. Date them, note what changed and keep the old one until the new one has run for a week. When output goes odd, the instructions are almost always the cause, not the model.

Measure one thing

Time to first reply, invoices raised without an error, reports out by Friday 4pm. One number, tracked for a month, will tell you more than any opinion about whether it is working.

Teach it once, share it wide

The value shows up when the whole team uses the same Project and the same Skills. One person quietly getting good at prompting is a hobby, a shared setup is a system.

Our team