It's very easy to open Claude, explain what you need, then find yourself explaining much the same thing in a week's time, or it suddenly doing a simple task totally differntly to the last ten times it has. Basically you find yourself feeling like you're starting from scratch, which is totally avoidable. If you're like me, you also see all the little icons and features in the interface and really want to get round to using them but never make time.
Here I'm going to go over the basic featureset of Claude, and I hope it's useful.
I've written about why businesses need a shared brain, and some of this is how I'd put that idea into practice with Claude, but you don't really even need to go that deep to make it more useful.
Know what each feature is for
A quick summary...
| When you need to… | Use… |
|---|---|
| Think through a question or get a quick answer | A conversation |
| Keep context for ongoing work or an area of responsibility | A project |
| Repeat a method consistently | A skill |
| Retrieve information or act in another app | A connector |
| Make something people can use and revisit | An artifact |
| Run a defined job regularly | A scheduled task |
It's worth noting Claude is bringing chat and Cowork into one experience so some accounts still show separate modes whilst others let you ask for a quick answer or a complete piece of work in the same conversation. Either way, you'll be able to use everything here.
Set up Claude for your own work
Start with Settings > Your Claude > Instructions for Claude (or Account in older layouts). This is where you can tell Claude a bit about your job, the language you use, how you like things written and how you want it to approach a problem. Someone leading an operations team, for example, might put:
I lead an operations team. Use British English and plain language. Separate evidence from assumptions. Challenge weak reasoning. When recommending something, explain the trade-off and what information could change your recommendation.
The background for the particular thing you're working on can go in a project.
Claude also has memory, which helps it pick things up between conversations. It's worth having a look at what it's remembering in settings and correcting anything out of date. Remembering how you work is useful, but I'd still keep approved company information in shared documents.
When you hand Claude a task, think about what you'd need to know: what we're trying to achieve, who it's for, what we're working from, any constraints and what the result should look like. “Review this proposal against the attached brief and identify the three weakest assumptions” gives it much more to work with than “make this better”.
Use projects when the context will matter again
Let's say you're working on something that's a project in itself, like a lot of work is - stuff like a product launch, a hiring round or a marketing campaign - a project gives you somewhere to keep the background you'll need again. For a one-off email, I'd usually just start a conversation, but projects are for the ongoing important things.
Imagine you're getting ready for your team's weekly review. I'd create a project for the team's work, add its goals, current plans, recent reports and decisions to the project knowledge, then give Claude some instructions:
Compare progress with our current goals. Link to the evidence behind your conclusions. Flag conflicting sources. Ask for missing information before recommending changes to the plan.
Within that project, you might have one conversation preparing the review, another investigating a problem, and another planning next month's work. They can draw on the same background, so you don't have to squeeze everything into one enormous conversation.
On Team and Enterprise, Share project lets you give colleagues view or edit access. View access lets them use it; I'd give editing rights to whoever is looking after the information in there.
Sharing a project doesn't automatically share your individual chats. If a colleague wants to see how you got to an answer, you can share that conversation with them. And when you've agreed something, add it to the project knowledge so it's there for colleagues to use next time.
Someone does still need to keep the documents up to date, including uploaded copies, and agree when they'll review them. If you've changed the team's targets, for example, make sure Claude has the new ones for the next review.
Turn repeatable work into skills
Then there are the jobs where you want Claude to follow the same process each time, like preparing that weekly review. A skill packages the instructions and supporting material for the job, which Claude can load when it needs them.
The project holds the team's goals and background; a weekly-review skill supplies the method you can reuse across teams or projects. I'd include the inputs, steps, output template, a good example and checks for unsupported claims. Its description should explain when to use it.
And you don't have to write all of this from scratch. You can ask Claude to help create the skill, then read through what it's come up with. It's surprisingly good at doing this.
A skill package contains a SKILL.md instruction file and any supporting material. You'll find the create and upload options in Customize > Skills, and you can upload a package you've made locally as a ZIP. Code execution and file creation need to be enabled for skills to work.
I'd try the skill on a week whose results I understand well, then on a report with information missing and one that doesn't quite fit the usual process. Does it ask the questions you'd expect, and actually follow the steps? That's more useful than judging how professional the answer sounds.
A plugin can bundle related skills and connectors. Once that first skill is useful, you can build up to a larger toolkit.
Share skills and manage their versions
Once you've worked out a useful way of doing something, it makes sense for colleagues to benefit from it too. This is where skills get interesting for a business: you can share that method and improve it as colleagues try it.
Claude now supports organisation skill version history and publishing personal skills to the organisation. Sharing a skill and publishing it for the organisation work a little differently.
To share a skill with colleagues, open its menu in Customize > Skills and choose Share. On Team and Enterprise, colleagues can enable it and start using it. It's still your skill. If you update it, they get the new version next time they use it.
If you want the organisation to manage the skill, open it and choose Publish to org. If it only exists on your laptop, upload it to your account first.
The owner sets publishing to Open, Requires review or Off under Organisation settings > Plugins & skills > Policy. If review is required, you submit the skill or update for approval. That means colleagues can keep using the approved version while you're still working on the next one.
Owners can see Version history from an item's menu in the Inventory tab. Whoever reviews an update can see what's changed, and once it's approved, users get it automatically. The published skill also stays with the organisation if its author leaves. Anthropic's organisation skills guide covers the details.
For the weekly-review skill example, a release note could be as simple as “Added a check that every reported result links to its source.” Keep the test examples with it and make clear who's looking after it. I'd run those examples again after a change to see whether it's actually helped.
Connect Claude to the information it needs
If your information is already sitting in Google Drive or Slack, connectors let Claude access it there. Open Customize > Connectors and follow the setup for the service you want. Team accounts may need an owner to enable it first.
For the weekly review, you could ask Claude to find the latest reports and work out what's changed since last week, with links so you can check. If you know which folder or documents it needs, tell it.
What Claude can access normally depends on your permissions in the connected service; shared-credential connectors are an exception. Some connectors can write or send things too, so think about what you're letting Claude do. I'd be happy for it to prepare a draft, but I'd want to check it before it sends it to everyone involved.
Use artifacts when the output deserves its own space
Sometimes you want something you can work with afterwards - a document, presentation, diagram, dashboard or little tool. An artifact gives that work its own space beside the conversation. You can revisit and refine it, and supported templates let you edit directly.
If you're trying to work out whether your team has enough time for next month's work, you could ask:
Build an interactive workload planner as an artifact. Let me change the number of people, available hours per person and hours needed for the work. Show any spare capacity or shortfall, with the assumptions and calculations.
Then you can sit down with colleagues and try things like “what if this takes twice as long?” or “what if we have one fewer person available?” and see what happens. I like being able to explore the idea like that, with the assumptions there to question - it's like having a project manager just ready for your questions.
The artifact starts private, and Share lets you choose who can use it. On Team and Enterprise, the organisation controls whether you can share outside it, so check the sharing options before passing a link around.
Do check the calculations and try a few awkward inputs before relying on it, though. It's easy to get carried away when something looks finished. With everything AI, review it yourself before relying on it regularly.
Schedule work once the method is reliable
Once that weekly review is working well, you probably don't want to keep typing the same request every Monday. The same goes for a morning briefing or regular research check. That's when I'd look at scheduling it.
In the unified experience, tell Claude what you want done and how often, check the instructions it suggests, then click Schedule. In Cowork, use Scheduled > New task. Scheduled tasks are available on paid plans.
For example:
Every Monday at 8.30am Europe/London, use the weekly-review skill to analyse the latest weekly report in our connected Drive folder. Compare results with targets, link the evidence and flag missing data. Prepare a draft for my review. Do not send it to anyone.
Cloud schedules can run while your computer is off. Jobs needing local files or apps still depend on the local setup; older local schedules may remain local.
You can check the results in Scheduled, change the instructions and pause anything you no longer need. I'd pay attention to the first few runs, because if you're making the same correction every week, it's probably something to fix in the instructions.
The future of work is in how these pieces connect
You can probably see how these start to fit together. For that weekly review example, the project holds the goals and background, connectors find the latest information, and the skill works through the review. An artifact helps you explore the workload, and a schedule gets the next review ready.
You still need to decide what matters, check the evidence and work out what to change next. But when someone finds a better way of doing it, that can go back into the shared skill, so everyone gets the benefit.
I think we'll see more work going this way, with Claude doing more of the steps and people deciding what needs doing and how it should be done. Knowing what good work looks like, and explaining it well enough for someone else to repeat, becomes really useful. Cal Newport has a recent video talking about how email changed the face of work (for better or worse) and Claude and other AI platforms seem to be doing similar - in my opinion resistance is futile! (sorry)
Hopefully this short guide helps you get the edge where it's needed.