Прежде чем работать с Claude Cowork, собери себе рабочее пространство

Раньше я получал от Claude Cowork посредственные результаты, и долго думал, что это инструмент сырой. На самом деле сырым был не Cowork, а моё рабочее пространство, в которое я его пускал.

Большинство людей делают с Cowork одно и то же: открывают папку, пишут промпт, надеются на лучшее. Иногда срабатывает. Чаще нет, и человек закрывает вкладку с ощущением, что инструмент перехвалили.

Тут важно понимать одну вещь. Это не вина Cowork. Он заходит в твоё рабочее пространство абсолютно без контекста, без правил, без понимания того, как у тебя в принципе принято работать, и начинает импровизировать. Он не знает, какой тон тебе нужен. Не знает, чего он не должен додумывать. Не знает, какие файлы обязательно надо прочитать перед началом любой задачи. И на выходе ты получаешь усреднённый результат, который технически не плох, но и не зацепляет.

Именно поэтому многие пробуют Cowork и решают, что это «ещё один чат, только с доступом к файлам». В этом гайде я покажу систему, которая эту проблему решает. Никакого кода, никаких сложных настроек, никаких десяти папок с непонятной логикой. Просто структура, которая работает.

По итогу у тебя будет:

• Минимальная система папок и файлов, дающая Cowork контекст и снимающая с него необходимость импровизировать
• Применение этой системы на четырёх реальных кейсах
• Понимание, как промптить такую систему (спойлер: промпты будут короткими, всю тяжёлую работу делают файлы)

Cowork нужны не лучшие промпты. Ему нужна система

Если ты пришёл из мира обычных чат-ботов, у тебя в голове такая логика: лучше промпт — лучше результат. Кажется, что главное мастерство это уметь сформулировать запрос.

В Claude Cowork эта логика больше не работает. Точнее, работает, но второстепенно. Главное теперь не промпт, а рабочее пространство, в которое ты Cowork запускаешь. Потому что он работает не только с тем, что ты вводишь в текстовое поле, он работает со всем, что лежит в папке, к которой у него есть доступ. С твоими файлами проекта. С твоими рабочими правилами. С твоими черновиками и примерами того, что ты считаешь хорошим результатом.

Задача — превратить твой способ работы в небольшую переиспользуемую систему из файлов. Один раз собрал, дальше пользуешься без необходимости каждый раз заново всё объяснять.

Вот общая схема того, что мы построим:

Переход от «открой папку и пиши промпт» к этой структуре выглядит небольшим. На самом деле он принципиальный. Как только твой способ работы переезжает в файлы, Cowork перестаёт каждый раз начинать с нуля. И его выдача перестаёт ощущаться как «нагенерил случайный текст», а начинает звучать так, будто инструмент уже знает, как ты работаешь.

Быстрый сетап: установка Cowork

Сначала технические шаги, потом сама система. Чтобы пользоваться Cowork, тебе нужен Claude для десктопа. Идёшь на claude.com/downloads, качаешь Claude Desktop, ставишь, заходишь в свой аккаунт. После установки в боковой панели выбираешь Cowork. Всё, ты внутри.

Быстрый сетап: глобальные инструкции

Глобальные инструкции — это место, где ты задаёшь поведение Cowork по умолчанию, которое будет применяться в каждой новой сессии. Открываешь меню профиля, идёшь в Settings → Cowork → Global Instructions и сохраняешь туда нужный текст.

Вставляешь туда такой текст:

Это базовое поведение, на которое Cowork будет опираться до того, как считает реальный контекст из твоего пространства.

Минимальная структура, с которой я бы стартовал

Я сознательно хочу убрать из этой системы всё лишнее. Если бы я делал такое пространство сегодня с нуля, я бы:

• Не стал бы начинать с десяти папок
• Не стал бы выкатывать целый огромный шаблон со всеми возможными разделами
• Начал бы с четырёх папок и двух файлов, и больше ничего

Вот структура:

На компьютере она выглядит вот так:

Этого уже достаточно, чтобы начать. По каждой папке:

• system/ — базовые правила работы Cowork, которые меняются редко
• context/ — стабильный контекст про тебя и твою работу, тоже меняется редко
• projects/ — активная работа, эта папка меняется от задачи к задаче
• outputs/ — всё, что Cowork производит на выходе

Маленькая структура, которая может разрастаться без превращения в помойку. Но сами папки без содержимого Cowork мало что говорят. Вся магия начинается, когда внутри появляются файлы.

