Speaker A
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. [music]
Jeff Su shares top 5 essential tips to optimize productivity using Claude Co-work, focusing on workspace setup, file management, and project organization.
Key Takeaways
- Proper workspace setup in Co-work is critical to avoid inefficiencies and token waste.
- Using tools like Obsidian enhances readability and editing of markdown files.
- Keeping the root claw.md file concise (under 300 lines) significantly reduces token consumption.
- Separating rules and facts between claw.md and memory.md improves Co-work’s output quality.
- Migrating projects into Co-work and organizing workstations boosts productivity and management.
Summary
- Co-work is a powerful productivity tool but lacks a gold standard for workspace setup, leading to avoidable issues if foundational setup is incorrect.
- Tip 1: Use Obsidian to read and edit .md markdown files in a more readable format, improving workspace management.
- Tip 2: Follow the 300-line rule for the root claw.md file to reduce token usage and improve efficiency by relocating non-essential rules.
- Tip 3: Correctly separate prescriptive rules (claw.md) from factual, changeable information (memory.md) to maintain output quality.
- Tip 4: Migrate Claude projects into Co-work by converting project instructions to workstation files and organizing resources accordingly.
- Tip 5: Use workspace-specific rules and pointers to keep workstations optimized, lean, and easy to manage.
- Jeff provides practical tactics such as using pointers for on-demand loading and leveraging Co-work’s ability to reorganize workspace files.
- The video includes a sponsored resource, the Claude Co-work Stack by HubSpot, offering optimized prompts for enhanced productivity.
- Jeff demonstrates real-time workspace edits and optimizations, emphasizing token cost savings and workflow clarity.
- The video covers detailed examples of workspace file structures, rules, and project management within Co-work.
Chapters
- 00:00Introduction to Co-work and workspace setup challenges
- 01:07Tip 1: Using Obsidian for markdown file management
- 02:19Tip 2: The 300-line rule and optimizing claw.md
- 04:43Relocating non-essential rules to keep claw.md lean
- 06:00Tip 3: Correct file placement between claw.md and memory.md
- 07:03Review and correction of file content with Co-work
- 08:08Sponsored resource: Claude Co-work Stack by HubSpot
- 09:18Tip 4: Migrating Claude projects into Co-work
- 12:10Tip 5: Managing workstations and rules for optimization
Full Transcript — Download SRT & Markdown
Speaker A
So, after five 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. Kicking things off with tip number one, the
Speaker A
markdown translator. As you know by now, Co-work's instructions and memory live in these .md markdown files. And although [music] 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
Speaker A
pain to read like this, right? And annoying as hell to edit. So, the first thing we want to do is to install a free app called Obsidian. Open folder as vault, open, point it to your Co-work workspace folder, open, and now every .md file
Speaker A
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 [music] in Obsidian and replace this
Speaker A
first bullet point, for example, under preferences with always make [music] 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
Speaker A
need to learn Obsidian or use any of its other features. It's just a lens to read and edit .md files. Pro tip, you can click command or control plus to zoom in. You can click the reading mode icon
Speaker A
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-.md files like spreadsheets, PDFs, and even
Speaker A
images in the sidebar. Moving on to tip number two, the 300-line rule. Because our 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
Speaker A
dropped by roughly 25%. And here are three tactics you can use right away. First, only include the bare essentials.
Speaker A
My claw.md template has six sections. First, this memory system section tells Co-work to always read memory.md at session start, so it knows what we did before. Next, preferences is how we want Co-work to communicate: tone, length, format, etc. Next, rules represent
Speaker A
behavioral guardrails. Basically, if you want Co-work to always do something, like always ask clarifying 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.
Speaker A
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.
Speaker A
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. Coming back to the lightweight template, since it's less
Speaker A
dense, the fifth section, references, include one-line pointers to files Co-work loads on demand. In other words, this voice.principles.md 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
Speaker A
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.md templates from my free Co-work toolkit, linked down below. But Jeff, I hear you say,
Speaker A
"There's no way I 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.
Speaker A
Does Co-work need this every session or only when a specific task comes up? Back in my actual claw.md, there's a section called governance missy principle that says all instructions and rules in this workspace must be mutually exclusive and
Speaker A
collectively exhaustive. And since this governs how all rules are organized in my entire Co-work 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
Speaker A
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
Speaker A
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 root claw.md into a new reference file and replace it with a one-line pointer in my
Speaker A
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.md leaner while preserving the template for on-demand loading, right? And opening
Speaker A
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.
Speaker A
[music] 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 [music] and ask Co-work
Speaker A
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.md and vice versa. And this confusion tanks output quality. The solution is adding a rule under claw.md's memory system section. Test
Speaker A
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.md. Scrolling down to the rule section, here we have
Speaker A
entries that say, "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
Speaker A
claw.md. Flipping over to the memory.md file and scrolling down, we see an entry here that says, "My company uses Microsoft Copilot," which is something that could change tomorrow, right?
Speaker A
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.md. Here's something you can do right now. Tell Co-work to review my root claw.md and memory.md. In
Speaker A
the claw.md file, flag any entry whose primary purpose is recording a fact or status, rather than prescribing how you should behave, right? And in memory.md, flag any entry whose primary purpose is telling you how to behave rather than
Speaker A
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.md file, which obviously I left them in there on
Speaker A
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.
Speaker A
Speaking of optimizing our workspace, today's sponsor HubSpot put together a free resource called the Claude 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
Speaker A
the research synthesis one, this one. Although I'd still probably use Claude Web for research, but my favorite by far, surprise surprise, is this file management prompt. The one change I'd make
Speaker A
it to organize following Tiago Forte's PARA 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
Speaker A
schedule task in Co-work that processes my iCloud folder every morning, meaning Co-work sorts through the receipts, PDFs, random downloads I capture, into the right folder automatically. You can grab the Claude Co-work stack for free, link down below. Thank you, HubSpot, for
Speaker A
sponsoring this video. All right, tip number three, the memory diet. Just like your root claude.md, your root memory.md 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. First, give
Speaker A
your memory.md a clear structure. My root memory.md 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.
Speaker A
Second, a scheduled 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
Speaker 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 root claude.md, I have a memory system
Speaker A
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
Speaker A
sentences max for every memory entry." Meaning, Co-work writes concise entries from day one instead of long paragraphs that bloats your memory.md file and waste tokens. Next, under size ceiling section, there's a rule that reads root memory.md 150 line ceiling. When the
Speaker A
ceiling is breached, the fix is always compression and archiving, never raising the ceiling. In plain English, this means when your memory.md file inevitably reaches 150 lines, co-work will automatically archive information that's no longer current, like things that happened two or three months ago.
Speaker A
But, wait a minute, where does that archived information go? Tactic number three, create an archive.md.
Speaker A
Here's a simple visualization. Your memory.md is a whiteboard that contains active projects and key facts you need to reference every day. Your archive.md is the filing cabinet with a complete record of everything you've done. And here's a key insight. Co-work does not
Speaker A
read archive.md every session. It's only when you ask something like, "What happened with the e-list three months ago?" Does it then check the archive.md file to find the answer? And because archive.md isn't loaded at session start, it doesn't need to have a size
Speaker A
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
Speaker A
whole thing, but basically, this prompt first creates your archive.md file, then adds the memory rules to your claw.md, and teaches co-work which entries to keep in memory.md and which to archive. Pro tip, you want to create a separate memory.md for each
Speaker A
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 root memory.md to see the project exists, then jumps to the project
Speaker A
memory.md to read project specific information like notion pages, email subject lines, past decisions, and current [music] status. And this cascading setup is why my root memory.md has never gone above 100 lines even after months of aggressive daily use.
Speaker A
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
Speaker A
same limitations as Claude projects. For instance, I used to rely on this Claude project to write my weekly newsletter.
Speaker A
And within this project, we have project instructions over here, a project knowledge file, and auto-generated 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
Speaker A
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
Speaker A
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 Claude projects into co-work, and the process
Speaker A
is simple. The project instructions essentially become the workstation Claude.md file, project memory becomes the memory.md file, and knowledge files get added to the project resources folder. Here's what to do in practice.
Speaker A
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,
Speaker A
paste the project 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. I might fast
Speaker A
forward this. [music] In the meantime though, let's head on over to my free template. Uh this is linked again, linked down below.
Speaker A
Copy this simple migration prompt, paste it into Co-work. And then, back in my downloads, share both the project info.md 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,
Speaker A
it's done. Let's go over what Co-work just did. First, it created a newsletter workstation folder. My newsletter's called Workspace Essentials, but this is a newsletter workstation folder.
Speaker A
Second, it created a workstation claw.md file that contains the same workflow as the original project instructions.
Speaker A
Third, it created a memory.md file with labeled instructions that I can actually edit like so.
Speaker A
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 claw.md file
Speaker A
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
Speaker A
can simply tell Co-work, "Hey, add a rule to my newsletter workstation. Each edition should have a maximum of three emojis." And Co-work will make the change directly in the newsletter claw.md file, as you can see right here.
Speaker A
And let's say I just published the latest issue. I can tell Co-work to add the latest edition to the newsletter examples file, pasting the copy, let it run, and after a minute I'm not going to wait, I'm too impatient. It will be
Speaker A
added to the newsletter examples recent markdown file. I cannot stress how much of a game-changer this is compared to the regular chatbots. This is how our co-work workspace compounds. Every improvement, every change we make today makes tomorrow's output better. By the
Speaker A
way, if you want my complete system with pre-built workstation templates and then step-by-step walk-through so you can skip the trial and error of building from scratch, I'm putting together a co-work academy course and can sign up for the waitlist down below. Moving on
Speaker A
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.
Speaker A
Back in my actual co-work 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
Speaker A
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?
Speaker A
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.
Speaker A
In contrast, once a newsletter draft is finalized, I can trigger my newsletter subject line 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
Speaker A
here, it'll 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,
Speaker A
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.
Speaker A
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
Speaker A
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.
Topics:Claude Co-workproductivity tipsworkspace setupmarkdown filesObsidiantoken optimizationproject managementfile organizationCo-work toolkitJeff Su
