# Claude Cowork: Top 5 Tips for Productivity - Channel: [Jeff Su](https://www.youtube.com/channel/UCwAnu01qlnVg1Ai2AbtTMaA) - Published: 2026-05-19 - Source video: [Watch on YouTube](https://youtube.com/watch?v=4wvLHFgnQZQ) - Read on ReadTube: https://www.read.tube/p/videos/4wvLHFgnQZQ - Language: Original (source language) ## Summary **Five Claude Co-Work Setup Tips** The video gives five setup tips for using Claude Co-Work more efficiently from day one. The core advice is to keep root files lean, separate rules from facts, archive old material, migrate Claude projects into workstations, and use skills only for repeatable tasks. The creator shows how to make MD files easier to edit with Obsidian, how to keep root claw.md and memory.mmd under strict size limits, and how to relocate task-specific content into reference files. The final distinction is that workstations are for ongoing areas of work, while skills are for repeatable processes that should run the same way every time. The video argues that Co-Work becomes much more powerful when its file structure is designed carefully from the start. The creator’s main message is that root files should stay small and focused, with different kinds of information separated into the right places so token usage stays low and outputs stay reliable. The first tips cover workspace hygiene. Obsidian is recommended as a readable way to view and edit markdown files. The root claw.md should stay around 200 to 250 lines, with 300 as an absolute ceiling, and any section that is only needed for a specific task should be moved into a reference file and replaced with a pointer. The video also stresses placing prescriptive rules in claw.md and changeable facts in memory.mmd, then using Co-Work to review both files and recommend corrections when items are misplaced. The memory system gets the same treatment. Root memory.mmd should have a clear structure for active projects, scheduled tasks, and persistent facts, with concise entries and a hard 150-line ceiling. When memory grows too large, old material should be compressed and archived in archive.md, which is not loaded every session. The video also recommends creating separate memory files for each workstation and project so context stays scoped and root memory remains compact. The later tips explain how to scale beyond basic setup. Claude projects should be transplanted into Co-Work by converting project instructions into a workstation claw.md, project memory into memory.mmd, and knowledge files into resources. This makes files editable, structured, and directly writable by the system. Finally, the video distinguishes workstations from skills: workstations are places or ongoing areas of work with context and judgment calls, while skills are repeatable processes that can run consistently from a checklist. - Use Obsidian to read and edit markdown files more easily. - Keep root claw.md lean, ideally 200 to 250 lines. - Move task-specific sections into reference files and leave pointers behind. - Put rules in claw.md and factual, changeable notes in memory.mmd. - Structure memory into active projects, scheduled tasks, and core facts. - Enforce a 150-line ceiling on root memory.mmd and archive old material. - Create archive.md for complete history without session-load cost. - Migrate Claude projects into Co-Work workstations for better control. - Treat workstations as ongoing work areas and skills as repeatable procedures. ## Article ### Co-work Is Powerful, but the Foundation Matters Co-work is insanely powerful, but there's a problem. Right now, there's no gold standard on how to set up your workspace. So if you get the foundation wrong, you're going to keep running into avoidable issues down the line. After 5 months of using co-work daily to run my entire life, and going into debt to pay for token usage, here are five essential things to get right from day one. Let's get started. ### Tip Number One: Use a Markdown Translator for Your MD Files Kicking things off with tip number one, the markdown translator. As you know by now, co-work's instructions and memory live in these MD markdown files. And although we can open them up and edit this directly, opening this just costs 20 tokens. Okay, that's a joke, but I kind of feel it's true. It's a pain to read like this, right? And annoying as hell to edit. So first what you want to do is install a free app called Obsidian. ```text Open folder as vault. Open. Point it to your co-workspace folder. Open. ``` And now every MD file instantly renders with proper headings, bold text, and bullet points. Basically, a much more readable format. And now let's say I want to change something in this `claw.md` file. Instead of doing anything here, I can select the `claw.md` tab in Obsidian and replace this first bullet point. For example, under preferences with *always make inappropriate jokes*. And let's just remove that line from earlier. And I'm going to close this and reopen. And you will see that the changes are already there. To be clear, you don't need to learn Obsidian or use any of its other features. It's just a lens to read and edit MD files. #### Pro tips for reading and editing MD files - Click Command and Control plus to zoom in. - Click the reading mode icon to lock the Obsidian page so you don't make edits by mistake. - Go to Obsidian settings, files and links. - Keep the **show all file types** toggle turned on. - This lets you see non-`.md` files like spreadsheets, PDFs, and even images in the sidebar. ### Tip Number Two: Keep Root `claw.md` Under 300 Lines Moving on to tip number two, the 300 line rule. Because a root `claw.md` loads every single session, a bloated file wastes a lot of tokens. And when I cut mine from over 600 lines to around 250, my token usage dropped by roughly 25%. And here are three tactics you can use right away. #### Tactic One: Include Only the Bare Essentials My `claw.md` template has six sections. 1. **Memory system** — this section tells co-work to always read `memory.mmd` at session start, so it knows what we did before. 2. **Preferences** — this is how we want co-work to communicate: tone, length, format, etc. 3. **Rules** — these represent behavioral guard rails. Basically, if you want co-work to always do something like always ask clarified questions before starting a complex task, or never do something like never edit files in my workspace without telling me what you changed and why, those belong here. 4. **Routing map** — heading over to my actual `claw.md`, the routing map contains a table that co-work checks to figure out which workstation to load based on my task. So if I'm writing an email, we load the Email HQ workstation. If I'm working on Chinese projects, load China Desk. If I'm brainstorming, use Clarity Partner. So on and so forth. 5. **References** — coming back to the lightweight template since it's less dense, the fifth section, references, includes one-line pointers to files co-work loads on demand. In other words, this `voice principles.mmd` file does not load every session, right? Only when I'm writing content. 6. **Creating new workstations** — and finally, creating new workstations basically tells co-work how to create new workstations in your workspace. **Pro tip:** the rule of thumb is to keep your `claw.md` file between 200 and 250 lines, with 300 being the absolute maximum. You can also grab these `claw.md` and `memory.mmd` templates from my free co-work toolkit linked down below. But Jeff, I hear you say, there's no way I can keep everything within 300 lines if I keep using co-work. And that brings us to tactic number two. #### Tactic Two: Ask Co-work to Relocate Non-Essential Rules Ask co-work to relocate non-essential rules. Here's the test: does co-work need this every session or only when a specific task comes up? Back in my actual `claw.mmd`, there's a section called governance `m.e.i` principle that says all instructions and rules in this workspace must be mutually exclusive and collectively exhaustive. And since this governs how all rules are organized in my entire co-workspace, this must be kept in my root `claw.md`. In contrast, there's a file creation rule bullet point down here that only applies when I'm creating a new file. And since I'm not creating files every session, instead of having all 22 rules live here, I have a pointer: *read this before creating any new file in the workspace*. Now let's apply this learning immediately. Going back to the creating new workstation section from before, we don't create new workstations every session, right? So we can tell co-work to move the creating new workstation section out of my root `claw.md` into a new reference file and replace it with a one-line pointer in my references table. And we're just going to let this run. And after a few seconds, we can see what happened. First, even co-work tells us that doing this keeps the root `claw` leaner while preserving the template for on-demand loading. And opening the Obsidian view, we can see that the entire creating new workstation section has been removed. Instead, it's been replaced by a pointer: *Hey, read this when creating a new workstation.* And where does this workstation template `.md` live? Under the `00 resources` folder. And as you can see, everything has been moved over here. And our `claw.md` just got shorter without losing anything. It's that simple when it comes to optimizing your `claw.md`: find sections that serve specific tasks and ask co-work to relocate them. ### Tip Number Three: Put Files in the Right Place Tactic number three, write files in the right place. In a nutshell, most co-work users put `claw.md` content in `memory.mmd` and vice versa. And this confusion tanks output quality. The solution is adding a rule under `claw.md`'s memory system section. - **Test one:** if the entry is prescriptive and contains words like *always* and *never*, then it belongs in `claw.md`. - **Test two:** if it describes a fact that could change, then it goes into `memory.mmd`. Scrolling down to the rule section here, we have an entry that says: *before drafting a new email, check if a related thread already exists with that recipient.* This is a version of *before doing X, do Y*, which is prescriptive behavior as well, right? That's why it belongs in `claw.md`. Flipping over to the `memory.mmd` file and scrolling down, we see an entry here that says: *my company uses Microsoft Copilot*, which is something that could change tomorrow, right? Probably something that should change. Just kidding. So this is a temporary fact and not a rule, and that's why it belongs in `memory.mmd`. Here's something you can do right now. Tell co-work to review my root `claw.md` and `memory.mmd`. In the `claw.md` file, flag any entry whose primary purpose is recording a factual status rather than prescribing how you should behave. And in `memory.mmd`, flag any entry whose primary purpose is telling you how to behave rather than recording a fact. Recommend where each flagged entry should move. And after a minute or two, co-work will share a list of recommendations. And here you can actually see there are five issues in my `memory.mmd` file, which obviously I left in there on purpose to show you what not to do. I don't make mistakes. And luckily my `claw.md` is clean though. So I can just literally say proceed with changes. And it's as easy as that. #### A free prompt from HubSpot for organizing files Speaking of optimizing our workspace, today's sponsor HubSpot put together a free resource called the cloud co-work stack that contains 12 co-work-optimized prompts you can use right away. There are a couple I found pretty useful, like this batch document generator one and the research synthesis one. This one, although I'd still probably use cloud web for research. But my favorite by far, surprise surprise, is this file management prompt. The one change I'd make to this is instead of choosing a primary sort by date or by project, tell it to organize following Thiago Forte's PAR method: projects, areas, resources, and archive. That way, every file lands in a bucket based on how actionable it is, not just what it looks like. This actually inspired me to create a schedule task in co-work that processes my iCloud inbox folder every morning. Meaning co-work sorts through the receipts, PDFs, random downloads I capture into the right folder automatically. You can grab the cloud co-work stack for free link down below. Thank you HubSpot for sponsoring this video. ### Tip Number Four: Keep Root `memory.mmd` Lean and Structured All right, tip number three, the memory diet. Just like your root `claw.md`, your root `memory.mmd` also loads every single session. So a messy one wastes tokens and makes co-work's output worse. So here are three things you can do. #### Tactic One: Give `memory.mmd` a Clear Structure My root `memory.mmd` has three sections, with the first being **active projects and work**, which is a list of everything I'm currently working on with a short status next to each one so co-work immediately knows what's on my plate. Second, a **schedule task** section that tracks all my automated recurring jobs so co-work doesn't accidentally create duplicates or miss a task that already exists. And third, the **core memory** section stores persistent facts about me like my career before becoming a full-time YouTuber, my LinkedIn URL, and my business address and how it's used. Basically, facts I need to reference all the time. #### Tactic Two: Set a Hard Ceiling So remember how in my root `claw.md` I have a memory system section and at the bottom here, there's actually a pointer to the full set of memory system rules. And if I open up that file, there are two things you should know. First, under entry format, there's a rule that says one to two sentences max for every memory entry. Meaning, co-work concise entries from day one instead of long paragraphs that bloat your `memory.mmd` file and waste tokens. Next, under size ceiling section, there's a rule that reads **root `memory.mmd` 150 line ceiling**. When the ceiling is breached, the fix is always compression and archiving, never raising the ceiling. In plain English, this means when your `memory.mmd` file inevitably reaches 150 lines, co-work will automatically archive information that's no longer current, like things that happened 2 or 3 months ago. But wait a minute, where does that archived information go? #### Tactic Three: Create an `archive.md` Create an `archive.md`. Here's a simple visualization. - Your `memory.mmd` is a whiteboard that contains active projects and key facts you need to reference every day. - Your `archive.mmd` is the filing cabinet with a complete record of everything you've done. And here's a key insight: co-work does not read `archive.mmd` every session. It's only when you ask something like *what happened with the e-list 3 months ago* does it then check the `archive.mmd` file to find the answer. And because `archive.md` isn't loaded at session start, it doesn't need to have a size ceiling, right? You can preserve everything you want without paying any token cost. To help you set this up, I have a prompt linked below that you can paste directly into co-work like so. In the interest of time, I won't read the whole thing, but basically this prompt first creates your `archive.mmd` file, then adds the memory rules to your `claw.md` and teaches co-work which entries to keep in `memory.mmd` and which to archive. **Pro tip:** you want to create a separate `memory.mmd` for each workstation and each project inside your workspace to reduce token usage. For example, when I ask co-work something like *what's going on with my latest email campaign?* co-work first checks `rootmemory.mmd` to see the project exists, then jumps to the project `memory.md` to read project-specific information like notion pages, email subject lines, past decisions, and current status. And this cascading setup is why my root `memory.mmd` has never gone above 100 lines even after months of aggressive daily use. ### Tip Number Five: Migrate Claude Projects into Co-work Next up, tip number four, the project transplant. A lot of you asked about the relationship between Claude projects and co-work. And long story short, you want to migrate all your Claude projects into co-work because co-work doesn't face the same limitations as Claude projects. For instance, I used to rely on this Claude project to write my weekly newsletter. And within this project, we have project instructions over here, a project knowledge file, and an autogenerated project memory. Compared to co-work, there are quite a few problems here. For example, if I wanted to make improvements to the project instructions, I would have to manually click in and type out something or paste in something, right? Second, clicking into the project memory, we see it's an AI-generated paragraph. I can't really structure or edit directly. This doesn't work really well. And third, even though I can link a Google Doc of past newsletter editions as a knowledge file, Claude can't write to this document directly either. I'd have to open the document and paste everything myself. All these issues can be addressed by migrating our Claude projects into co-work. And the process is simple. - The project instructions essentially become the workstation `claw.md` file. - Project memory becomes the `memory.mmd` file. - Knowledge files get added to the project resources folder. #### How to migrate a project step by step Here's what to do in practice: 1. Open up a blank text document. 2. Go in and select all. 3. Copy the project instructions and paste it into this document. 4. Press enter twice. 5. Go back. 6. Click into project memory. 7. Select all of this. 8. Add a header one: **Project memory**. 9. Paste the project memory in as well. 10. Save this as a markdown document: `project info.md`. 11. Save. All right. And then I can download my entire Google Doc as a markdown file as well. All tabs. This might take a few moments, so I might fast forward this. In the meantime, though, let's head on over to my free template. This is linked again linked down below. Copy this simple migration prompt. Paste it into co-work. And then back in my downloads, share both the `project info.mmd` and my Google Doc `.md` file into co-work and just let this run in order for the Claude project to be migrated into co-work. All right, it's done. Let's go over what co-work just did. 1. It created a newsletter workstation folder. My newsletter is called Workspace Essentials, but this is a newsletter workstation folder. 2. It created a workstation `claw.mmd` file that contains the same workflow as the original project instructions. 3. It created a `memory.md` file with labeled structs that I can actually edit like so. 4. It created a resources folder with three separate resource files: one for audience and positioning, one for my recent newsletters, and one that extracted style patterns from my existing newsletters. As a bonus, we can even go back to our root `claw.mmd` file. And scrolling all the way down, you can see that under routing map, co-work even added a new entry that maps to our newly created newsletter workstation. Now, whenever I want to make a change to any of those files, I can simply tell co-work, *Hey, add a rule to my newsletter workstation. Each addition should have a maximum of three emojis,* and co-work will make the change directly in the newsletter `claw.mmd` file as you can see right here. And let's say I just publish the latest issue. I can tell co-work to add the latest edition to the newsletter examples file. Paste in the copy. Let it run. And after a minute — I'm not going to wait, I'm too impatient — it will be added to the newsletter examples recent markdown file. I cannot stress how much of a game changer this is compared to the regular chat bots. This is how our co-workspace compounds. Every improvement, every change we make today makes tomorrow's output better. By the way, if you want my complete system with pre-built workstation templates and the step-by-step walkthrough so you can skip the trial and error of building from scratch, I'm putting together a Co-work Academy course and you can sign up for the wait list down below. ### Tip Number Five: Know When to Use a Skill Versus a Workstation Moving on to tip number five, the skill check. A lot of you asked about skills versus workstations after my last video. So here's the difference in a nutshell. Back in my actual co-workspace, I say, *I want to work on my next native weekly newsletter. What do I need to do again?* And let's see what it says. All right, as you can see, co-work first loaded my newsletter workstation for context, then laid out the workflow. But notice how a lot of these steps surface a decision I need to make. For example, step one: do I have a topic in mind? Which Google application am I covering this week? Right? This illustrates something important. This newsletter workflow cannot run on autopilot. I, the human, need to make decisions and judgment calls as part of the process. In contrast, once a newsletter draft is finalized, I can trigger my newsletter subject line skill, which takes the final draft and applies the instructions from the skill that can run on autopilot since it's just a checklist. And I'm going to fast forward a bit here. It will give me five scored options. I know exactly what I'm getting back every time, and the only thing that changes is the content. Example number two, I have a workstation audit skill that checks for misplaced rules, bloat, and gaps within a specific workstation folder to keep my workstations optimized and lean. The output is a report with an executive summary up front, followed by specific findings and recommendations. So the test for when to create a workstation versus a skill is actually pretty simple: is this a place I work or a thing I do? If it's an ongoing area of work with its own voice and accumulated context, that's a workstation. If it's a repeatable process you want done the same way every time, that's a skill. If you found this helpful, check out my full co-work playlist next. See you there. And in the meantime, have a great one.