ドキュメント共著ワークフロー

このスキルは、ユーザーを協調的なドキュメント作成に導くための構造化されたワークフローを提供します。3つのステージ(コンテキスト収集、改善と構成、リーダーテスト)を通じてユーザーを主体的にガイドします。

このワークフローを提案するタイミング

トリガー条件:

• ユーザーがドキュメント作成に言及している: 「ドキュメントを書く」「提案書を作成する」「仕様書を作る」「書き起こす」など
• ユーザーが特定のドキュメントタイプに言及している: 「PRD」「デザインドキュメント」「決定ドキュメント」「RFC」など
• ユーザーが実質的な執筆作業を開始しようとしている

初期提案: ドキュメント共著のための構造化されたワークフローをユーザーに提案します。3つのステージを説明します:

1. コンテキスト収集: ユーザーがすべての関連コンテキストを提供し、Claudeが明確化の質問を行う
2. 改善と構成: ブレーンストーミングと編集を通じて各セクションを反復的に構築する
3. リーダーテスト: 他の人が読む前に、新しいClaude(コンテキストなし)でドキュメントをテストして盲点をキャッチする

このアプローチにより、他の人がドキュメントを読むときに(Claudeに貼り付けたときを含む)ドキュメントが効果的に機能することが保証されることを説明します。このワークフローを試したいのか、それともフリースタイルで進めたいのかを聞きます。

ユーザーが拒否した場合、フリースタイルで作業します。ユーザーが同意した場合、ステージ1に進みます。

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

目標: ユーザーが知っていることとClaudeが知っていることのギャップを埋め、後の段階で適切なガイダンスを可能にします。

初期質問

ドキュメントに関するメタコンテキストをユーザーに質問することから始めます:

1. このドキュメントはどの種類ですか？(例: 技術仕様書、決定ドキュメント、提案書)
2. 主な対象読者は誰ですか？
3. 誰かがこれを読むときの期待される影響は何ですか？
4. 従うべきテンプレートや特定の形式がありますか？
5. 他に知っておくべき制約やコンテキストはありますか？

ユーザーが簡潔に答えたり、最適な方法で情報をダンプできることを伝えます。

テンプレートやドキュメントタイプについてユーザーが言及した場合:

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

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

• 適切な統合を使用して現在の状態を読む
• 代替テキストのない画像をチェックする
• 代替テキストのない画像がある場合、他の人がClaudeを使用してドキュメントを理解しようとするときにClaudeがそれを見ることができないことを説明します。代替テキストを生成したいかどうかを聞きます。その場合、説明的な代替テキスト生成のために各画像をチャットに貼り付けるようにリクエストします。

情報ダンプ

初期質問に答えた後、ユーザーが持つすべてのコンテキストをダンプすることを促します。以下のような情報をリクエストします:

• プロジェクト/問題に関する背景
• チームの議論や共有ドキュメント
• 代替ソリューションが使用されていない理由
• 組織的なコンテキスト(チームダイナミクス、過去のインシデント、政治的問題)
• タイムラインの圧力または制約
• 技術アーキテクチャまたは依存関係
• ステークホルダーの懸念事項

整理することを心配する必要がないことを勧めます。すべてを出しましょう。コンテキストを提供するための複数の方法を提案します:

• 意識の流れでの情報ダンプ
• チームチャネルやスレッドへのポイント
• 共有ドキュメントへのリンク

統合が利用可能な場合(例: Slack、Teams、Google Drive、SharePoint、または他のMCPサーバー)、これらを使用してコンテキストを直接プルできることを言及します。

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

最初のダンプが完了した後、明確化の質問が聞かれることを通知します。

コンテキスト収集中:

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

  • 統合が利用可能: コンテンツが今読まれることを通知し、適切な統合を使用する
  • 統合が利用不可: アクセスの欠如を説明します。Claudeの設定でコネクタを有効にするか、関連するコンテンツを直接貼り付けるようにお勧めします。

• ユーザーが未知のエンティティ/プロジェクトに言及する場合:

  • 接続されたツールを検索して詳しく学ぶべきかどうかを聞く
  • 検索の前にユーザーの確認を待つ

• ユーザーがコンテキストを提供する際に、何が学習されているのか、何がまだ不明確なのかを追跡する

明確化の質問を尋ねる:

ユーザーが初期ダンプを完了したと合図したとき(または実質的なコンテキストが提供された後)、明確化の質問をして理解を確認します:

コンテキストのギャップに基づいて5〜10の番号付き質問を生成します。