Два файла, которые оживляют структуру

Папки дают Cowork место для работы. Файлы говорят ему, как именно работать. На старте достаточно двух файлов:

1. context/HOW-I-WORK.md
2. system/SYSTEM-RULES.md

HOW-I-WORK.md описывает, кто ты в этом рабочем пространстве: чем занимаешься, как мыслишь, как пишешь, как общаешься, что считаешь качественной работой, а что халтурой.

SYSTEM-RULES.md определяет, как Cowork должен себя вести: когда уточнять что-то перед действием, чего никогда не додумывать, как работать с неопределённостью, как выглядит сильный результат на выходе.

Что обычно лежит внутри HOW-I-WORK.md:

• Чем ты занимаешься профессионально
• Для кого ты это делаешь (твоя аудитория или клиенты)
• Как ты мыслишь и подходишь к задачам
• Как ты общаешься, какой у тебя стиль
• Что в текстах звучит как ты, а что точно нет
• Что тебе категорически не нравится в работе других
• Какие источники для тебя важнее при противоречивых данных
• Реальные примеры твоих работ (если есть смысл их сюда положить)

Что обычно лежит внутри SYSTEM-RULES.md:

• Базовые принципы, по которым Cowork должен работать
• Когда он должен задавать вопросы перед действием
• Как себя вести в процессе выполнения задачи
• Как работать с неопределённостью и противоречивыми данными
• Что считается сильным результатом
• Жёсткие ограничения, которые нельзя нарушать
• Финальная проверка перед сдачей результата

Вот как структура выглядит в сборе:

Не пиши эти файлы вручную

И вот тут самое важное, что я понял на собственном опыте. Эти два файла я бы ни в коем случае не стал писать с нуля, садясь за пустой документ.

Причина простая. Когда ты сам пишешь о себе с чистого листа, ты автоматически начинаешь описывать не реального себя, а ту версию себя, которой хотел бы быть. Идеального работника с идеальными привычками, которого не существует в природе. Cowork получает на вход эту вылизанную легенду, а потом сталкивается с тобой настоящим, и получается рассинхрон.

Гораздо лучше работает другой подход — собрать оба файла через интервью. Cowork сам задаёт тебе серию вопросов, ты честно отвечаешь, и на выходе он генерирует файлы на основе твоих реальных ответов. То, что ты бы сам про себя никогда не сформулировал, проявляется через диалог.

Хорошее интервью вытаскивает то, что почти никто бы не написал самостоятельно:

• Как ты на самом деле работаешь, а не как тебе кажется
• Как ты на самом деле пишешь
• Что ты ценишь в сильных результатах, и от чего сразу теряешь доверие к слабым
• Что Cowork никогда не должен принимать за данность
• Какая помощь тебе реально нужна (а не та, которой ты якобы хочешь)

Ниже промпт для такого интервью. Скопируй его в Cowork и отвечай по одному вопросу за раз. Будет около пятидесяти вопросов, и качество финальных файлов прямо зависит от того, насколько детально и честно ты будешь отвечать. На халяву тут не получится.

После того как Cowork прогонит тебя через эти вопросы и выдаст два файла, ты получаешь то, чего нельзя получить никаким другим способом. Не абстрактные правила, которые я скачал из интернета и переименовал, а живые файлы про тебя, под твою работу, под твою аудиторию, под твои триггеры. Это и есть тот самый сдвиг, ради которого мы всё это собираем.

Никаких файлов ради файлов. Никаких бесконечных промптов, чтобы каждый раз объяснять Cowork контекст с нуля. Только минимальная структура, два живых файла и Cowork, который наконец-то понимает, с кем работает.

Как применять эту систему: четыре кейса

Главный плюс этой структуры в том, что она работает для любой задачи. Статья, отчёт, презентация, ресёрч проекта, еженедельная сводка, коммерческое предложение, разбор результатов — логика везде одна.

Папка проекта + два базовых файла + короткий промпт

Это и есть весь рецепт. Тебе не надо каждый раз переизобретать колесо. Меняется только содержимое папки projects/ и формулировка короткого промпта-триггера.

То есть:

• system/SYSTEM-RULES.md остаётся почти неизменным
• context/HOW-I-WORK.md тоже почти неизменен
• Меняется только содержимое внутри projects/

В папке проектов хранится всё, что касается конкретной задачи: бриф, заметки, материалы для референса, черновики. Дальше посмотрим четыре конкретных примера, чтобы стало понятно как это работает в реальности.

