ドキュメントの共同編集

出典: anthropics/skills (MIT) を基にしたコンテンツ。

このスキルは、共同でドキュメントを作成する際にユーザーをガイドするための構造化されたワークフローを提供します。アクティブなガイドとして機能し、コンテキスト収集、洗練と構造、読者テストの 3 つの段階をユーザーに案内します。

このワークフローをいつ提供するか

トリガー条件:

• ユーザーがドキュメントの作成について言及しています:「ドキュメントを書く」、「提案書を下書きする」、「仕様を作成する」、「書き上げる」
• ユーザーが特定のドキュメントの種類について言及しています:「PRD」、「設計ドキュメント」、「決定ドキュメント」、「RFC」
• ユーザーは実質的な執筆作業を開始しているようです

初回特典: ドキュメントを共同編集するための構造化されたワークフローをユーザーに提供します。 3 つの段階について説明します。

1. コンテキスト収集: ユーザーは関連するすべてのコンテキストを提供し、クロードは明確な質問をします。
2. 改良と構造: ブレーンストーミングと編集を通じて各セクションを繰り返し構築します
3. 読者テスト: 他の人が読む前にドキュメントを新しいクロード (文脈なし) でテストして盲点を見つけます。

このアプローチにより、他の人がドキュメントを読んだとき (Claude に貼り付けたときも含めて) ドキュメントが適切に機能することが保証されることを説明します。このワークフローを試してみたいか、それともフリーフォームで作業することを希望するかを尋ねます。

ユーザーが拒否した場合は、自由形式で作業します。ユーザーが同意した場合は、ステージ 1 に進みます。

ステージ 1: コンテキストの収集

目標: ユーザーが知っていることとクロードが知っていることの間のギャップを埋め、後でスマートなガイダンスを可能にします。

最初の質問

まず、ユーザーにドキュメントに関するメタコンテキストを尋ねます。

1. これはどのような種類の文書ですか? (例: 技術仕様、決定文書、提案)
2. 主な視聴者は誰ですか?
3. 誰かがこれを読んだときに望ましい影響は何ですか?
4. 従うべきテンプレートや特定の形式はありますか?
5. 他に知っておくべき制約やコンテキストはありますか?

速記で答えることも、情報をダンプすることもできるが、それが彼らにとって最適であることを伝えます。

ユーザーがテンプレートを提供するか、ドキュメントの種類に言及する場合:

• 共有するテンプレート ドキュメントがあるかどうかを尋ねる
• 共有ドキュメントへのリンクが提供されている場合は、適切な統合を使用してそれを取得します
• ファイルが提供されている場合は、それを読みます

ユーザーが既存の共有ドキュメントの編集について言及した場合:

• 適切な統合を使用して現在の状態を読み取ります
• 代替テキストのない画像を確認する
• 画像が代替テキストなしで存在する場合は、他の人がドキュメントを理解するためにクロードを使用すると、クロードは画像を見ることができないことを説明します。代替テキストを生成するかどうかを尋ねます。その場合は、説明的な代替テキストを生成するために各画像をチャットに貼り付けるように依頼してください。

情報ダンプ

最初の質問に答えたら、ユーザーに手持ちのコンテキストをすべて吐き出すよう促します。次のような情報を要求します。

• プロジェクト/問題の背景
• 関連するチームのディスカッションまたは共有ドキュメント
• 代替ソリューションが使用されない理由
• 組織の背景 (チームの力学、過去の出来事、政治)
• スケジュール上のプレッシャーや制約
• 技術的なアーキテクチャまたは依存関係
• 利害関係者の懸念

整理することについて心配する必要はなく、すべてを取り出してくださいとアドバイスします。コンテキストを提供する複数の方法を提供します。

• 情報ダンプの意識の流れ
• 読むチーム チャネルまたはスレッドをポイントします
• 共有ドキュメントへのリンク

統合が利用可能な場合 (Slack、Teams、Google Drive、SharePoint、またはその他の MCP サーバーなど)、これらを使用してコンテキストを直接取り込めることについて言及します。

Claude.ai または Claude アプリで統合が検出されない場合: Claude 設定でコネクタを有効にして、メッセージング アプリやドキュメント ストレージからコンテキストを直接取得できるようにすることを提案します。

最初のダンプが完了したら質問が行われることを明確に伝えます。

コンテキスト収集中:

• ユーザーがチーム チャネルまたは共有ドキュメントに言及した場合:

  • 統合が利用可能な場合: コンテンツが今読み取られることを伝え、適切な統合を使用します。
  • 統合が利用できない場合: アクセスがないことを説明します。クロード設定でコネクタを有効にするか、関連するコンテンツを直接貼り付けることを提案してください。

