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

Решается это небольшой системой файлов. Кода в ней нет.

Главная идея: контекст живёт в файлах

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

Шаг 1. Установка и общие инструкции

Cowork входит в настольное приложение Claude. Скачайте его с официальной страницы, войдите в аккаунт и выберите Cowork в боковой панели.

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

Ты работаешь вместе со мной в этой папке.

До начала любой задачи прочитай:
1. context/HOW-I-WORK.md
2. system/SYSTEM-RULES.md
3. папку нужного проекта в projects/

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

Главный источник данных — файлы в этой папке.
Готовые результаты сохраняй в outputs/.

Шаг 2. Четыре папки

workspace/
├── system/
├── context/
├── projects/
└── outputs/
  • system/ — правила работы Cowork. Меняются редко.
  • context/ — сведения о вас и вашей работе. Тоже меняются редко.
  • projects/ — текущие задачи, по папке на каждую.
  • outputs/ — всё, что Cowork создаёт.

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

Шаг 3. Два файла

context/HOW-I-WORK.md описывает вас:

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

system/SYSTEM-RULES.md описывает поведение Cowork:

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

Шаг 4. Не пишите эти файлы сами

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

Запрос для такого интервью:

Проведи со мной интервью, чтобы создать два файла:
1. context/HOW-I-WORK.md
2. system/SYSTEM-RULES.md

Три блока вопросов:

A. Работа. Чем я занимаюсь, что создаю, для кого,
   что ценит моя аудитория, каким источникам я доверяю,
   в чём эта папка должна мне помогать.

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

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

Как вести интервью:
- Один вопрос за раз, жди ответа.
- Не больше 50 вопросов. Остановись, когда информации достаточно.
- На расплывчатый ответ проси конкретный пример.
- Если я противоречу себе, укажи на это.
- Если я описываю желаемое, а не действительное, попроси подтверждение.
- Не хвали ответы. Просто задавай следующий вопрос.

В конце выдай оба файла целиком.
Темы, по которым данных мало, перечисли отдельным списком.
Не создавай файлы до конца интервью.

Начни с блока A.

Качество файлов зависит от подробности ответов. Заложите на интервью около часа.

Как устроена любая задача

Формула одна: папка проекта, два базовых файла и короткий запрос. От задачи к задаче меняется только содержимое projects/.

projects/
└── market-review/
    ├── brief.md
    ├── notes.md
    ├── references/
    └── drafts/
  • brief.md — цель, аудитория, что важно, чего быть не должно.
  • notes.md — сырые наблюдения и открытые вопросы.
  • references/ — материалы, на которые нужно опираться.
  • drafts/ — промежуточные версии.

Четыре примера

  • Записка для решения. В заметках лежат наблюдения о конкурентах за месяц и риски. Запрос просит документ, по которому можно принять решение, а не пересказ. На выходе варианты, риски и рекомендация.
  • Квартальный отчёт. В брифе указаны аудитория и ограничения: коротко, предположения отдельно, упор на последствия. В references/ лежат метрики и прошлые отчёты.
  • План презентации. В брифе записано, что презентация должна объяснить и чего в ней быть не должно. Запрос просит логику переходов и задачу каждого слайда.
  • Разбор проекта перед вложением. В папке собраны токеномика, сообщения команды, чужие мнения и ваши прошлые разборы. Запрос задаёт структуру: суть, активность команды, распределение токенов, сравнение с похожими проектами, красные флаги. Cowork опирается на собранные вами материалы и не выдумывает партнёрства. Решение о деньгах при этом остаётся за вами.

Как формулировать запросы

Сначала вопросы

Прочитай папку проекта.
Задай уточняющие вопросы до начала работы.

Этот приём нужен, когда цель не до конца ясна, результат увидит конкретная аудитория или одна неверная догадка обесценит всю работу.

Короткий запрос

Работай по папке проекта с учётом HOW-I-WORK и SYSTEM-RULES.
Черновик сохрани в outputs/.

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

Как расширять систему

Ошибки две: годами сидеть на минимуме, когда задачи его переросли, или сразу построить десятки файлов на все случаи. Добавляйте файл, когда видите повторение, а не на будущее.

  • system/ — когда Cowork повторяет одну ошибку или появилось правило, которое действует почти всегда.
  • context/ — когда описание аудитории или стиля перестало помещаться в один файл.
  • projects/ — когда у типовой задачи сложился постоянный набор файлов.

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