ドキュメント共同作成ワークフロー
このスキルは、ユーザーが協力してドキュメントを作成するための構造化ワークフローを提供します。積極的なガイドとして機能し、ユーザーを次の3つの段階に導きます：コンテキスト収集、洗練と構造化、読者テスト。
このワークフローを提供するタイミング
トリガー条件:
- ユーザーがドキュメント作成に言及する：「ドキュメントを書く」、「提案書を作成する」、「仕様書を作成する」、「書き起こす」
- ユーザーが特定のドキュメントタイプに言及する：「PRD」、「設計ドキュメント」、「意思決定ドキュメント」、「RFC」
- ユーザーがかなりの量のライティングタスクを始めているように見える
最初の提案: ドキュメントを共同作成するための構造化ワークフローをユーザーに提案します。3つの段階を説明します：
- コンテキスト収集: ユーザーが関連するすべてのコンテキストを提供し、Claudeが明確化のための質問をする
- 洗練と構造化: ブレインストーミングと編集を通じて各セクションを反復的に構築する
- 読者テスト: 新しいClaude（コンテキストなし）でドキュメントをテストし、他の人が読む前の盲点を発見する
このアプローチにより、他の人（Claudeに貼り付けた場合も含む）がドキュメントを読んだときにうまく機能することを保証すると説明します。このワークフローを試すか、自由形式で作業するかを尋ねます。
ユーザーが拒否した場合は自由形式で作業します。ユーザーが承諾した場合は、段階1に進みます。
段階1: コンテキスト収集
目標: ユーザーが知っていることとClaudeが知っていることのギャップを埋め、後でスマートなガイダンスを可能にします。
最初の質問
まず、ドキュメントに関するメタコンテキストをユーザーに尋ねます：
- このドキュメントはどのようなタイプですか？（例：技術仕様書、意思決定ドキュメント、提案書）
- 主な読者は誰ですか？
- 誰かがこれを読んだときに期待する影響は何ですか？
- 従うべきテンプレートや特定のフォーマットはありますか？
- 知っておくべき他の制約やコンテキストはありますか？
簡略表記で答えたり、自分に最適な方法で情報をダンプしたりできることを伝えます。
ユーザーがテンプレートを提供したり、ドキュメントタイプに言及した場合:
- 共有できるテンプレートドキュメントがあるか尋ねる
- 共有ドキュメントへのリンクを提供する場合は、適切な統合を使用して取得する
- ファイルを提供する場合は、それを読み取る
ユーザーが既存の共有ドキュメントの編集に言及した場合:
- 適切な統合を使用して現在の状態を読み取る
- 代替テキスト（alt-text）のない画像がないか確認する
- 代替テキストなしの画像が存在する場合、他の人が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のセクションを提案します。
この構造で動作するか、調整したいかを尋ねます。
構造が合意されたら:
すべてのセクションのプレースホルダーテキストを含む初期ドキュメント構造を作成します。
アーティファクトにアクセスできる場合:
create_fileを使用してアーティファクトを作成します。これにより、Claudeとユーザーの両方が作業するための足場が得られます。
すべてのセクションのプレースホルダーを含む初期構造が作成されることを伝えます。
すべてのセクションヘッダーと「[後で記入]」や「[ここにコンテンツ]」などの簡単なプレースホルダーテキストを含むアーティファクトを作成します。
足場リンクを提供し、各セクションを埋める時が来たことを示します。
アーティファクトにアクセスできない場合:
作業ディレクトリにマークダウンファイルを作成します。適切に名前を付けます（例：decision-doc.md、technical-spec.md）。
すべてのセクションのプレースホルダーを含む初期構造が作成されることを伝えます。
すべてのセクションヘッダーとプレースホルダーテキストを含むファイルを作成します。
ファイル名が作成されたことを確認し、各セクションを埋める時が来たことを示します。
各セクションについて:
ステップ1: 明確化の質問
[SECTION NAME] セクションの作業を開始することを宣言します。含めるべきものについて5〜10の明確化の質問をします：
コンテキストとセクションの目的に基づいて、5〜10の具体的な質問を生成します。
簡略表記で答えるか、カバーすべき重要なことを示すだけでよいことを伝えます。
ステップ2: ブレインストーミング
[SECTION NAME] セクションについて、セクションの複雑さに応じて5〜20の含める可能性のある項目をブレインストーミングします。次のものを探します：
- 忘れられているかもしれない共有コンテキスト
- まだ言及されていない角度や考慮事項
セクションの複雑さに基づいて5〜20の番号付きオプションを生成します。最後に、さらにオプションが必要な場合、さらにブレインストーミングすることを提案します。
ステップ3: キュレーション
どのポイントを保持、削除、または統合するかを尋ねます。次のセクションの優先順位を学ぶために、簡単な理由を要求します。
例を提供します：
- 「1,4,7,9を保持」
- 「3を削除（1と重複）」
- 「6を削除（読者はこれを既に知っている）」
- 「11と12を統合」
ユーザーが自由形式のフィードバックを与えた場合（例：「良さそう」や「ほとんど気に入ったけど...」）、数値選択の代わりに、その好みを抽出して進めます。保持/削除/変更したいものを解析して適用します。
ステップ4: ギャップチェック
選択した内容に基づいて、[SECTION NAME] セクションに欠けている重要なものがないか尋ねます。
ステップ5: ドラフト作成
str_replaceを使用して、このセクションのプレースホルダーテキストを実際のドラフトコンテンツに置き換えます。
選択内容に基づいて、[SECTION NAME] セクションがドラフトされることを宣言します。
アーティファクトを使用する場合: ドラフト後、アーティファクトへのリンクを提供します。
ユーザーにそれを読んで、変更したい箇所を示すよう依頼します。具体的であることで、次のセクションでの学習に役立つことに注意してください。
ファイルを使用する場合（アーティファクトなし）: ドラフト後、完了を確認します。
[SECTION NAME] セクションが [filename] にドラフトされたことを伝えます。ユーザーにそれを読んで、変更したい箇所を示すよう依頼します。具体的であることで、次のセクションでの学習に役立つことに注意してください。
ユーザーへの重要な指示（最初のセクションをドラフトするときに含める）: ドキュメントを直接編集する代わりに、変更したい箇所を示すよう依頼するメモを提供します。これにより、将来のセクションでのスタイル学習に役立ちます。例：「Xの箇条書きを削除 - Yですでにカバーされている」または「3番目の段落をもっと簡潔に」。
ステップ6: 反復的な洗練
ユーザーがフィードバックを提供するにつれて：
str_replaceを使用して編集を行います（ドキュメント全体を再印刷しない）- アーティファクトを使用する場合: 編集後ごとにアーティファクトへのリンクを提供する
- ファイルを使用する場合: 編集が完了したことを確認するだけ
- ユーザーがドキュメントを直接編集して読み取りを依頼した場合：彼らが行った変更を頭の中でメモし、将来のセクションで考慮に入れる（これにより彼らの好みが示される）
ユーザーがセクションに満足するまで繰り返します。
品質チェック
実質的な変更なしで3回連続の反復の後、重要な情報を失わずに削除できるものがあるか尋ねます。
セクションが完了したら、[SECTION NAME] が完了したことを確認します。次のセクションに進む準備ができているか尋ねます。
すべてのセクションについて繰り返します。
完了近く
完了に近づいたら（セクションの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テストに合格したことを宣言します。完了前に：
- ユーザー自身で最終的な読み直しをすることを推奨する - 彼らがこのドキュメントの所有者であり、品質に責任を持つ
- 事実、リンク、技術的な詳細を再確認することを提案する
- 望んだ影響を達成していることを確認するよう依頼する
完了の確認を求めます。
ドキュメントが完成したことを祝福します。