• ユーザーが不明なエンティティ/プロジェクトについて言及した場合:

  • 詳細を確認するには、接続されているツールを検索する必要があるかどうかを尋ねます
  • 検索する前にユーザーの確認を待ちます

• ユーザーがコンテキストを提供すると、何が学習され、何がまだ不明であるかを追跡します

明確な質問をする:

ユーザーが最初のダンプを完了したことを示したら (または十分なコンテキストが提供された後)、理解を確実にするために明確な質問をします。

文脈のギャップに基づいて、5 ～ 10 個の番号付きの質問を生成します。

短縮表現を使って答えたり (例: 「1: はい、2: #channel を参照、3: 下位互換のためいいえ」)、他のドキュメントにリンクしたり、読むチャンネルを指定したり、単に情報をダンプし続けたりできることを伝えます。彼らにとって最も効率的なものなら何でも。

終了条件: 質問が理解を示す場合、つまり基本的な説明を必要とせずにエッジケースやトレードオフについて質問できる場合には、十分なコンテキストが収集されています。

移行: この段階でさらに提供したいコンテキストがあるかどうか、または文書の草案に進む時期が来たかどうかを尋ねます。

ユーザーがさらに追加したい場合は、そのままにしてください。準備ができたら、ステージ 2 に進みます。

ステージ 2: 改良と構造化

目標: ブレーンストーミング、キュレーション、反復的な改良を通じて、ドキュメントをセクションごとに構築します。

ユーザーへの指示: ドキュメントはセクションごとに構築されることを説明します。各セクションについて:

1. 何を含めるかについて明確な質問が行われます
2. 5 ～ 20 の選択肢がブレインストーミングされます
3. ユーザーは何を保持/削除/結合するかを指示します
4. このセクションは草案になります
5. 外科的編集を通じて洗練されます

最も不明な点が多いセクション (通常は中核となる決定/提案) から始めて、残りの部分に取り組みます。

セクションの順序:

文書の構造が明確な場合: どのセクションから始めたいかを尋ねます。

不明な点が最も多いセクションから始めることを提案します。意思決定文書の場合、通常、これが中心となる提案になります。スペックについては、通常は技術的なアプローチです。概要セクションは最後に残しておくのが最善です。

ユーザーがどのセクションが必要かわからない場合: ドキュメントとテンプレートのタイプに基づいて、ドキュメントの種類に適した 3 ～ 5 つのセクションを提案します。

この構造が機能するかどうか、または調整したいかどうかを尋ねます。

構造が合意されたら:

すべてのセクションにプレースホルダー テキストを含む初期ドキュメント構造を作成します。

アーティファクトにアクセスできる場合: create_fileを使用してアーティファクトを作成します。これにより、クロードとユーザーの両方に作業の足場が与えられます。

すべてのセクションのプレースホルダーを含む初期構造が作成されることを伝えます。

すべてのセクションのヘッダーと、「[To be write]」や「[Content here]」などの短いプレースホルダー テキストを含む成果物を作成します。

スキャフォールド リンクを提供し、各セクションに入力する時期であることを示します。

アーティファクトにアクセスできない場合: 作業ディレクトリにマークダウン ファイルを作成します。適切な名前を付けます (例:decision-doc.md、technical-spec.md)。

すべてのセクションのプレースホルダーを含む初期構造が作成されることを伝えます。

すべてのセクション ヘッダーとプレースホルダー テキストを含むファイルを作成します。

ファイル名が作成されたことを確認し、各セクションに入力することを示します。

各セクションについて:

ステップ 1: 質問を明確にする

[セクション名] セクションで作業が開始されることを発表します。何を含めるべきかについて、5 ～ 10 個の明確な質問をします。

コンテキストとセクションの目的に基づいて、5 ～ 10 個の具体的な質問を生成します。

速記で答えることもできるし、重要な点だけを説明することもできることを伝えます。

ステップ 2: ブレーンストーミング

[セクション名] セクションについては、セクションの複雑さに応じて、含まれる可能性のある内容をブレインストーミング [5 ～ 20] します。探してください:

• 忘れられていたかもしれない共有コンテキスト
• まだ言及されていない角度や考慮事項

セクションの複雑さに基づいて、5 ～ 20 個の番号付きオプションを生成します。最後に、追加のオプションが必要な場合は、さらにブレインストーミングを行うことを提案します。

ステップ 3: キュレーション

どのポイントを維持するか、削除するか、または統合する必要があるかを尋ねます。次のセクションの優先順位を理解するために、簡単な理由を要求します。

例を示します。

• 「1、4、7、9をキープ」
• 「3 を削除 (1 は重複)」
• 「6 を削除します (視聴者はすでにこれを知っています)」
• 「11と12を組み合わせる」

ユーザーが番号付きの選択ではなく、自由形式のフィードバック (例: 「見た目は良い」または「ほとんどが気に入っていますが...」) を提供する場合は、ユーザーの好みを抽出して続行します。保持/削除/変更したいものを解析して適用します。

ステップ 4: ギャップチェック

選択した内容に基づいて、[セクション名] セクションに不足している重要な点がないか尋ねます。

ステップ 5: 製図

str_replaceを使用して、このセクションのプレースホルダー テキストを実際の下書きコンテンツに置き換えます。

選択した内容に基づいて、[セクション名] セクションの下書きが作成されることを発表します。

アーティファクトを使用する場合: ドラフト後、アーティファクトへのリンクを提供します。

それを最後まで読んで、何を変更する必要があるかを指示してもらいます。具体的にすることは、次のセクションの学習に役立つことに注意してください。

ファイルを使用する場合 (アーティファクトなし): 製図後、完成を確認します。

[セクション名] セクションが [ファイル名] で作成されたことを伝えます。それを最後まで読んで、何を変更する必要があるかを指示してもらいます。具体的にすることは、次のセクションの学習に役立つことに注意してください。

ユーザーへの重要な指示 (最初のセクションの草稿を含む): 注記を提供します: ドキュメントを直接編集する代わりに、何を変更するかを指示するよう依頼します。これは、今後のセクションでのスタイルを学ぶのに役立ちます。例: 「X の箇条書きを削除 - 既に Y でカバーされている」または「3 番目の段落をより簡潔に」。

ステップ 6: 反復的な改良

ユーザーがフィードバックを提供すると、次のようになります。

• 編集にはstr_replaceを使用してください (ドキュメント全体を再印刷しないでください)
• アーティファクトを使用する場合: 各編集後にアーティファクトへのリンクを提供します
• ファイルを使用している場合: 編集が完了していることを確認してください
• ユーザーがドキュメントを直接編集し、それを読むように要求した場合: 行った変更を心の中でメモし、今後のセクションで使用するために覚えておいてください (これはユーザーの好みを示します)

ユーザーがセクションに満足するまで繰り返しを続けます。

品質検査

実質的な変更がなかった 3 回の繰り返しの後、重要な情報を失わずに何かを削除できるかどうかを尋ねます。

セクションが完了したら、[セクション名] が完了していることを確認します。次のセクションに進む準備ができているかどうかを尋ねます。

すべてのセクションに対して繰り返します。

完成間近

完了が近づいたら (セクションの 80% 以上が完了)、文書全体を再読して以下の点を確認する意向を表明します。

• セクション全体の流れと一貫性
• 冗長性または矛盾
• 「スロップ」または一般的なフィラーのように感じるもの
• 一つ一つの文に重みがあるかどうか

ドキュメント全体を読んでフィードバックを提供してください。

すべてのセクションの下書きと洗練が完了すると: すべてのセクションが草案であることを発表します。完全な文書をもう一度確認する意向を示します。

全体的な一貫性、流れ、完全性をレビューします。

最終的な提案があれば提供します。

Reader Testing に移行する準備ができているか、または他に改善したい点があるかどうかを尋ねます。

ステージ 3: リーダーのテスト

目標: 新しいクロード (文脈を流さない) でドキュメントをテストし、読者にとって機能することを確認します。

ユーザーへの指示: これからドキュメントが読者にとって実際に機能するかどうかを確認するためのテストが行われることを説明します。これは盲点、つまり作成者にとっては理解できるものの、他の人を混乱させる可能性のあるものを捕らえます。

テストのアプローチ

サブエージェントへのアクセスが利用可能な場合 (クロード コードなど):

ユーザーの関与なしで直接テストを実行します。

ステップ 1: 読者の質問を予測する

読者がこの文書を見つけようとするときにどのような質問をするかを予測する意図を発表します。

読者が現実的に尋ねるであろう質問を 5 ～ 10 個作成します。

ステップ 2: サブエージェントでテストする

これらの質問が新しいクロード インスタンスでテストされることを発表します (この会話のコンテキストはありません)。

質問ごとに、ドキュメントのコンテンツと質問だけを指定してサブエージェントを呼び出します。

読者クロードが各質問について正解/不正解をまとめます。

ステップ 3: 追加のチェックを実行する

追加のチェックが実行されることを発表します。

サブエージェントを呼び出して、曖昧さ、誤った仮定、矛盾をチェックします。

見つかった問題を要約します。

ステップ 4: 報告と修正

問題が見つかった場合: Reader Claude が特定の問題に悩んでいることを報告します。

具体的な問題を列挙します。

これらのギャップを修正する意向を示します。

問題のあるセクションの改良にループバックします。

---

サブエージェントにアクセスできない場合 (claude.ai Web インターフェイスなど):

ユーザーは手動でテストを行う必要があります。

ステップ 1: 読者の質問を予測する

この文書を見つけようとするときに人々がどのような質問をする可能性があるかを尋ねてください。彼らは Claude.ai に何を入力するでしょうか?

読者が現実的に尋ねるであろう質問を 5 ～ 10 個作成します。

ステップ 2: セットアップのテスト

テスト手順を提供します。

1. 新しいクロードの会話を開始します: https://claude.ai
2. ドキュメントのコンテンツを貼り付けるか共有します (コネクタが有効になっている共有ドキュメント プラットフォームを使用している場合は、リンクを提供します)
3. 生成された質問を Reader Claude に質問します

各質問について、Reader Claude に次の情報を提供するように指示します。

• 答えは
• 曖昧な点や不明瞭な点はないか
• ドキュメントがすでに知られていると想定している知識/コンテキスト

リーダーのクロードが正しい答えを出しているか、何か誤解をしていないかを確認してください。

ステップ 3: 追加のチェック

読者クロードにも尋ねてください:

• 「このドキュメントの中で、読者にとって曖昧または不明瞭になる可能性のあるものは何ですか?」
• 「このドキュメントでは、読者がすでにどのような知識や背景を持っていることを想定していますか?」
• 内部に矛盾や不一致はありませんか？

ステップ 4: 結果に基づいて反復する

読者のクロードが何を間違えたのか、あるいは何に苦労したかを尋ねてください。それらのギャップを修正する意図を示します。

問題のあるセクションの調整にループバックします。

---

終了条件 (両方のアプローチ)

Reader Claude が常に質問に正しく回答し、新たなギャップや曖昧な点が表面化しなければ、ドキュメントの準備は完了です。

最終レビュー

リーダーテストに合格すると: ドキュメントが Reader Claude テストに合格したことを発表します。完了前:

1. 自分自身で最終的な読み合わせを行うことを推奨します - 彼らはこの文書を所有しており、その品質に責任があります
2. 事実、リンク、技術的な詳細を再確認することを提案します。
3. 望んでいた効果が得られるかどうかを確認してもらいます

もう一度レビューしてほしいか、それとも作業は完了したかを尋ねます。

** ユーザーが最終レビューを希望する場合は、それを提供してください。それ以外の場合:** 書類の完成を発表します。最後にいくつかのヒントを提供します。

• 読者がドキュメントがどのように作成されたかを確認できるように、この会話を付録にリンクすることを検討してください。
• 付録を使用して、メインのドキュメントを肥大化させずに深みを与えます
• 実際の読者からフィードバックを受け取ったらドキュメントを更新します

効果的な指導のためのヒント

トーン:

• 直接的かつ手続き的であること
• ユーザーの行動に影響を与える場合、その根拠を簡単に説明する
• アプローチを「販売」しようとせず、ただ実行するだけです

逸脱の処理:

• ユーザーがステージをスキップしたい場合: これをスキップして自由形式で書きたいかどうかを尋ねます
• ユーザーがイライラしているように見える場合: 予想よりも時間がかかっていることを認めます。より速く移動する方法を提案する
• 常にユーザーにプロセスを調整する権限を与える

コンテキスト管理:

• 全体を通して、言及された内容に文脈が欠けている場合は、積極的に質問してください
• ギャップを蓄積させないでください - ギャップが生じたときに対処します

アーティファクト管理:

• 完全なセクションのドラフトにはcreate_fileを使用してください
• すべての編集にはstr_replaceを使用してください
• 変更のたびにアーティファクト リンクを提供する
• リストのブレーンストーミングにはアーティファクトを決して使用しないでください - それは単なる会話です

スピードよりも品質:

• ステージを急いで通過しないでください
• 各反復では有意義な改善が行われるはずです
• 目標は、読者にとって実際に役立つドキュメントです

GitHub で見る

GitHub で見る