Getting started with Claude Cowork

By default Claude writes in a style everyone recognises as AI. You get rid of that by recording how you sound. You will use that profile in every step that follows.

There are two routes. If you have little written material, open tone-of-voice-intake.md and answer the questions: who you write for, how you want to come across, which words are genuinely yours and which ones you avoid. You then summarise your answers in five to eight lines.

If you have an archive of sent email, use the brand-voice skill instead. You supply five to ten messages that sound the way you want to sound, and the skill extracts your tone, your word choice and your sentence length. The instructions are in skills/tone-of-voice-skill-info.md.

The two routes complement each other. Start with whichever gives you something fastest and top it up later.

This is layer 1, the block of text that steers every conversation. Open CLAUDE-global-template.md and fill in the parts between square brackets: who you are, what you do, how you want Claude to work and which tools you use. Paste in your tone of voice from step 1.

Take over the two writing rules the kit ships with as well. The humaniser approach in humanizer-approach.md strips out the patterns that give AI text away, such as em dashes and words like seamless and holistic. The NLP rules in vault-sjabloon/tasks/00_resources/nlp-rules.md go a step further and require you to write what something actually is.

Split your guardrails into groups. The template uses four: sending and publishing, people and amounts, executing and spending, code and version control. One long list works fine for a month and becomes unreadable after that, because you keep adding to it. Write each guardrail as a hard rule, in the imperative.

If you write documents featuring people who will not read them themselves, fill in the block on third parties as well. Among other things it says that every amount is marked as either a confirmed rate or a worked example, and that those two never mix in one document. That is the mistake that costs money fastest.

Then paste the completed block in two places: in the Claude app under your personal preferences, and in Cowork under the project instructions. The first applies everywhere you use Claude, the second only inside that project.

Copy the vault-sjabloon folder to wherever you want to work and give it a name of your own. This folder is your Cowork working folder and, if you like, your Obsidian vault at the same time. Connecting it to Cowork happens in step 4.

Once the folder hangs off a project, Cowork automatically reads the CLAUDE.md in it on opening and follows the instructions inside it. That is layer 2, so the vault itself only: how the folders are organised and when Claude should load what. The numbered folders from 00-INBOX to 10-SYSTEEM each have a fixed purpose, explained in a README per folder.

Inside 10-SYSTEEM, the templates/ folder has a role of its own. It holds the shape of a document that keeps coming back without a process of its own, the halfway house between a loose project file and a skill. The README in that folder gives the criterion, plus the rule that a template becomes a candidate for a skill the third time you use it.

You have two memories. That surprises people, and without a division of labour the same facts drift apart in two places. tasks/MEMORY.md is the memory you edit yourself: running projects, decisions made and names that keep coming back. Keep each line short and hold to the ceiling of 150 lines, otherwise the file slows everything down. Cowork's own memory fills itself while you work and you leave that one alone. If you spot something there you want to manage yourself, move it to MEMORY.md.

Finally, fill the routing map in CLAUDE.md with your own workstations. If you work for several clients or on several projects, create an HQ folder per project inside tasks/. That is layer 4.

A project is the workspace everything else ends up in. It bundles the folder Claude works in, the instructions that apply to all that work, your recurring tasks and a memory that belongs to that project alone. If you juggle several things at once, a project per subject keeps those worlds apart.

You will find Projects in the left column of the Claude desktop app. The plus button offers three ways to create one:

• From scratch. Cowork creates a new folder and you supply the instructions and the first files.
• Import from a Claude project. If you already have a project in chat with instructions and files, Cowork pulls those across and turns them into a local project. One project at a time.
• Use an existing folder. This is the route for this kit. You point at the vault you set up in step 3, name the project and paste in your instructions.

What sits inside a project. The instructions steer every task within this project, so that is where the block from step 2 goes. The context decides where Claude reads and writes: a local folder, a linked chat project or a plain URL. Scheduled tasks recur within this project. The memory holds on to what you do here and does not carry it over to another project.

