mcpField
D
doc-coauthoring

doc-coauthoring

github.com/full-stack-skillsドキュメント278 回インストール4 週間前に更新
リポジトリ

doc-coauthoring について

doc-coauthoring は、根拠の整理、構成案の作成、執筆、読者テストを通じて文書を共同で作成・改善するスキルです。依頼に応じて手順を調整し、専門的な文書作成は指定のスキルに引き継ぎます。

主な機能

  1. 01文書の目的と読者のニーズを明確化
  2. 02事実、決定、制約、未解決事項を整理
  3. 03目的に合った文書構成を提案
  4. 04根拠の不足を示しながら執筆・改稿
  5. 05読者の質問に照らして文書を検証

活用シーン

  1. 01資料を基に意思決定文書を作成
  2. 02既存文書を対象を絞って改稿
  3. 03草稿の曖昧さや根拠のない主張を確認
  4. 04API リファレンスやチュートリアルを専門スキルに引き継ぎ

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/full-stack-skills/document-skills --skill doc-coauthoring

インストール後、Claude Code で/doc-coauthoringを入力して読み込まれたか確認します。

同梱ファイルagents/openai.yaml

詳細

ドキュメントの共同執筆

積極的な執筆パートナーとして振る舞います。決まった質問をユーザーに強いるのではなく、依頼に応じてワークフローの深さを調整してください。

専門的な成果物の振り分け

  • 製品ドキュメント一式や PRD の階層構造:full-stack-doc スキルに引き継いでください。次のコマンドでインストールできます:npx skills add full-stack-skills/document-skills --skill full-stack-doc。
  • 技術チュートリアルや統合記事:technical-blog-doc スキルに引き継いでください。次のコマンドでインストールできます:npx skills add full-stack-skills/document-skills --skill technical-blog-doc。
  • API リファレンスの生成:api-doc-generator スキルに引き継いでください。次のコマンドでインストールできます:npx skills add full-stack-skills/document-skills --skill api-doc-generator。

関係者の背景、論旨の構成、読者テストが主な課題である場合は、専門スキルと併せてこのスキルを使用してください。

ステージ 1:執筆の前提を確認する

依頼と利用可能な資料から、次の点を確認します。

  • ドキュメントの種類と、それによって可能にすべき意思決定。
  • 主な読者と副次的な読者。
  • 読者に期待する行動または理解。
  • 必要な形式、長さ、期限、承認上の制約。
  • 情報源とその権威レベル。
  • 対象ファイルまたは共有ドキュメント(該当する場合)。

ドキュメントに実質的な影響を与える質問だけをしてください。簡略な記述や、構成されていないコンテキストの一括共有も受け入れてください。

ステージ 2:根拠を整理する

入力を次のように分類します。

カテゴリ扱い
検証済みの事実そのまま記載し、有用であれば出典を引用またはリンクする
決定事項担当者、根拠、影響を記録する
制約代替案への影響を説明する
仮定明示し、必要な検証を特定する
未解決の質問担当者または次のアクションを記録する
意見発言者を明記するか、根拠のある推奨事項にする

参照されているファイルや接続済みの情報源が利用可能な場合は読み込んでください。利用できない連携機能やツールにアクセスできると主張してはいけません。関係者の立場を捏造してはいけません。

ステージ 3:構成を提案する

ドキュメントの目的に合ったアウトラインを提示します。一般的でない順序を採用する場合に限り、その理由を説明してください。既存のドキュメントについては、有用な構成を維持し、全面的に置き換えるのではなく、焦点を絞った変更を提案してください。

意思決定ドキュメントで一般的な流れ:

  1. エグゼクティブサマリー
  2. 背景と課題
  3. 目標と対象外
  4. 制約と根拠
  5. 検討した選択肢
  6. 推奨事項と根拠
  7. リスクと軽減策
  8. 展開、検証、担当者
  9. 未解決の質問

ステージ 4:執筆と推敲

  • 価値の高いセクションから先に執筆します。
  • 用語の一貫性を保ち、曖昧な用語は一度定義します。
  • 一般論より、具体的な主張、例、判断基準を優先します。
  • ユーザーの文体と希望する言語を維持します。
  • 根拠が不足している箇所には、待確認 または同等のマーカーを付けます。
  • 重要な未解決の決定事項は文章に埋もれないよう、別途記録します。
  • ファイルを編集する際は、重要な構成変更を提示または要約し、無関係な内容を上書きしてはいけません。

ステージ 5:読者テスト

実際の読者の前提に照らしてドキュメントをテストします。

  1. 初めて読む人が抱く質問を予測します。
  2. 会話の文脈がなくても、ドキュメントが各質問に答えているか確認します。
  3. 曖昧な代名詞、未定義の用語、隠れた仮定、裏付けのない主張、欠けているつなぎを特定します。
  4. 求められている判断やアクションが明確か確認します。
  5. 重大な読者の疑問がなくなるまで修正を繰り返します。

独立したエージェントを利用でき、テストが安全な場合は、意図した回答を知らせずに、ドキュメントと読者の質問を新しいエージェントに渡してください。それ以外の場合は、ドキュメントの内容だけを使って初見の読者として確認します。

完了時の報告事項

依頼された成果物を作成または更新した後、次の点を報告します。

  • 最終的な構成と重要な決定事項。
  • 未解決の質問と、判明している場合はその担当者。
  • 引き続き検証が必要な根拠。
  • 読者テストで見つかり、修正した問題。
  • ファイルを作成した場合は、その正確な出力先。

コメント