Після кількох місяців щоденної роботи з Claude Cowork, американський продакт- та контент-менеджер Джефф Су фактично переніс на цю систему все своє життя й бізнес. Інструкції для ШІ, робочі процеси, пам’ять про проєкти — усе живе в markdown‑файлах на кшталт CLAUDE.md і MEMORY.md. Саме навколо цих файлів і виникає головна проблема: без чіткої структури вони швидко розростаються, стають нечитабельними, а кожна сесія з Claude починає «з’їдати» дедалі більше токенів.
У цьому матеріалі — про дві ключові ідеї, які Су виніс із власного досвіду: використання Obsidian як «markdown‑перекладача» для Cowork і агресивне винесення деталей із CLAUDE.md у окремі reference‑файли. Разом вони перетворюють хаотичний набір інструкцій на керовану систему, де Claude завантажує лише те, що потрібно саме зараз.
Obsidian як «лінза» для CLAUDE.md і MEMORY.md
Claude Cowork зберігає інструкції та пам’ять у звичайних .md‑файлах. Формально це зручно: їх можна відкрити будь-яким текстовим редактором, версіонувати в Git, копіювати між проєктами. На практиці — сирий markdown швидко перетворюється на стіну тексту, яку незручно читати й редагувати.
Су пропонує просте рішення: використовувати безкоштовний застосунок Obsidian не як повноцінний PKM‑комбайн, а як «markdown‑перекладач» для Cowork.
Суть підходу така. Замість того, щоб відкривати окремі файли, користувач вказує Obsidian на всю папку Cowork як на vault. Після цього всі .md‑файли робочого простору — CLAUDE.md, MEMORY.md, додаткові інструкції — миттєво відображаються з заголовками, жирним шрифтом, списками та іншою розміткою. Те, що в текстовому редакторі виглядало як суцільний потік символів, у Obsidian перетворюється на структурований документ, який можна проглядати як сторінку.
Ключовий момент: Су не закликає вчити екосистему Obsidian, будувати графи знань чи підключати плагіни. У цьому сценарії Obsidian — лише зручна «лінза» для читання та редагування файлів Cowork. Будь-яка зміна, зроблена в Obsidian, одразу зберігається в тих самих файлах, які використовує Claude. Закривши й знову відкривши Cowork, користувач бачить оновлені інструкції вже в інтерфейсі Anthropic.
Декілька дрібних, але практичних деталей роблять цей підхід ще кориснішим. У Obsidian можна збільшити масштаб, щоб комфортно читати довгі інструкції; перемкнутися в режим «тільки читання», аби випадково не зіпсувати критичні правила; увімкнути відображення всіх типів файлів у боковій панелі, щоб поруч із markdown‑інструкціями бачити таблиці, PDF чи зображення, які також живуть у робочій папці Cowork. У результаті CLAUDE.md і MEMORY.md перестають бути «чорними ящиками» й стають звичайними документами, з якими можна працювати як із будь-яким робочим текстом.
Це не лише питання зручності. Коли інструкції легко читати, їх легше підтримувати в актуальному стані, помічати дублікати, суперечності чи застарілі правила. А саме підтримуваність стає критичною, коли Cowork починає обслуговувати десятки робочих сценаріїв.
Маршрутизація в CLAUDE.md: таблиця замість хаосу
У центрі будь-якого робочого простору Cowork — файл CLAUDE.md. Він завантажується на початку кожної сесії, задає базові правила поведінки моделі, описує, як працює пам’ять, і вирішує, які «робочі станції» (workstations) слід підключити під конкретне завдання. Якщо цей файл перетворюється на енциклопедію всього, що коли-небудь вигадував користувач, кожна взаємодія з Claude стає дорожчою й менш передбачуваною.
Су вибудував у CLAUDE.md чітку структуру з шести секцій, але для теми розвантаження особливо важливі дві: routing map і references.
Routing map — це таблиця, яка виконує роль карти маршрутизації завдань. У ній кожен тип задачі пов’язаний із конкретною робочою станцією. Наприклад, листування відправляється в «Email HQ», робота з китайськими проєктами — у «China Desk», брейнштормінг — у «Clarity Partner». Claude дивиться на цю таблицю, щоб вирішити, який набір інструкцій і пам’яті підвантажити під поточний запит.
Важливий нюанс: у самій таблиці немає детальних інструкцій для кожної станції. Вона лише вказує, куди скерувати завдання. Усе, що стосується конкретної логіки роботи «Email HQ» чи «China Desk», може й має жити в окремих файлах. Такий поділ дозволяє тримати CLAUDE.md компактним, а спеціалізовані правила — локалізованими там, де вони справді потрібні.
References — ще один ключовий елемент. Це секція з однорядковими посиланнями на додаткові файли, які Claude завантажує лише за потреби. Наприклад, файл voice_principles.md із детальними вимогами до тону й стилю контенту не підтягується в кожну сесію автоматично. Він підключається лише тоді, коли користувач працює над текстами, де ці принципи мають значення. Таким чином, кореневий файл залишається «худим», а спеціалізовані інструкції не збільшують токен‑футпринт кожної взаємодії.
Ця логіка — таблиця для маршрутизації плюс посилання на on‑demand ресурси — створює основу для подальшого розвантаження CLAUDE.md. Вона дозволяє відокремити те, що має бути завжди «в голові» Claude, від того, що достатньо тримати «на полиці» й діставати лише за потреби.
Як винести деталі з CLAUDE.md у reference‑файли
Коли CLAUDE.md починає розростатися, перший інстинкт — просто додати ще один розділ. Су пропонує протилежну стратегію: усе, що не потрібно в кожній сесії, потрібно виносити в окремі reference‑файли, залишаючи в корені лише короткі вказівки.
Він використовує простий тест. Якщо правило або блок інструкцій потрібні Claude у кожній взаємодії, вони залишаються в CLAUDE.md. Якщо ж вони стосуються лише конкретного типу завдань, їх слід винести. Прикладом «ядерного» правила є governance MECE principle — запис у CLAUDE.md, який вимагає, щоб усі інструкції в робочому просторі були «mutually exclusive and collectively exhaustive». Це метаправило, що визначає, як організовані всі інші правила, тому воно має бути завжди доступним моделі.
Натомість детальні правила створення файлів — типовий кандидат на винесення. Су показує, як у нього замість 22 пунктів інструкцій у кореневому файлі залишається лише один рядок‑вказівка: прочитати окремий документ перед створенням нового файлу. Самі ж правила переїжджають у новий reference‑файл, розміщений, наприклад, у папці 00-resources. Claude більше не тягне ці деталі в кожну сесію, але може завантажити їх, коли користувач справді створює новий документ.
Той самий підхід застосовується до секції «creating new workstations». Створення нових робочих станцій — не щоденна операція. Тримати повний шаблон і покрокові інструкції в CLAUDE.md означає платити токенами за інформацію, яка 95% часу не використовується. Су переносить цю секцію в окремий файл‑шаблон, а в корені залишає лише короткий запис у таблиці references на кшталт «прочитати при створенні нової робочої станції».
Цікаво, що сам процес перенесення він також делегує Claude. Замість того, щоб вручну вирізати й вставляти текст, користувач може дати Cowork чітку команду: перемістити певну секцію з CLAUDE.md у новий reference‑файл і замінити її в корені однорядковим посиланням. Claude виконує операцію, оновлює файлову структуру (наприклад, додає новий документ у 00-resources), а користувач уже в Obsidian бачить, що секція зникла з кореня й з’явилася в окремому файлі.
Цей прийом перетворює «прибирання» в CLAUDE.md на напівавтоматичний процес. Достатньо виявити блок, який стосується вузького сценарію, і сформулювати запит до Cowork на його релокацію. Крок за кроком кореневий файл худне, але жодна інструкція не губиться — вона просто переїжджає в reference‑простір, який завантажується лише за потреби.
Розмежування правил і фактів: що зберігати в CLAUDE.md, а що в MEMORY.md
Ще одна типова проблема користувачів Cowork — змішування вмісту CLAUDE.md і MEMORY.md. У кореневий файл часто потрапляють факти про бізнес чи проєкти, а в пам’ять — поведінкові правила. У результаті Claude витрачає токени на читання зайвих даних, а якість відповіді падає, бо модель не розуміє, що є інструкцією, а що — контекстом.
Су пропонує чіткий критерій, який він кодує прямо в секції memory system CLAUDE.md. Кожен запис проходить два тести. Якщо формулювання є прескриптивним і містить слова на кшталт «always» або «never», воно належить до CLAUDE.md. Це інструкція, яка визначає, як Claude має поводитися. Наприклад, правило «перед тим, як писати новий лист, перевірити, чи існує пов’язаний тред із цим отримувачем» — типовий приклад поведінкової настанови. Воно описує послідовність дій, а не стан світу, тому має жити в секції rules кореневого файлу.
Якщо ж запис описує факт, який може змінитися, його місце в MEMORY.md. Фраза «моя компанія використовує Microsoft Copilot» — саме такий випадок. Це характеристика поточного стану інфраструктури, яка завтра може стати іншою. Для Claude важливо знати цей факт, але не як інструкцію, а як елемент контексту, який можна оновити. Тому він має бути в пам’яті, а не в наборі правил.
Су йде далі й пропонує використати сам Cowork для ревізії. Користувач може попросити Claude переглянути CLAUDE.md і MEMORY.md, позначити записи, які «переплуталися» (тобто факти в кореневому файлі й правила в пам’яті), і запропонувати, куди їх перемістити. Після цього достатньо дати команду «продовжити з рекомендованими змінами», і модель сама рознесе записи по правильних файлах.
Це розмежування має прямий вплив на ефективність. CLAUDE.md залишається компактним набором стабільних правил, які рідко змінюються й завжди потрібні на старті сесії. MEMORY.md перетворюється на динамічний простір фактів, що відображають поточний стан проєктів, інструментів і бізнесу. Коли кожен тип інформації опиняється «у своєму домі», Claude краще розуміє, що від нього очікують, і менше витрачає токенів на зайві читання.
Lean‑підхід до Cowork: коли менше — означає краще
У підсумку стратегія, яку демонструє Су, зводиться до кількох взаємопов’язаних принципів. По‑перше, інструкції мають бути видимими й зручними для людини. Використання Obsidian як «markdown‑перекладача» робить CLAUDE.md і MEMORY.md такими ж читабельними, як будь-який документ у текстовому редакторі. Це знижує бар’єр для регулярного обслуговування правил.
По‑друге, кореневий файл не повинен бути енциклопедією. Routing map і references дозволяють тримати в CLAUDE.md лише те, що справді потрібно в кожній сесії: базові правила, карту робочих станцій, ключові метапринципи. Усе інше — детальні шаблони, рідкісні сценарії, специфічні інструкції — переїжджає в reference‑файли, які Claude завантажує лише тоді, коли користувач запускає відповідний процес.
По‑третє, правила й факти мають бути розведені по різних каналах. Прескриптивний контент — у CLAUDE.md, фактичний — у MEMORY.md. Це не лише покращує якість відповідей, а й спрощує подальшу автоматизацію: Claude може сам перевіряти, куди потрапляє новий запис, і за потреби пропонувати його перемістити.
Нарешті, важливо, що всі ці операції — від перенесення секцій у reference‑файли до ревізії пам’яті — сам Су виконує за участі Claude Cowork. Модель не лише споживає інструкції, а й допомагає їх реорганізовувати. У поєднанні з Obsidian як зручною «лінзою» це створює замкнений цикл: людина формулює принципи, Claude допомагає їх реалізувати в структурі файлів, а Obsidian робить цю структуру прозорою й керованою.
Для користувачів, які прагнуть перетворити Cowork із «чорної скриньки» на передбачуваний робочий інструмент, саме така дисципліна роботи з CLAUDE.md, MEMORY.md і reference‑файлами може стати вирішальною. Менше зайвих рядків у корені, більше логіки в маршрутизації, чіткий поділ правил і фактів — і кожна сесія з Claude стає трохи дешевшою, швидшою й зрозумілішою.
Джерело
Top 5 Claude Cowork Tips I Wish I Knew from Day One — Jeff Su