Transcript: Top 5 Claude Cowork Tips I Wish I Knew from Day One

Source video ID: 4wvLHFgnQZQ

Transcript

• 0:00 — 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. So, after 5 months of using co-work daily to run my entire life and going to debt to pay for token usage, here are five essential things to get right from day one. Let’s get started. 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
• 0:31 — 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 to install a free app called Obsidian. 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
• 1:02 — 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
• 1:33 — and edit MD files. Pro tip, you can click command and control plus to zoom in. You can click the reading mode icon to lock the Obsidian page so you don’t make edits by mistake. And you can even go to Obsidian settings, files and links. Keep the show all file types toggle turned on. And this lets you see non.mmd files like spreadsheets, PDFs, and even images in the sidebar. Moving on to tip number two, the 300 line rule. Because a root cloud.md loads every
• 2:04 — 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. First, only include the bare essentials. My claw.md template has six sections. First, this memory system section tells Coowwork to always read memory.mmd at session start. So, it knows what we did before. Next, preferences is how we want co-work to communicate. Tone, length, format, etc.
• 2:35 — Next, rules 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. 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
• 3:06 — working on Chinese projects, load China desk. If I’m brainstorming, use clarity partner. So on and so forth. Coming back to the lightweight template since it’s less dense. The fifth section, references include oneline pointers to files co-workloads on demand. In other words, this voice principles.mmd file does not load every session. Right? Only when I’m writing content. 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
• 3:36 — 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. 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 cloud.mmd, there’s a section called governance mei
• 4:07 — 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.mmd. In contrast, there’s a file creation rule bullet point down here that only apply 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
• 4:38 — 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 move the creating new workstation section out of my rootclaw.mmd into a new reference file and replace it with a oneline 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 cloud leaner while preserving the template for ondemand
• 5:09 — loading. Right. 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
• 5:39 — that serve specific tasks and ask co-work to relocate them. 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
• 6:10 — 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.mmd. 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
• 6:42 — that’s why it belongs in memory.mmd. Here’s something you can do right now. Tell co-work to review my root cause.md and memory.mmd. In the cause.mmd file, flag any entry whose primary purpose is recording a factor status rather than prescribing how you should behave. Right? And in memory, flag any entry whose primary purpose is telling you how to behave rather than recording a fact. Recommend where each flaged entry should move. And after a minute or two, co-work will share a list of recommendations. And here you can actually see uh there
• 7:12 — are five issues in my memory.mmd file which obviously I left them in there on purpose to show you what not to do. I don’t make mistakes. And um luckily uh my claw.md is clean though. So I can just literally say proceed with changes. And it’s as easy as that. 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
• 7:44 — 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
• 8:15 — 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. 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 cooworks output worse. So here are three things you can do. First, give your memory.mmd a clear structure. My rootmemory.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
• 8:47 — 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 number two, set a hard ceiling. So, remember how in my rootclaw.md I have a memory
• 9:17 — 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
• 9:47 — 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 alliance, 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 number three, create an archive.md. Here’s a simple visualization. Your
• 10:17 — 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
• 10:48 — 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
• 11:20 — 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 rootmemory.mmd has never gone above 100 lines even after months of aggressive daily use. Next up, tip number four, the
• 11:50 — 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 cla projects into co-work because co-work doesn’t face the same limitations as claude projects. For instance, I used to rely on this cloud project to write my weekly newsletter. And within this project, we have project instructions over here, a project knowledge file, 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
• 12:20 — 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 like open the document and paste everything myself. All these issues can be addressed by migrating our claw projects into co-work. And the process is simple.
• 12:50 — The project instructions essentially become the workstation claw.md file. Project memory becomes the memory.mmd file. And knowledge files get added to the project resources folder. Here’s what to do in practice. Open up a blank text document. Go in and select all. Copy the project instructions and paste it into this document. Press enter twice. Go back. Click into project memory. Select all of this. Add a header one. Project memory. Paste the project
• 13:22 — memory in as well. Save this as a markdown document. Project info.md. 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. Uh, this is linked again linked down below. Copy this simple migration prompt. Paste it into co-work. And then back in my
• 13:54 — 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 claw project to be migrated into co-work. All right, it’s done. Let’s go over what coowork just did. First, it created a newsletter workstation folder. My newsletter is called workspace essentials, but this is a newsletter workstation folder. Second, it created a workstation claw.mmd file that contains the same workflow as the original project instructions. Third, it created
• 14:26 — a memory MD file with labeled structs that I can actually edit like so. And fourth, it created a resources folder with three separate resource files. one for audience and positioning, one for uh my recent newsletters, and one that extracted uh style patterns from my existing newsletters. As a bonus, we can even go back to our root cloudmomd file. And scrolling all the way down, you can see that under routing map, co-work even
• 14:56 — 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
• 15:27 — 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 Coowwork Academy course and can sign up for the
• 15:58 — weight list down below. 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 surfaces a decision I need to make. For example, step one, do I have a topic in mind? Which Google
• 16:28 — 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 subjectline skill, which takes the final draft, 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
• 16:59 — 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
• 17:30 — 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.