Claude Coworkを初めて使う時はこんな感じです：フォルダを開いて、リクエストを書いて、普通の結果を得て、「あ、これはファイルにアクセスできるチャットなだけか」と思う。だいたいはツール自体の問題じゃなくて、リクエストの書き方でもないんです。Coworkはコンテキストなしでフォルダに入ってくる。あなたのトーン、要件、何を勝手に推測したらいけないか、そういうのがわかってない。だから勝手に対応しちゃう。
これは小さなファイルシステムで解決します。コードは含まれていません。
主なアイデア：コンテキストはファイルに生きている
チャットボットでは回答の品質はリクエストに左右されます。Coworkはアクセス可能なフォルダにあるすべてのもので動作します：プロジェクト資料、ルール、ドラフト、良い結果の例。ファイルで一度あなたの作業方法を説明すれば、それを各リクエストで繰り返す必要がなくなります。
ステップ1：インストールと一般的な指示
CoworkはClaudeのデスクトップアプリケーションに含まれています。公式ページからダウンロードし、アカウントにログインして、サイドバーからCoworkを選択します。
その後、Coworkの設定を開いて、グローバル指示のセクションを探します。これらは新しいセッションごとに適用されます。そこに基本的な動作を記録します：
Ты работаешь вместе со мной в этой папке.
До начала любой задачи прочитай:
1. context/HOW-I-WORK.md
2. system/SYSTEM-RULES.md
3. папку нужного проекта в projects/
Если не ясны цель, аудитория или формат результата, сначала спроси.
Не придумывай факты, цифры, даты и договорённости.
Когда не уверен, скажи об этом прямо.
Главный источник данных — файлы в этой папке.
Готовые результаты сохраняй в outputs/.ステップ2：4つのフォルダ
workspace/
├── system/
├── context/
├── projects/
└── outputs/- system/ — Coworkの動作ルール。めったに変わりません。
- context/ — あなたと あなたの仕事についての情報。これもめったに変わりません。
- projects/ — 現在のタスク、各タスクに1つのフォルダ。
- outputs/ — Coworkが作成するすべてのもの。
10個のフォルダと大きなテンプレートから始めないでください。この構造はスタートに十分で、混乱なく拡張できます。
ステップ3：2つのファイル
context/HOW-I-WORK.mdがあなたを説明します：
- あなたが何をしていて、誰のためにしているか；
- タスクにどのようにアプローチするか；
- どのように書くか、何があなたのように聞こえるか、そうでないか；
- 他人の仕事で何があなたをイライラさせるか；
- 矛盾がある場合、どの情報源を信頼するか；
- あなたのテキストまたは結果の例。
system/SYSTEM-RULES.mdはCoworkの動作を説明します：
- 作業を始める前に質問するタイミング；
- 不完全または矛盾するデータの場合の対応方法；
- 強い結果と見なされるもの、弱い結果と見なされるもの；
- 厳格な禁止事項；
- 提出前の確認。
ステップ4：これらのファイルを自分で書かないでください
白紙から自分を説明する場合、人は自分がなりたい人を説明します。Coworkは美化された肖像を取得し、その後現実とは異なります。面接の方が信頼性があります：Coworkが1つずつ質問を尋ね、あなたが回答し、彼があなたの回答から両方のファイルを作成します。
そのようなインタビューのリクエスト：
Проведи со мной интервью, чтобы создать два файла:
1. context/HOW-I-WORK.md
2. system/SYSTEM-RULES.md
Три блока вопросов:
A. Работа. Чем я занимаюсь, что создаю, для кого,
что ценит моя аудитория, каким источникам я доверяю,
в чём эта папка должна мне помогать.
B. Стиль и мышление. Как я пишу в лучшей форме и на автопилоте,
какие слова для меня естественны, что я не выношу в текстах,
как я разбираю сложные задачи. Попроси реальные отрывки моих текстов.
C. Правила для тебя. Когда спрашивать до начала работы,
что нельзя додумывать, как поступать при противоречиях,
какая помощь мне полезна, а какая мешает.
Как вести интервью:
- Один вопрос за раз, жди ответа.
- Не больше 50 вопросов. Остановись, когда информации достаточно.
- На расплывчатый ответ проси конкретный пример.
- Если я противоречу себе, укажи на это.
- Если я описываю желаемое, а не действительное, попроси подтверждение.
- Не хвали ответы. Просто задавай следующий вопрос.
В конце выдай оба файла целиком.
Темы, по которым данных мало, перечисли отдельным списком.
Не создавай файлы до конца интервью.
Начни с блока A.ファイルの品質は回答の詳細さに依存します。インタビューに約1時間かかることを想定してください。
すべてのタスクがどのように構成されているか
公式は1つです：プロジェクトフォルダ、2つの基本ファイル、短いリクエスト。タスク間でprojects/の内容だけが変わります。
projects/
└── market-review/
├── brief.md
├── notes.md
├── references/
└── drafts/- brief.md — 目標、対象者、何が重要か、何があってはいけないか。
- notes.md — 生の観察と未解決の質問。
- references/ — 頼るべき資料。
- drafts/ — 中間バージョン。
4つの例
- 意思決定用メモ。ノートには1ヶ月間の競合他社に関する観察とリスクが含まれています。リクエストは言い換えではなく、決定を下すことができるドキュメントを要求します。出力にはオプション、リスク、および推奨事項が含まれます。
- 四半期報告。ブリーフには対象者と制限事項が記載されています：短く、仮定は別に、結果に焦点を当てます。references/にはメトリクスと過去のレポートが含まれています。
- プレゼンテーションプラン。ブリーフには、プレゼンテーションが説明すべきことと含まれるべきではないことが記載されています。リクエストは遷移ロジックと各スライドのタスクを要求します。
- 投資前のプロジェクト分析。フォルダにはトークノミクス、チームメッセージ、他人の意見、および過去の分析が集まっています。リクエストは構造を指定します：本質、チーム活動、トークン配分、類似プロジェクトとの比較、赤旗。Coworkは収集した資料に基づき、パートナーシップを創造しません。資金についての決定はあなたに委ねられます。
リクエストをどのように定式化するか
最初に質問
Прочитай папку проекта.
Задай уточняющие вопросы до начала работы.このテクニックは、目標がはっきりしていない場合、具体的な対象者が結果を見るか、1つの誤った推測が全体の作業を無効にする場合に必要です。
短いリクエスト
Работай по папке проекта с учётом HOW-I-WORK и SYSTEM-RULES.
Черновик сохрани в outputs/.空のチャットでは、そのようなリクエストは失敗します。ここで機能するのは、コンテキストがすでにファイルにあるためです。したがって、簡単な兆候は：長いリクエストを書かなければならない場合、ファイルに何か不足しており、それをそこに追加する必要があります。
システムを拡張する方法
誤りは2つです：タスクがそれを超えたときに最小限にとどまるか、すぐにすべてのケースに対して数十のファイルを構築すること。繰り返しを見たときにファイルを追加し、将来のためではなく。
- system/ — Coworkが同じエラーを繰り返したり、ほぼすべての場合に適用されるルールが出現したとき。
- context/ — 対象者またはスタイルの説明が1つのファイルに収まらなくなったとき。
- projects/ — 標準的なタスクが恒久的なファイルのセットを構成したとき。
システムは正しく成長します。各タスクでより少ない説明、より少ない修正、より少ない再起動が必要になれば。これが起こらない場合は、誰も使用していないファイルを削除してください。