When do you start a new project? As soon as a work area has its own folder, its own instructions or its own recurring tasks. A one-off question belongs in a conversation inside an existing project, not in a new one. If you work for several clients, one project per client is a workable split, with the context skill from the next step as the domain layer underneath.

Two things to know. Projects live locally on your computer and do not sync to the cloud, so they will not be there on a second machine. Archiving a project removes it from the list while your folders and files on disk stay untouched.

If you work for one client, skip this step. If you work for several, or on projects that have little to do with each other, this is the step that makes your set-up scale.

The problem without this layer: the rules of one work area load while you work on another. You ask for an invoice and get the terminology of a client project back. Putting everything in one large instruction file makes it worse, because then everything loads on every request.

A context skill is a small file per work area that loads only when that area is in play. Cowork picks the skill based on the description in its header, so you never have to point at it yourself. It holds your role, the standard document types, the terms that mean something specific here and the rules that apply only here. Your tone and your working method do not belong in it, those already sit in layer 1.

Split along where your work comes from, so per client, per brand or per product. Splitting by task type works less well, because the same task recurs at every client. The explanation and a fill-in template are in context-skills.md.

Then test whether the skill loads: give an instruction from that work area without naming it. If nothing happens, the description is missing the words you actually use.

This is where a tidy folder becomes a system that learns from itself. The vault points to three working methods you can switch on separately.

• The agile build loop in 10-SYSTEEM/werkwijze-bouwlus.md. Claude cuts a larger assignment into blocks and puts a check to you after each block. You spot mistakes after ten minutes instead of half a day.
• The reviewer subagent in 10-SYSTEEM/agents/beoordelaar.md. A second Claude that assesses a piece with clean context, so without the writer's reasoning. Point it at everything that leaves your desk. Installation goes through agents/LEESME.md.
• Session logs in 10-SYSTEEM/sessielogs/. At the end of a working session Claude records which decisions were made and which corrections you gave. A consolidation pass turns those into updates to your lessons and your memory.

Of the three, the reviewer pays off fastest. Start there if you only want to switch on one.

Keep an eye on lessons.md. That file grows faster than you expect and therefore has its own ceiling and archiving rule, just like MEMORY.md. Without maintenance it holds more after six months than Claude can usefully carry in one session.

A guardrail in your global settings is an instruction. Claude usually follows it, but it remains text. A hook is binding and works at tool level.

In 10-SYSTEEM/hooks/ sits a PreToolUse hook that enforces your most important guardrails. The hook runs before Claude uses a tool and blocks whatever you have ruled out, for example sending email or touching your git folder. Installation goes through hooks/INSTALLEREN.md.

Do this step if you give Claude access to things you would rather not lose. If you only work with individual documents, you can skip it.

If you work with incoming sources such as meeting notes, exports or case files, things fill up quickly. Claude rereads the same raw files for every question, which is slow and produces mistakes.

The compiler vault solves that with two folders. In 20-RAW you drop your untouched sources and you never change them again. In 30-WIKI sits the compiled synthesis per topic or per person, and that is what Claude reads back. How it works is described in 10-SYSTEEM/compileer-schema.md.

One rule matters here: a text Claude wrote earlier is not a source. Always check a factual claim against 20-RAW before reusing it, even when it already appears in an approved document.

A skill is a recorded way of carrying out a recurring task. You describe once how it should go and Claude follows that description every time after. Skills can be shared, so what you build a colleague can use.

The kit points to two skills to start with. The Humanizer strips AI patterns out of your text and was built by @blader, available at github.com/blader/humanizer. The brand-voice skill derives your writing voice from your own material, see step 1.

After that you build your own. Look at tasks you do more than three times a month where the result has to look the same each time. Those are your candidates. Where a context skill from step 4 describes what applies in a work area, a task skill describes how one job runs.