Jonathon's AI Wiki

Top 5 Claude Cowork Tips I Wish I Knew from Day One (Jeff)

7 min read

Source: Top 5 Claude Cowork Tips I Wish I Knew from Day One (YouTube 4wvLHFgnQZQ), Jeff, 2026-05-21.

Five specific tactical tips for setting up Claude Cowork’s foundation correctly from day one — based on five months of daily Cowork use (“I’m in debt from token usage”). Each tip is a small but high-leverage configuration choice that compounds. Headline tactics: Obsidian as Cowork’s file viewer, 300-line claude.md ceiling (Jeff’s drop from 600→250 lines = ~25% token reduction), prescriptive-rules-vs-changeable-facts routing between claude.md and memory.md, migrating Claude Projects → Cowork workstations, and the “is this a place I work or a thing I do?” test for skill vs workstation. Adjacent companion to Ben’s comprehensive Cowork feature primer (same week) but Ben covers the full feature surface; Jeff focuses on the five foundational mistakes.

Key Takeaways

Tip 1 — The Markdown Translator (Obsidian as your Cowork viewer)

  • The problem. Cowork’s claude.md and memory.md files are raw markdown. Editing them inside Cowork’s UI is friction-heavy (“opening this just costs 20 tokens — joke, but kind of true”).
  • The fix. Install Obsidian (free). Open folder as vault, point at your co-workspace folder. Now every .md file renders properly with headings, bold text, bullets — readable + editable.
  • Tactical pro tips.
    • Cmd/Ctrl + + to zoom in.
    • Reading mode icon to lock the page (avoid accidental edits).
    • Obsidian Settings → Files & Links → toggle Show all file types on so you can see non-.md files (spreadsheets, PDFs, images) in the sidebar.
  • Obsidian is just a lens. No need to learn the rest of Obsidian. It’s a markdown viewer over the same files Cowork edits.

Tip 2 — The 300-Line Rule (and how to relocate non-essentials)

  • The problem. Your root claude.md loads every session. A bloated claude.md wastes tokens every turn. Jeff cut his from 600 → 250 lines and saw ~25% token usage drop.
  • Three tactics:
    1. Bare-essentials sections only. Jeff’s template has six sections: Memory system (tells Cowork to read memory.md at session start), Preferences (tone, length, format), Rules (behavioral guardrails), Routing map (which workstation to load by task type), References (one-line pointers to on-demand files), Creating new workstations (workstation-creation template).
    2. Relocate non-essentials. Test: “Does Cowork need this every session or only when a specific task comes up?” If specific-task-only, relocate it. Example: a 22-bullet file-creation ruleset moved out to 00 resources/file-creation-rules.md, replaced by a one-line pointer in the references table.
    3. Hard ceiling: 200–250 lines, 300 absolute max.
  • Just ask Cowork to relocate. Example prompt: “Move the creating-new-workstation section out of my root claude.md into a new reference file and replace it with a one-line pointer in my references table.” Cowork executes the refactor.

Tip 3 — Write to the Right File (prescriptive vs factual)

  • The most common Cowork bug: entries that belong in claude.md end up in memory.md and vice versa. “This confusion tanks output quality.”
  • Two tests:
    • Prescriptive (always / never / before-doing-X-do-Y) → claude.md. Example: “Before drafting a new email, check if a related thread already exists with that recipient.”
    • Factual (could change tomorrow) → memory.md. Example: “My company uses Microsoft Copilot” — fact, not rule.
  • The audit prompt. Tell Cowork: “Review my root claude.md and memory.md. Flag any entry whose primary purpose is recording a fact or status rather than prescribing behavior. And in memory, flag any entry whose primary purpose is telling you how to behave rather than recording a fact. Recommend where each flagged entry should move.”
  • Cascading project memory pattern. Each workstation/project gets its own memory.md. Root memory (“active projects + scheduled tasks + core memory”) is small (Jeff’s root memory has never gone above 100 lines with months of daily use). Project-specific memory (notion pages, past decisions, etc.) lives in <project>/memory.md.