Пример 1. Превращаем разрозненные заметки в бриф для принятия решений

Внутри projects/ создаёшь подпапку под конкретную задачу. Например, тебе нужно разобрать движения конкурентов за последний месяц и понять, надо ли реагировать.

Сама система не меняется ни на каплю. Меняется только то, что лежит внутри market-review/.

Файл notes.md может выглядеть так:

В references/ кладёшь всё, что помогает интерпретировать заметки: предыдущие презентации, отчёты по конкурентам, бенчмарки, внутренние документы. В drafts/ появятся варианты брифа: первая версия, сжатая, версия с акцентом на руководство.

Промпт может быть совсем простым:

Метод не поменялся. Поменялось только содержимое папки проекта. Вот что Cowork выдал на выходе:

Бриф даёт точку опоры для решения, разделяет риски и варианты, и заканчивается конкретной рекомендацией с дальнейшими шагами. Это совсем другое качество, чем общая сводка из обычного чат-бота.

Пример 2. Готовим отчёт для руководства к встрече

Структура становится чуть сложнее, потому что теперь у тебя не разрозненные заметки, а уже сформированная подложка для серьёзного документа.

Файл brief.md выглядит так:

А notes.md примерно так:

В references/ идут метрики, предыдущие квартальные отчёты, финансовая документация, сводки от команд, старые слайды. В drafts/ — первая версия отчёта, укороченный вариант, версия с акцентом на риски, заготовка под слайды.

Промпт:

Результат:

Cowork превратил разрозненный контекст в чёткий отчёт с метриками, рисками и решениями, готовыми к обсуждению на встрече.

Пример 3. Делаем план презентации, не начиная с пустого экрана

Структура папки:

Файл brief.md:

references/ — метрики, предыдущие квартальные отчёты, финансовые документы, сводки команд, старые слайды. drafts/ — первая структура, сжатый вариант, версия с акцентом на риски, готовый план под слайды.

Промпт:

Что получилось:

Cowork не просто упорядочил мысли в красивую структуру. Он превратил размытое стратегическое обновление в презентацию с понятной аркой повествования.

Пример 4 (бонусный, не из оригинала). Ресёрч крипто-проекта перед инвестицией

До этого все три кейса были про корпоративный мир, но логика этой системы шире. Покажу как это работает в крипто-нише, где задача формализуется так: разбросанные источники нужно превратить в структурированный разбор с конкретной рекомендацией брать или не брать.

Допустим, ты собираешься заходить в новый проект. Источников много: токеномика на сайте, тред в X от команды, обсуждения в Telegram-чатах, тейки от инфлюенсеров, твои собственные заметки по похожим проектам, скрины важных графиков. Обычно это всё валяется по разным вкладкам, и в момент принятия решения ты пытаешься удержать всё в голове одновременно.

Со связкой Cowork и правильной папкой это выглядит так:

Файл brief.md:

В references/ лежит всё сырое: твиты команды за последние пару месяцев, скрины обсуждений в чатах, заметки по похожим проектам, в которые ты заходил раньше. В tokenomics.md ты сводишь ключевые цифры по распределению токенов, разлокам, инфляции.

Промпт:

На выходе ты получаешь структурированный документ, который опирается на реальные данные из твоей же папки. Никаких галлюцинаций про несуществующие партнёрства, потому что Cowork работает только с тем, что лежит в references/. Никаких общих фраз про «инновационную блокчейн-технологию», потому что у тебя в HOW-I-WORK.md написано, что ты эти фразы терпеть не можешь. И никакой подмены анализа поверхностным согласием, потому что в SYSTEM-RULES.md явно сказано, что Cowork должен подсвечивать красные флаги, а не закрывать на них глаза.

Та же логика работает для любых крипто-задач. Месячный разбор результатов трейдинга? Кидаешь в папку выгрузки сделок, скрины P&L, заметки о том, что пошло не так — Cowork собирает отчёт по паттернам и ошибкам. Подготовка статьи в свой канал? Кладёшь прошлые посты для удержания стиля, ресёрч по теме, ключевые тейки — на выходе получаешь черновик в твоём голосе.

Как промптить Cowork в этой системе

К этому моменту у тебя уже есть всё необходимое. Но есть разница между аккуратно собранным пространством и пространством, которое реально экономит время. Эта разница в том, как ты с ним общаешься после того, как оно собрано. Делюсь двумя любимыми подходами.

