doc-coauthoring
ドキュメント共同執筆ワークフロー
このスキルは、コラボレイティブなドキュメント作成をガイドするための構造化ワークフローを提供します。アクティブなガイドとして、ユーザーを3つのステージ（コンテキスト収集、洗練と構造化、読者テスト）に導きます。
このワークフローを提案するタイミング
トリガー条件：
- ユーザーがドキュメント作成に言及：「ドキュメントを書く」「提案書を作成」「仕様書を書く」「まとめる」
- ユーザーが特定のドキュメントタイプに言及：「PRD」「設計ドキュメント」「決定文書」「RFC」
- ユーザーが実質的なライティングタスクを開始しようとしている
最初の提案： ドキュメント共同執筆のための構造化ワークフローを提案。3つのステージを説明：
- コンテキスト収集：Claudeが明確化の質問をしながら、ユーザーが関連するすべてのコンテキストを提供
- 洗練と構造化：ブレインストーミングと編集を通じて各セクションを反復的に構築
- 読者テスト：他の人が読む前に盲点を発見するため、新鮮なClaude（コンテキストなし）でドキュメントをテスト
このアプローチが、他の人が読むとき（Claudeに貼り付けるときを含む）にドキュメントがうまく機能することを保証するのに役立つことを説明。このワークフローを試すか、フリーフォームで作業するかを尋ねる。
ユーザーが辞退した場合はフリーフォームで作業。承諾した場合はステージ1に進む。
ステージ1：コンテキスト収集
目標： ユーザーが知っていることとClaudeが知っていることのギャップを埋め、後でスマートなガイダンスを可能にする。
最初の質問
まず、ドキュメントに関するメタコンテキストをユーザーに尋ねる：
- これはどのタイプのドキュメントですか？（例：技術仕様書、決定文書、提案書）
- 主な対象読者は誰ですか？
- 誰かがこれを読んだときの望ましいインパクトは何ですか？
- 従うべきテンプレートや特定のフォーマットはありますか？
- 知っておくべき他の制約やコンテキストはありますか？
省略形で回答したり、自分に合った方法で情報をダンプしたりできることを伝える。
ユーザーがテンプレートを提供するか、ドキュメントタイプに言及した場合：
- 共有するテンプレートドキュメントがあるか尋ねる
- 共有ドキュメントへのリンクを提供した場合は、適切なインテグレーションを使用してフェッチ
- ファイルを提供した場合は読み込む
ユーザーが既存の共有ドキュメントの編集に言及した場合：
- 適切なインテグレーションを使用して現在の状態を読み込む
- alt-textのない画像をチェック
- alt-textのない画像が存在する場合、他の人がClaudeを使用してドキュメントを理解しようとするとき、Claudeはそれらを見ることができないことを説明。alt-textの生成を希望するか尋ねる。希望する場合は、説明的なalt-text生成のために各画像をチャットに貼り付けるよう依頼。
情報のダンプ
最初の質問に回答したら、ユーザーが持っているすべてのコンテキストをダンプするよう促す。以下のような情報を要求：
- プロジェクト/問題の背景
- 関連するチームの議論や共有ドキュメント
- 代替ソリューションが使用されていない理由
- 組織のコンテキスト（チームダイナミクス、過去のインシデント、政治）
- タイムラインのプレッシャーや制約
- 技術的アーキテクチャや依存関係
- ステークホルダーの懸念
整理することを心配する必要はない - すべて出すようにアドバイス。コンテキストを提供する複数の方法を提案：
- 思考の流れのままに情報をダンプ
- 読むべきチームチャンネルやスレッドを指定
- 共有ドキュメントへのリンク
インテグレーションが利用可能な場合（例：Slack、Teams、Google Drive、SharePoint、その他のMCPサーバー）、これらを使用してコンテキストを直接取り込めることに言及。
インテグレーションが検出されず、Claude.aiまたはClaudeアプリの場合： Claude設定でコネクターを有効にして、メッセージングアプリやドキュメントストレージから直接コンテキストを取り込めるようにすることを提案。
最初のダンプが終わったら明確化の質問をすることを伝える。
コンテキスト収集中：
-
ユーザーがチームチャンネルや共有ドキュメントに言及した場合：
- インテグレーションが利用可能な場合：今からコンテンツを読むことを伝え、適切なインテグレーションを使用
- インテグレーションが利用できない場合：アクセスできないことを説明。Claude設定でコネクターを有効にするか、関連するコンテンツを直接貼り付けることを提案。
-
ユーザーが不明なエンティティ/プロジェクトに言及した場合：
- 接続されたツールを検索して詳細を学ぶべきか尋ねる
- 検索する前にユーザーの確認を待つ
-
ユーザーがコンテキストを提供するにつれて、学んだことと不明な点を追跡
明確化の質問：
ユーザーが最初のダンプを完了したことを示す（または十分なコンテキストが提供された後）、理解を確認するために明確化の質問をする：
コンテキストのギャップに基づいて5〜10個の番号付き質問を生成。
省略形で回答できること（例：「1: はい、2: #channelを参照、3: 後方互換性のためno」）、さらにドキュメントへのリンク、読むべきチャンネルの指定、または情報のダンプを続けることができることを伝える。最も効率的な方法で。
終了条件： 質問が理解を示すとき - 基本的なことを説明してもらわなくても、エッジケースやトレードオフについて質問できるとき - 十分なコンテキストが収集された。
移行： この段階で提供したい追加のコンテキストがあるか、ドキュメントの起草に移る準備ができているかを尋ねる。
ユーザーがさらに追加したい場合は許可。準備ができたらステージ2に進む。
ステージ2：洗練と構造化
目標： ブレインストーミング、キュレーション、反復的な洗練を通じてセクションごとにドキュメントを構築。
ユーザーへの説明： ドキュメントをセクションごとに構築することを説明。各セクションについて：
- 含めるべき内容について明確化の質問をする
- 5〜20のオプションをブレインストーミング
- ユーザーが保持/削除/組み合わせを指示
- セクションを起草
- 外科的な編集で洗練
最も不明な点が多いセクション（通常は核心の決定/提案）から始め、残りを進める。
セクションの順序：
ドキュメント構造が明確な場合： どのセクションから始めたいか尋ねる。
最も不明な点が多いセクションから始めることを提案。決定文書の場合、通常は核心の提案。仕様書の場合、通常は技術的アプローチ。サマリーセクションは最後にするのが最善。
ユーザーが必要なセクションがわからない場合： ドキュメントタイプとテンプレートに基づいて、適切な3〜5つのセクションを提案。
この構造で問題ないか、調整したいか尋ねる。
構造が合意されたら：
すべてのセクションのプレースホルダーテキストで初期ドキュメント構造を作成。
アーティファクトへのアクセスがある場合：
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テストに合格したことを発表。完了前に：
- 自分で最終読み通しをすることを推奨 - このドキュメントの所有者であり、その品質に責任がある
- 事実、リンク、または技術的詳細を再確認することを提案
- 望んだインパクトを達成しているか確認するよう依頼
もう一度レビューしたいか、作業が完了したかを尋ねる。
ユーザーが最終レビューを望む場合は提供。そうでなければ： ドキュメント完了を発表。いくつかの最終的なヒントを提供：
- 読者がドキュメントがどのように開発されたかを見られるように、この会話を付録にリンクすることを検討
- メインドキュメントを膨らませることなく深さを提供するために付録を使用
- 実際の読者からフィードバックを受けたらドキュメントを更新
効果的なガイダンスのヒント
トーン：
- 直接的で手続き的に
- ユーザーの行動に影響する場合は簡潔に理由を説明
- アプローチを「売り込もう」としない - ただ実行
逸脱の処理：
- ユーザーがステージをスキップしたい場合：これをスキップしてフリーフォームで書きたいか尋ねる
- ユーザーがフラストレーションを感じているようなら：予想より時間がかかっていることを認める。より速く進む方法を提案
- 常にユーザーにプロセスを調整する権限を与える
コンテキスト管理：
- 全体を通じて、言及されたことにコンテキストが欠けている場合は積極的に尋ねる
- ギャップを蓄積させない - 発生したら対処
アーティファクト管理：
- 完全なセクションの起草には
create_fileを使用 - すべての編集には
str_replaceを使用 - 変更のたびにアーティファクトリンクを提供
- ブレインストーミングリストにはアーティファクトを使用しない - それは会話の一部
スピードより品質：
- ステージを急がない
- 各イテレーションで意味のある改善を行う
- 目標は読者にとって実際に機能するドキュメント