The Memory Diet

  • memory.md loads every session — keep it lean. Three-section structure: Active projects + work (current items with status), Scheduled tasks (so Cowork doesn’t dupe an existing cron), Core memory (persistent facts — Jeff’s career, LinkedIn, business address).
  • Entry format rule. “One to two sentences max for every memory entry.” Concise entries from day one — long paragraphs bloat tokens.
  • Hard ceiling rule for memory.md: 150 lines. When breached, compress + archive — never raise the ceiling.
  • archive.md for everything else. Filing cabinet. Cowork doesn’t load it every session — only on demand (“what happened with the e-list 3 months ago?”). No size ceiling because it’s not in the always-loaded path.

Tip 4 — The Project Transplant (Claude Projects → Cowork Workstations)

  • Why migrate. Cowork doesn’t have Claude Project limitations: editing instructions is friction-heavy in Claude Projects; project memory is auto-generated paragraphs you can’t structure; knowledge files can’t be written back by Claude.
  • The mapping.
    • Project instructions → workstation claude.md.
    • Project memory → workstation memory.md.
    • Knowledge files → <workstation>/resources/<file>.md.
  • The migration steps.
    1. Copy project instructions into a text doc.
    2. Paste two newlines + a Header 1 “Project memory” + the project memory contents.
    3. Save as project-info.md.
    4. Download any linked Google docs as markdown.
    5. Paste a migration prompt into Cowork along with both files. Cowork does the rest.
  • What Cowork generates. New workstation folder, workstation claude.md mirroring the project instructions, structured memory.md you can edit, resources/ folder with each knowledge file as a separate .md. Even adds a routing-map entry mapping <task> → the new workstation.
  • The compound win. Every improvement to a workstation makes tomorrow’s output better — unlike chat-only project tweaks that don’t compound.

Tip 5 — The Skill Check (workstation or skill?)

  • The test. Ask: “Is this a place I work or a thing I do?”
    • Ongoing area of work with its own voice + accumulated context → workstation. Has decision points, judgment, and human-in-the-loop steps.
    • Repeatable process that runs the same way every time → skill. No human decisions; it’s a checklist.
  • Examples.
    • Workstation example (newsletter). “Do I have a topic? Which Google app am I covering this week?” — these are decisions Jeff has to make. Workstation, not skill.
    • Skill example (subject-line generator). Takes a final draft, applies one set of instructions, outputs 5 scored options. Same shape every time. Skill.
    • Skill example (workstation audit). Checks a workstation folder for misplaced rules + bloat + gaps. Same output structure every time (executive summary + findings + recommendations). Skill.

Try It

  1. Install Obsidian + open your Cowork folder as a vault. First step before anything else — every other tip is easier with a real markdown viewer.
  2. Measure your root claude.md line count. If it’s > 300 lines, you have token waste. Run an audit pass: which sections are prescriptive every session, which are task-specific? Relocate the task-specific ones to reference files, replace with pointers.
  3. Run the audit prompt on claude.md + memory.md. Have Cowork flag misplaced entries (rules in memory / facts in claude.md). Apply the moves.
  4. Migrate one Claude Project to a Cowork workstation. Pick a project you use weekly (newsletter, sales outreach, content repurposing). Run the migration prompt. Measure the difference in iteration speed.
  5. Cap your memory.md at 150 lines. Create archive.md. Tell Cowork to compress + archive entries older than 30 days that aren’t in the active-work section.
  6. Audit one new workflow. Pick something you do regularly that you’ve been calling “a workstation.” Run the skill-check test. If it’s actually a checklist, refactor it into a skill.

Open Questions

  • 300-line ceiling — is the source for this Anthropic guidance or Jeff’s empirical observation? Jeff cites a 200-300 word “best practice anyway” from Anthropic; the 300-line is his ceiling rule. Anthropic doesn’t publish an authoritative line count — would be worth confirming.
  • Compression algorithm. When memory.md breaches 150 lines and Cowork “compresses + archives,” what’s the actual transformation? Jeff doesn’t show the prompt. Likely a date-based + content-importance ranking.
  • Cascading project-memory cost. Each workstation having its own memory.md means each workstation triggers an additional read on the path. Token cost is per-workstation-loaded, not unbounded — but the explicit measurement isn’t shown.
  • Workstation audit skill availability. Jeff describes a workstation audit skill but it’s only available in his paid AI Accelerator community.

Graph View

Backlinks