doc-coauthoring

ドキュメント共同執筆ワークフロー

共同でドキュメントを作成するワークフローです。3つの段階で進めます：Context Gathering → Refinement & Structure → Reader Testing。

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

トリガー条件：

• ユーザーが記事やドキュメントの執筆、共同執筆に言及した
• ユーザーが素材を提供し、コンテンツの作成を求めた

プロセスを簡潔に説明したら、すぐに開始してください。過度に説明しないでください。

Stage 1: Context Gathering

目標： 内容の方向性や文体を含む、十分なコンテキストをすばやく把握します。

基本情報（必ず確認）

1. ドキュメントの種類は何ですか？（公式アカウント／小紅書／技術ドキュメント／提案書）
2. 想定読者は誰ですか？
3. 読み終えた後、どのような効果を期待しますか？
4. あなた自身の意見や視点は何ですか？
5. 分量や文体の希望はありますか？

文体の好み（必ず確認）

重要：後から何度も修正することがないよう、事前に文体を確認してください。

ユーザーに次の点を尋ねます。

• 参考資料はありますか？（ある場合は、まず文体を分析し、それに沿ってください）
• 簡潔な文章と詳しい文章のどちらがよいですか？
• 守ってほしい執筆上の習慣はありますか？

参考資料の文体分析

ユーザーが参考資料を提供した場合：

まず資料を読み、その文体を分析します。

• 文の特徴（短文が中心か、長文が中心か）
• 構成（小見出しの有無、段落の長さ）
• 口調（口語的か、フォーマルか）
• 避けるべきパターン

分析後、ユーザーに「参考資料の文体を把握しました。以降の執筆ではその文体に沿います」と伝えます。

よくある執筆上のアンチパターン（デフォルトで避ける）

ユーザーが明確に希望しない限り、次のパターンは避けてください。

1. 自問自答の文型：❌「これはどういう意味でしょうか？つまり……という意味です」→ ✅ 直接述べる
2. 過剰な対比：❌「……ではなく……」を何度も続ける → ✅ 何であるかを直接述べる
3. 事例を小見出しで分割する：❌ 各事例に太字の見出しを付ける → ✅ 流れのよい文章にまとめる
4. 問いかけから始める：❌「なぜこうなるのでしょうか？」→ ✅ 原因を直接述べる
5. 結論を繰り返す：❌「要するに、以上をまとめると、これはつまり」→ ✅ 省くか簡潔にする
6. 過剰な説明：❌ すべての概念を詳しく説明する → ✅ 読者に基礎知識があることを前提にする

ユーザーが「冗長すぎる」と言ったら、すぐに簡潔にしてください。言い訳は不要です。

素材の取り扱い

ユーザーが素材ファイルを提供した場合：

• 直接読み取る
• 重要な情報を抽出する
• 質問しすぎず、すぐに次の段階へ進む

追加情報が必要な場合：

• インターネットで話題の見解、事例、データを検索できます
• 毎回「検索しますか？」と尋ねず、自分から検索してください

終了条件

ユーザーが基本情報の質問に回答したら、確認を繰り返さず、すぐに Stage 2 へ進んでください。

Stage 2: Refinement & Structure

目標： 各章について、ブレインストーミング、選別、執筆、反復を行います。

構成の決定

ドキュメントの種類に応じて3～6章を提案し、[待執筆] をプレースホルダーとして使ったファイルの枠組み（Markdown ファイル）を作成します。

各章の進め方

Step 1: ブレインストーミング

盛り込める項目を8～15個挙げ、番号を付けて提示します。

**N 个可能包含的点：**
1. xxx
2. xxx
...

**保留哪些？** 比如：`1、3、5、7`

Step 2: 選別

ユーザーが選択肢を返したら、次のように対応します。

• ユーザーが「全部」または「1-N」と言った場合：再確認せず、すべて採用する
• ユーザーが一部を選んだ場合：選ばれた項目だけを使う
• 「これでよいですか？」と聞き返さず、すぐに執筆へ進む

Step 3: 執筆

選別結果に基づいてその章を執筆し、ファイルを直接更新します。

執筆後は、次のようにします。

• その章の内容を引用ブロック形式で提示する
• 「変更したいところはありますか？問題なければ『続ける』とお知らせください」と簡潔に尋ねる

Step 4: 反復

ユーザーからのフィードバックには、次のルールで対応します。

ユーザーの発言	対応
「続ける」	次の章へ進む
「冗長すぎる」	すぐに簡潔にする。説明は不要
「xxxの文型は使わないで」	以降の章でも守る
具体的な修正指示	修正し、結果を提示する

反復はすばやく行います。 ユーザーからフィードバックを受けたら、すぐに修正し、修正後はすぐに提示してください。長々と説明しないでください。

文体の学習

反復を通じて、ユーザーの文体の好みを覚えておきます。

• ユーザーが削除した内容 → 以降は避ける
• ユーザーが「冗長すぎる」と言った → 以降はさらに簡潔にする
• ユーザーが「自問自答はやめて」と言った → すべての章で避ける

すべての章が完成したら

全文を提示して通読してもらい、調整が必要か尋ねます。

Stage 3: Reader Testing（任意）

目標： 新鮮な視点で、ドキュメントが明確かどうかを確認します。

ユーザーから依頼された場合、またはドキュメントが長い／複雑な場合にのみ実施を提案します。

実施方法

1. 読者が疑問に思いそうな点を5～10個予測する
2. サブエージェントを使うか、新しい会話を開いてテストするようユーザーに提案する
3. 問題が見つかった場合は Stage 2 に戻って修正する

---

基本原則

効率を優先

• 確認を繰り返さず、ユーザーが言ったとおりに実行する
• ブレインストーミング後、ユーザーが「全部」と選んだらそのまま採用する
• すばやく反復し、修正したらすぐに提示する

一貫した文体

• 第1章で決めた文体を、以降の章でも守る
• ユーザーの修正フィードバックを覚え、他の箇所にも反映する

簡潔な表現

• 内容は引用ブロックで簡潔に提示する
• つなぎの言葉は一言にする：「続けますか？」「変更したいところはありますか？」
• ワークフローを長々と説明しない

よくあるフィードバックへのすばやい対応

ユーザーの発言	すぐに行うこと
「冗長すぎる」	50％簡潔にする。説明は不要
「自問自答はやめて」	すべての問いかけを削除して書き直す
「まとめて書いて」	小見出しをなくし、流れのよい文章にする
「続ける」	次の章へ進む
「全文を出して」	ファイルを読み、全文を提示する