Подход с уточняющими вопросами

Это просто способ запуска Cowork, при котором он не лезет сразу делать работу, а сначала задаёт вопросы по неясным местам. Логика такая:

• Cowork читает папку проекта
• Если в контексте есть пробелы, он задаёт уточняющие вопросы
• И только после того, как пробелы закрыты, начинает работать

Активируется это самой формулировкой запроса. Например:

Ты уже видел этот подход в действии в примерах выше:

• В первом примере Cowork спросил, в чём именно состоит решение, которое нужно принять
• Во втором — уточнил по инициативам и какое решение должно выйти из встречи
• В третьем — спросил про рабочие потоки, следующие шаги и формат

Этот подход имеет смысл, когда:

• Цель задачи ещё не полностью ясна
• Аудитория результата важна и её нельзя обобщать
• Результат имеет реальные последствия
• Одно неверное предположение может развалить всю работу
• Возможных вариантов выдачи несколько, и ты хочешь, чтобы Cowork выбрал правильный

Простыми словами — используй его всякий раз, когда не хочешь, чтобы Cowork самостоятельно додумывал пробелы.

Короткие промпты

Короткий промпт хорошо работает только потому, что рабочее пространство уже содержит весь нужный контекст. Это принципиально.

В пустом чате короткий промпт обычно проваливается. Cowork-у нужно объяснять всё с нуля, и без подробностей он начинает гадать. Но в правильно настроенном пространстве, где уже есть:

…промпту больше не надо тащить на себе всю нагрузку. Контекст живёт в файлах. Промпт просто запускает систему. Например:

Или ещё короче:

Никакой магии. Твоё пространство делает основную работу за тебя.

И это диагностический признак сразу. Если тебе постоянно приходится писать длинные промпты, чтобы Cowork хоть как-то понял базу, проблема не в промпте. Проблема в том, что в файлах пока недостаточно контекста, и его нужно туда дописать.

Как наращивать систему, не превращая её в свалку

Когда люди понимают саму концепцию, они обычно совершают одну из двух ошибок. Либо остаются на самой минимальной структуре годами и не расширяют её, хотя задачи давно переросли двух файлов. Либо наоборот, сразу же строят гигантский монстр-сетап с десятками файлов на каждый возможный случай, который сами потом не могут поддерживать.

Не делай ни того, ни другого. Главный принцип: начинай с малого и пусть сама работа подсказывает, чего не хватает. Расширяй систему только тогда, когда замечаешь повторяющийся паттерн. Не создавай файлы потому, что они «могут когда-нибудь пригодиться». Создавай их, когда видишь, что какая-то логика уже повторяется и заслуживает отдельного места.

Папку system/ имеет смысл расширять, когда:

• Cowork раз за разом совершает одну и ту же ошибку
• У тебя появились правила, которые применяются почти всегда
• Твой стандарт качества стал чётче и заслуживает явной фиксации
• Ты хочешь зафиксировать способ работы, который не должен меняться от проекта к проекту

Например, если Cowork постоянно путает резюме с рекомендацией, это уже повод дописать явное правило в SYSTEM-RULES.md или вынести его в отдельный файл.

Папку context/ имеет смысл расширять, когда:

• Твоя аудитория уже достаточно сложная, чтобы получить свой файл
• Твой стиль письма требует более точного описания
• Хочется разделить материалы, тональность и правила приоритета источников
• Твой способ работы перестал умещаться в один файл HOW-I-WORK.md

Цель — не плодить файлы, а сделать контекст реально пригодным для использования.

Папку projects/ имеет смысл расширять, когда:

• Определённый тип задач всегда использует одни и те же подфайлы
• Внутри проекта нужен больший порядок
• Хочется чётче разделить бриф, заметки, материалы и черновики
• Повторяющаяся задача уже обросла собственной логикой

Большая часть изменений в системе как раз и происходит здесь.

Как понять, что система растёт правильно

Это видно по практике. Каждая новая задача требует:

• Меньше объяснений на старте
• Меньше правок результата
• Меньше перезапусков с нуля
• На выходе появляется что-то полезное уже с первого подхода

Если это происходит — система развивается правильно. Если нет, то ты просто наращиваешь структуру ради ощущения «у меня всё организовано», и эта структура реальной работе не помогает. Тогда стоит откатиться назад и подумать, какие файлы из системы реально используются, а какие просто занимают место.