ドキュメント共同作成ワークフロー は何をしますか？
このスキルは、共同ドキュメント作成のための構造化ワークフローをユーザーにガイドします。アクティブなガイドとして、ユーザーを3つの段階（コンテキスト収集、洗練と構造化、読者テスト）に導きます。
このワークフローを提供するタイミング
トリガー条件:
- ユーザーが「ドキュメントを書く」「提案書を作成する」「仕様書を作成する」「書き起こし」など、ドキュメント作成について言及したとき
- ユーザーが特定のドキュメントタイプ（「PRD」「設計ドキュメント」「意思決定ドキュメント」「RFC」）について言及したとき
- ユーザーがかなりの量の文章作成タスクを開始しようとしているように見えるとき
最初の提案: ドキュメントを共同作成するための構造化ワークフローをユーザーに提案します。3つの段階を説明します:
- コンテキスト収集: Claudeが質問をしながら、ユーザーが関連するすべてのコンテキストを提供します
- 洗練と構造化: 各セクションをブレインストーミングと編集を通じて反復的に構築します
- 読者テスト: コンテキストのない新しいClaudeでドキュメントをテストし、他の人が読む前に盲点を特定します
このアプローチにより、他の人がドキュメントを読むとき（Claudeに貼り付けて読む場合も含む）に効果的に機能することを保証すると説明します。このワークフローを試すか、自由形式で作業したいかを尋ねます。
ユーザーが断った場合は自由形式で作業します。ユーザーが受け入れた場合は、段階1に進みます。
段階1: コンテキスト収集
目標: ユーザーが知っていることとClaudeが知っていることのギャップを埋め、後でスマートなガイダンスを可能にします。
最初の質問
まず、ドキュメントに関するメタコンテキストをユーザーに尋ねます:
- これはどのタイプのドキュメントですか？ (例: 技術仕様書、意思決定ドキュメント、提案書)
- 主な読者は誰ですか？
- 誰かがこれを読んだときに期待する影響は何ですか？
- 従うべきテンプレートや特定のフォーマットはありますか？
- 知っておくべきその他の制約やコンテキストはありますか？
ユーザーには、自分にとって最も効率的な方法で、短縮形で答えたり、情報をそのままダンプしたりできることを伝えます。
ユーザーがテンプレートを提供したり、ドキュメントタイプに言及した場合:
- 共有するテンプレートドキュメントがあるか尋ねます
- 共有ドキュメントへのリンクを提供された場合は、適切な統合機能を使用して取得します
- ファイルを提供された場合は、それを読み取ります
ユーザーが既存の共有ドキュメントの編集について言及した場合:
- 適切な統合機能を使用して現在の状態を読み取ります
- 代替テキストのない画像がないか確認します
- 代替テキストのない画像が存在する場合、他の人がClaudeを使用してドキュメントを理解する際にClaudeがそれらを認識できないことを説明します。代替テキストを生成するか尋ねます。生成する場合は、代替テキスト生成のために各画像をチャットに貼り付けるよう依頼します。
情報ダンプ
最初の質問に答えたら、ユーザーに持っているすべてのコンテキストをダンプするよう促します。以下のような情報を要求します:
- プロジェクト/問題の背景
- 関連するチームの議論や共有ドキュメント
- 代替ソリューションが使用されていない理由
- 組織のコンテキスト（チームの力学、過去のインシデント、政治的事情）
- スケジュールのプレッシャーや制約
- 技術アーキテクチャや依存関係
- ステークホルダーの懸念事項
整理することを心配する必要はなく、すべてをそのまま出すようにアドバイスします。コンテキストを提供する複数の方法を提供します:
- 意識の流れで情報ダンプ
- チームチャンネルやスレッドをポイントして読む
- 共有ドキュメントへのリンク
統合機能が利用可能な場合（例: Slack、Teams、Google Drive、SharePoint、その他のMCPサーバー）、これらを使用してコンテキストを直接取り込めることを伝えます。
統合機能が検出されず、claude.aiまたはClaudeアプリを使用している場合: Claude設定でコネクタを有効にすると、メッセージングアプリやドキュメントストレージからコンテキストを直接取得できることを提案します。
初期ダンプが完了したら、明確化のための質問をすることを伝えます。
コンテキスト収集中:
-
ユーザーがチームチャンネルや共有ドキュメントに言及した場合:
- 統合機能が利用可能な場合: コンテンツを今すぐ読み取ることを伝え、適切な統合機能を使用します
- 統合機能が利用できない場合: アクセスできないことを説明します。Claude設定でコネクタを有効にするか、関連コンテンツを直接貼り付けることを提案します。
-
ユーザーが不明なエンティティ/プロジェクトに言及した場合:
- 接続されたツールを検索して詳細を調べるか尋ねます
- ユーザーの確認を待ってから検索します
-
ユーザーがコンテキストを提供するにつれて、学習した内容とまだ不明な点を追跡します
明確化のための質問:
ユーザーが初期ダンプを完了したことを示したら（またはかなりのコンテキストが提供された後）、理解を確認するための質問をします:
コンテキストのギャップに基づいて、5〜10の番号付きの質問を生成します。
ユーザーには、短縮形で答えられることを伝えます（例: 「1: はい、2: #channelを参照、3: いいえ、後方互換性のため」）、より多くのドキュメントにリンクしたり、読むべきチャンネルを指摘したり、情報ダンプを続けたりすることもできます。自分にとって最も効率的な方法を選ぶよう促します。
終了条件: 基本的な説明を必要とせずにエッジケースやトレードオフについて質問できるようになったとき、十分なコンテキストが収集されたと見なします。
移行: この段階で提供したいコンテキストがまだあるか、ドキュメントの作成に進む準備ができているかを尋ねます。
ユーザーがさらに追加したい場合は許可します。準備ができたら、段階2に進みます。
段階2: 洗練と構造化
目標: ブレインストーミング、キュレーション、反復的な洗練を通じて、ドキュメントをセクションごとに構築します。
ユーザーへの指示: ドキュメントはセクションごとに構築されることを説明します。各セクションについて:
- 含める内容について明確化の質問をします
- 5〜20の選択肢をブレインストーミングします
- ユーザーは何を保持/削除/統合するかを指示します
- セクションがドラフトされます
- 外科的な編集を通じて洗練されます
最も不明な点が多いセクション（通常はコアの決定/提案）から始め、残りを進めます。
セクションの順序:
ドキュメント構造が明確な場合: どのセクションから始めたいか尋ねます。
最も不明な点が多いセクションから始めることを提案します。意思決定ドキュメントの場合、通常はコアの提案です。仕様書の場合、通常は技術的アプローチです。サマリーセクションは最後に残すのが最適です。
ユーザーが必要なセクションを知らない場合: ドキュメントのタイプとテンプレートに基づいて、適切な3〜5のセクションを提案します。
この構造で機能するか、調整したいかを尋ねます。
構造が合意されたら:
すべてのセクションにプレースホルダーテキストを入れた初期ドキュメント構造を作成します。
アーティファクトへのアクセスが利用可能な場合（例: Claude Code）:
create_file を使用してアーティファクトを作成します。これにより、Claudeとユーザーの両方が作業するための足場が得られます。
すべてのセクションヘッダーと「[未作成]」や「[コンテンツここに]」などの短いプレースホルダーテキストを含むアーティファクトを作成します。
足場のリンクを提供し、各セクションを埋める時間であることを示します。
アーティファクトへのアクセスがない場合:
作業ディレクトリにマークダウンファイルを作成します。適切に名前を付けます（例: 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%以上が完了）、ドキュメント全体を再読し、以下をチェックする意図を通知します:
- セクション間の流れと一貫性
- 冗長性や矛盾
- 「スロップ」や一般的な埋め草のように感じられるもの
- すべての文に重みがあるかどうか
ドキュメント全体を読み、フィードバックを提供します。
すべてのセクションがドラフトされ洗練されたとき: すべてのセクションがドラフトされたことを通知します。ドキュメント全体をもう一度レビューする意図を示します。
全体的な一貫性、流れ、完全性をレビューします。
最終的な提案を提供します。
読者テストに進む準備ができているか、さらに洗練したい点があるかを尋ねます。
段階3: 読者テスト
目標: コンテキストのない新しいClaudeでドキュメントをテストし、読者にとって機能するかを確認します。
ユーザーへの指示: テストを実行して、ドキュメントが実際に読者にとって機能するかどうかを確認することを説明します。これにより、盲点（作成者には意味が通じるが、他の人を混乱させる可能性のあるもの）を特定します。
テストアプローチ
サブエージェントへのアクセスが利用可能な場合（例: Claude Code）:
ユーザーの関与なしで直接テストを実行します。
ステップ1: 読者の質問を予測
読者がこのドキュメントを見つけようとしたときに尋ねる可能性のある質問を予測する意図を通知します。
読者が現実的に尋ねるであろう5〜10の質問を生成します。
ステップ2: サブエージェントでテスト
これらの質問を、コンテキストのない新しいClaudeインスタンスでテストすることを通知します。
各質問について、ドキュメントコンテンツと質問だけを含むサブエージェントを呼び出します。
各質問について、Reader Claudeが正しく答えた点と間違えた点を要約します。
ステップ3: 追加チェックを実行
追加のチェックを実行することを通知します。
サブエージェントを呼び出して、あいまいさ、誤った前提、矛盾をチェックします。
見つかった問題を要約します。
ステップ4: 報告と修正
問題が見つかった場合: Reader Claudeが特定の問題で苦戦したことを報告します。
具体的な問題をリストします。
これらのギャップを修正する意図を示します。
問題のあるセクションについては、洗練に戻ります。
サブエージェントへのアクセスがない場合（例: claude.ai Webインターフェース）:
ユーザーが手動でテストする必要があります。
ステップ1: 読者の質問を予測
人々がこのドキュメントを見つけようとしたときに尋ねる可能性のある質問を尋ねます。Claude.aiに何を入力するでしょうか？
読者が現実的に尋ねるであろう5〜10の質問を生成します。
ステップ2: テストのセットアップ
テスト手順を提供します:
- 新しいClaude会話を開く: https://claude.ai
- ドキュメントコンテンツを貼り付けるか共有する（共有ドキュメントプラットフォームでコネクタが有効になっている場合はリンクを提供する）
- 生成された質問をReader Claudeに尋ねる
各質問について、Reader Claudeに以下を提供するよう指示します:
- 回答
- あいまいまたは不明瞭だった点
- ドキュメントが既に知っていると想定している知識/コンテキスト
Reader Claudeが正しい回答をするか、何かを誤解するかを確認します。
ステップ3: 追加チェック
また、Reader Claudeに以下を尋ねます:
- 「このドキュメントの中で、読者にとってあいまいまたは不明瞭かもしれない点は何ですか？」
- 「このドキュメントはどのような知識やコンテキストを読者が既に持っていると想定していますか？」
- 「内部的な矛盾や不整合はありますか？」
ステップ4: 結果に基づいて反復
Reader Claudeが何を間違えたか、または苦戦したかを尋ねます。それらのギャップを修正する意図を示します。
問題のあるセクションについては、洗練に戻ります。
終了条件（両方のアプローチ）
Reader Claudeが一貫して質問に正しく答え、新しいギャップやあいまいさを表面化しなくなったとき、ドキュメントは準備完了です。
最終レビュー
読者テストに合格したとき: ドキュメントがReader Claudeテストに合格したことを通知します。完了前に:
- ユーザー自身で最終的な読み直しを行うことを推奨します - このドキュメントはユーザーが所有し、その品質に責任を持ちます
- 事実、リンク、技術的な詳細を再確認することを提案します
- ドキュメントが期待した影響を達成しているか確認するよう依頼します
質問します
...
[翻訳のために切り詰められました]