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.

Your writing rules do not go in this block but in a skill of their own. The kit supplies two sources for it. 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 require you to write what something actually is. In step 6 you turn those into the skill writing-rules. This block then holds only one line that points to that skill; the template already has it.

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 one place: in the Claude app under Settings, at Instructions for Claude. That block applies in every chat and every project. Do not paste it into your project instructions as well. Every rule would then load twice, and within a few weeks the two versions drift apart because you only ever update one of them. Step 4 explains what does belong in project instructions.

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, each with its own job. Claude's memory holds the facts about you: who you are, what you do, for whom and what you are working on. It lives in your account and is there in every chat, even when your computer is off. Fill it using memory-intake.md. tasks/MEMORY.md is the signpost of your vault: paths, the state of running projects and references to project notes, under 120 lines. Rules belong in neither; they go in your global settings and your skills. Personal data of clients does not belong there either.

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 instructions that apply only to that work, the files that belong to it, 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 app. Create a project, give it a name and, in the desktop app, connect the vault you set up in step 3 so Claude may read and write there. The project lives in your account, so you will also see it on your phone or on a second computer. The link to your folder works from the computer where that folder lives.

What belongs in project instructions. Only what differs in this project from your global settings: the purpose of the project and the rules that apply only here, for example which context skill loads here or what never happens in this project. Do not repeat your global settings. Start the instructions with the sentence: My global settings apply in full and are not repeated here. Ten lines of project instructions are usually enough.

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.

Archiving. Archiving a project removes it from the list. 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.

Turn your always-on rules into a skill. A reference to a file in your settings only works while your vault is connected. A skill belongs to your account and loads in every chat and every project. Start with your writing rules: ask Claude to build a skill called writing-rules from nlp-rules.md and humanizer-approach.md.

Keep an eye on lessons.md. That file grows faster than you expect. So with every correction, decide the destination first: if the lesson describes how a document comes about, it goes to the skill that makes that document, and only what fits nowhere else goes into lessons.md. Rewrite an existing lesson rather than adding a second one beneath it. The management rules sit at the top of the file.

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.

Where the hook applies. The hook lives in ~/.claude/settings.json on your own computer and works in sessions that run there. A task that runs in the cloud does not read that file. There your guardrail applies only as an instruction in your global settings.

If you work with incoming sources such as meeting notes, exports or reports, 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, and that is what Claude reads back. How it works is described in 10-SYSTEEM/compileer-schema.md. Personal data of clients or applicants does not belong there. It stays in the protected system where you manage it, such as your CRM or your case management system.

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 5 describes what applies in a work area, a task skill describes how one job runs.