ユーザーが簡潔に答える(例: 「1: はい、2: #チャネルを参照、3: 後方互換性のため否」)、より多くのドキュメントへのリンク、チャネルへのポイント、またはただ情報ダンプを続けることができることを通知します。彼らにとって最も効率的な何でも。

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

遷移: この段階で提供したいコンテキストがもっとあるか、それともドキュメントの作成に進む時間かどうかを聞きます。

ユーザーがさらに追加したい場合、許可します。準備ができたら、ステージ2に進みます。

ステージ2: 改善と構成

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

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

1. 含める内容について明確化の質問が聞かれます
2. 5〜20の選択肢がブレーンストーミングされます
3. ユーザーが何を保持/削除/統合するかを示します
4. セクションが作成されます
5. 手術的な編集を通じて改善されます

最初に最も未知数が多いセクション(通常はコア決定/提案)から始めて、残りを進めます。

セクション順序:

ドキュメント構造が明確な場合: どのセクションから始めたいかを聞きます。

最も未知数が多いセクションから始めることをお勧めします。決定ドキュメントの場合、それは通常コア提案です。仕様の場合、それは通常技術的アプローチです。要約セクションは最後に残すのが最適です。

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

この構造が機能するか、それとも調整したいかを聞きます。

構造に同意した後:

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

アーティファクトへのアクセスがある場合: create_fileを使用してアーティファクトを作成します。これにより、Claudeとユーザーがスキャフォルドから作業できます。

すべてのセクションのプレースホルダーを持つ初期構造が作成されることをユーザーに通知します。

「[To be written]」または「[Content here]」のようなプレースホルダーテキストを含むすべてのセクションヘッダーを含むアーティファクトを作成します。

スキャフォルドリンクを提供し、各セクションを埋める時間が来たことを示します。

アーティファクトへのアクセスがない場合: ワーキングディレクトリにMarkdownファイルを作成します。適切に名前を付けます(例: 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インスタンス(この会話からのコンテキストなし)でテストされることを発表します。

各質問について、サブエージェントをドキュメントコンテンツと質問だけで呼び出します。

各質問に対して、リーダーClaudeが正しく/間違いを得たことを要約します。

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

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

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

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

ステップ4: レポートと修正

問題が見つかった場合: リーダーClaudeが特定の問題で苦労したことを報告します。

特定の問題をリストします。

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

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

---

サブエージェントへのアクセスがない場合(例: Claude.ai Webインターフェース):

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

ステップ1: リーダーの質問を予測する

人々がこのドキュメントを発見しようとするときに何の質問をするかを聞きます。彼らはClaude.aiに何を入力しますか？

読者が現実的に尋ねる5〜10の質問を生成します。

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

テスト指示を提供します:

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

各質問について、リーダーClaudeに以下を提供するように指示します:

• 答え
• 何が曖昧または不明確だったかどうか
• ドキュメントが既に既知であると想定しているコンテキスト/知識

リーダーClaudeが正しい答えを与えるか、何か誤解するかをチェックします。

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

リーダーClaudeにも尋ねます:

• 「このドキュメントで読者に曖昧または不明確かもしれないことは何ですか？」
• 「このドキュメントは、読者がすでに持っていると仮定している知識またはコンテキストは何ですか？」
• 「内部矛盾または矛盾がありますか？」

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

リーダーClaudeが何を誤ったか、または何に苦労したかを聞きます。これらのギャップを修正する意図を示します。

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

---

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

リーダーClaudeが一貫して質問に正しく答え、新しいギャップまたは曖昧性を浮上させ続けないとき、ドキュメントは準備ができています。

最終レビュー

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

1. ドキュメントの最終読みを自分で実行することを推奨します。彼らがこのドキュメントを所有し、その品質の責任があります
2. 事実、リンク、技術的詳細をダブルチェックすることをお勧めします
3. それが望んでいた影響を達成することを確認するように依頼します

別のレビューが必要かどうか、それともそれが完了であるかを聞きます。

ユーザーが最終レビューを望む場合、提供します。それ以外の場合: ドキュメント完了を発表します。いくつかの最終ヒントを提供します:

• この会話をドキュメントの附録にリンクすることを検討します。読者がドキュメントがどのように開発されたかを見ることができるようにします
• メインドキュメントをいっぱいにしない深さを提供するために附録を使用します
• ドキュメントを実際の読者からのフィードバックが受け取られるときに更新します

効果的なガイダンスのためのヒント

トーン:

• 直接的で手続き的である
• ユーザーの行動に影響する場合は簡潔に根拠を説明する
• アプローチを「販売」しようとしない。それだけ実行する

逸脱の処理:

• ユーザーがステージをスキップしたい場合: これをスキップしてフリースタイルで書きたいかどうかを聞く
• ユーザーが沮喪しているように見える場合: これが予想より時間がかかっていることを認めます。より速く移動する方法を提案します
• 常にユーザーにプロセスを調整する代理店を与える

コンテキスト管理:

• 全体を通じて、言及された何かについてコンテキストが欠けている場合、プロアクティブに聞く
• ギャップが蓄積させない。それらが現れるときに対処する

アーティファクト管理:

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

スピードより品質:

• ステージを急いで進めない
• 各反復は意味のある改善を行う必要があります
• 目標は実際に読者に対して機能するドキュメントです

使用時期

このスキルは、概要で説明されているワークフローまたはアクションを実行するために適用できます。

制限事項

• 環境固有の検証、テスト、または専門家の確認の代わりとして、この出力を使用しないでください。
• タスクが上記で説明されているスコープと明確に一致する場合のみ、このスキルを使用します。
• 必要な入力、許可、安全境界、または成功基準が欠けている場合は、停止して明確化を求めます。