ドキュメント共同作成ワークフロー

読者にとって機能するドキュメント作成のための協調的ワークフロー。

このワークフローを提供すべきタイミング

トリガー条件:

• ドキュメント作成: 「ドキュメントを書く」「提案書を下書きする」「仕様書を作成する」「書き起こす」
• コードドキュメント: 「README を書く」「API ドキュメントを作成する」「このコードをドキュメント化する」「アーキテクチャドキュメント」
• 特定のドキュメント種類: 「PRD」「設計ドキュメント」「意思決定ドキュメント」「RFC」「技術仕様書」
• ユーザーが実質的な作成タスクを開始する場合

ワークフローバリアント

バリアント	ステージ	用途
完全な協調作成	コンテキスト収集 → 改善 → リーダーテスト	提案書、仕様書、意思決定ドキュメント、RFC
簡潔な協調作成	コンテキスト収集 → 改善	README、API ドキュメント、アーキテクチャガイド

両バリアントは協調的原則(質問による明確化、反復的改善)を使用します。簡潔版はリーダーテストをスキップします。コードドキュメントは動作する例や API の正確性など別の検証方法があるためです。

3つのステージの概要

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

ユーザーが知っていることと Claude が知っていることのギャップを埋めます。ドキュメント種類、対象読者、期待する影響、テンプレートについて質問します。情報の詰め込みを促し、理解が十分になるまで明確化質問を続けます。

ステージ 2: 改善とストラクチャリング

セクションごとにドキュメントを構築します。各セクションについて、明確化質問をし、オプションをブレインストーミングし、ユーザーに選別させ、下書きし、手術的編集により改善します。README、API などのスキャフォルドとしてコードドキュメントパターンを使用します。

ステージ 3: リーダーテスト(完全な協調作成のみ)

新しい Claude(コンテキストの漏洩なし)でドキュメントをテストし、読者向けに機能することを確認します。サブエージェントが利用可能な場合は直接テストします。そうでない場合は、ユーザーに手動テストをガイドします。

初期提供テンプレート

トリガーされた時は、ワークフローを提供します:

その[ドキュメント種類]の執筆をサポートできます。ドキュメントが他の人に読まれた時に
うまく機能することを確認するための構造化ワークフローを使用しています:

1. **コンテキスト収集**: あなたが関連するコンテキストを共有し、私が明確化質問をします
2. **改善とストラクチャリング**: ブレインストーミングと反復を通じて各セクションを構築します
3. **リーダーテスト**: 新しい Claude でドキュメントをテストし、見落としを発見します
   (README などのコードドキュメントはスキップ可能)

このワークフローを試してみますか、それとも自由形式で進めたいですか?

コードドキュメントパターン

コードドキュメントについては、開始スキャフォルドとして適切なパターンを選択します:

ドキュメント種類	パターン
README	機能、インストール、クイックスタート、設定、API、貢献
API ドキュメント	OpenAPI スペック(パス、スキーマ、例)
アーキテクチャ	概要、コンポーネント図、コンポーネント表、データフロー
設定	必須/オプション変数表、設定例
モジュール	目的、アーキテクチャ図、コンポーネント、メソッド表

完全なパターンについては WORKFLOW.md を参照してください。

リソース

• WORKFLOW.md - 完全なステージ手順とコードパターン
• EXAMPLES.md - 提案書、仕様書、README の完全なテンプレート
• TROUBLESHOOTING.md - 一般的な問題と解決方法

ヒント

• 直接的かつ手続き的に - ユーザーの行動に影響する場合は簡潔に根拠を説明する
• ユーザーに主導権を与える - ステージをスキップしたり自由形式で進めたりできるようにする
• コンテキストを追跡する - ギャップが生じた時に対処し、蓄積させない
• 手術的編集を使用する - ドキュメント全体を再出力せず、str_replace を使用する
• 速度よりも品質 - 各反復で実質的な改善をもたらす
• コードドキュメント向け - 例が機能することを検証し、API シグネチャを実際のコードに対して確認する