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.
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.
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.
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.
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.
The people on the call
We run these sessions live every week, build the examples in front of you, and leave the prompts here so you can take them straight back to your own business.
