القائمة
[ユーザーとの対話必須] 仕様書・提案書・設計ドキュメント・RFC・ADR などをユーザーと共同執筆するワークフロースキル。「仕様書を作って」「提案書を書いて」「設計ドキュメントを作成して」「PRDを書いて」「RFCを書いて」「ADRを書いて」などで発動する。
يُحدَّد Prompt الذي يراجع المصدر أولًا بشكل افتراضي. يمكنك التبديل إلى أمر مباشر أو تنزيل نسخة محلية.
اقرأ SKILL.md وأي ملفات مرافقة يعرضها SkillsMP قبل أن تقرر التثبيت.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
يتجاوز الأمر المباشر Prompt المخصّص للمراجعة. افحص المصدر قبل تشغيله.
npx skills add https://github.com/ynitto/sandbox --skill doc-coauthoringيبقى الأمر في سطر واحد. مرّر أفقيًا لمراجعته كاملًا قبل النسخ.
تفضّل نسخة محلية؟ نزّل الملفات المتاحة حاليًا لدى SkillsMP.
استنادا إلى تصنيف SOC المهني
عرض SKILL.md
| name | doc-coauthoring |
| description | [ユーザーとの対話必須] 仕様書・提案書・設計ドキュメント・RFC・ADR などをユーザーと共同執筆するワークフロースキル。「仕様書を作って」「提案書を書いて」「設計ドキュメントを作成して」「PRDを書いて」「RFCを書いて」「ADRを書いて」などで発動する。 |
| metadata | {"version":"1.1.0","source":"https://skills.sh/anthropics/skills/doc-coauthoring","tier":"experimental","category":"research","tags":["documentation","rfc","adr","collaborative","interactive"]} |
このスキルは、ドキュメントを共同で作成するための構造化されたワークフローを提供する。コンテキスト収集・構造化と推敲・読者テストの3ステージで、アクティブなガイドとしてユーザーを導く。
注意: このスキルはユーザーとの積極的なインタラクションを前提とする。各ステップでユーザーの確認・選択・フィードバックを求めること。ユーザーの応答を待たずに先へ進まないこと。
トリガー条件:
最初の提案: 構造化ワークフローで共同執筆することを提案する。3つのステージを説明する:
このアプローチにより、他の人が読む際（他者がAIに貼り付けた場合を含む）にも機能するドキュメントが作成できることを伝える。このワークフローを試したいか、自由形式で進めたいかを確認する。
ユーザーが断った場合は自由形式で対応する。承諾した場合はステージ1へ進む。
目標: ユーザーが知っていることとClaudeが知っていることのギャップを埋め、後の賢いガイダンスを可能にする。
ドキュメントのメタコンテキストを確認する:
回答は箇条書きや短縮形でよいと伝える。
テンプレートが提供された場合またはドキュメント種類が言及された場合:
既存の共有ドキュメントを編集する場合:
最初の質問への回答後、持っているコンテキストをすべてダンプするよう促す。以下のような情報を求める:
整理しなくてよいと伝え、とにかくすべて出力するよう促す。コンテキストの提供方法を複数提案する:
統合機能が利用可能な場合（Slack、Teams、Google Drive、SharePoint、その他のMCPサーバーなど）: これらを使ってコンテキストを直接取り込めることを伝える。
統合機能が検出されず、コネクター設定が可能なエージェント環境の場合: エージェントの設定でコネクターを有効にすると、メッセージングアプリやドキュメントストレージから直接コンテキストを引き込めることを案内する（例: Claude.ai の Settings > Connectors）。
VSCode + GitHub Copilot Chat環境の場合:
GitHub Copilot Chatの#fileや@workspaceを使ってリポジトリ内のドキュメントやコードをコンテキストとして引き込める。Teams会議のトランスクリプト（.vttや.txt）があればファイルとして参照できる。
最初のダンプが終わったら確認質問をすることを伝える。
コンテキスト収集中:
チャンネルや共有ドキュメントが言及された場合:
未知のエンティティ・プロジェクトが言及された場合:
コンテキストが提供される中で、分かったことと不明なことを追跡する
確認質問:
ユーザーが初期ダンプを終えたと示した後（または十分なコンテキストが提供された後）、理解のためのギャップに基づいて5〜10個の番号付き質問をする。
回答は短縮形でよい（例:「1: はい、2: #チャンネル参照、3: 後方互換性のため不可」）、追加ドキュメントへのリンク、チャンネルの指示、または情報ダンプの継続も受け付けることを伝える。
終了条件: 基本的なことを説明しなくても、エッジケースとトレードオフについて質問できるようになったとき、十分なコンテキストが収集できた状態とする。
移行: この段階でさらにコンテキストを提供したいか、それとも文書の草稿作成に移るかを確認する。
ユーザーが追加したい場合は追加させる。準備ができたらステージ2へ進む。
目標: ブレインストーミング・精査・反復改善を通じてセクションごとに文書を構築する。
ユーザーへの説明: セクションごとに文書を構築することを説明する。各セクションで:
最も不明点が多いセクション（通常は核心的な決定や提案）から始め、残りを処理する。
セクションの順序:
ドキュメント構造が明確な場合: どのセクションから始めたいか確認する。
最も不明点が多いセクションから始めることを提案する。意思決定ドキュメントなら核心的な提案、仕様書なら技術的アプローチが通常該当する。サマリーセクションは最後に残すのが良い。
ユーザーが必要なセクションを分からない場合: ドキュメントの種類とテンプレートに基づいて、適切な3〜5つのセクションを提案する。
この構造で良いか、調整したいか確認する。
構造が合意されたら:
すべてのセクションにプレースホルダーテキストを入れた初期ドキュメント構造を作成する。
アーティファクト（artifacts）が利用可能な場合（Claude.ai等）:
create_fileを使ってアーティファクトを作成する。これはClaudeとユーザー双方の足場となる。
すべてのセクションヘッダーと「[執筆予定]」や「[ここに内容を記載]」のような簡潔なプレースホルダーテキストを含むアーティファクトを作成する。
ファイルを使う場合（Claude Code・ターミナル環境・VSCode等）:
作業ディレクトリにMarkdownファイルを作成する。適切な名前をつける（例: decision-doc.md、technical-spec.md）。
Windowsの注意点:
- パス区切り文字は
\（ただしMarkdownリンク内では/も可）- ファイル作成時のカレントディレクトリを確認し、絶対パスで伝える
- PowerShellを使う場合:
New-Item -ItemType File -Path "decision-doc.md"または単にWrite-Output "" > decision-doc.md
すべてのセクションヘッダーとプレースホルダーテキストを含むファイルを作成する。
GitHub Copilot Chatの場合:
VSCode上のCopilot Chatでは、#file:decision-doc.mdで作成したファイルを参照しながら共同作業ができることを案内する。
[セクション名]セクションの作業を開始することを告げる。含めるべき内容について5〜10個の確認質問をする。
コンテキストとセクションの目的に基づいた具体的な質問を5〜10個生成する。
回答は短縮形でよい、または重要なことを示せばよいと伝える。
[セクション名]セクションで含めることができる候補を、セクションの複雑さに応じて5〜20個ブレインストーミングする。以下を探す:
セクションの複雑さに基づいて5〜20個の番号付きオプションを生成する。追加のオプションが必要ならブレインストーミングを続けることを提案する。
どのポイントを残す・削除する・統合するかを確認する。次のセクションの優先度を学ぶため、簡潔な理由を求める。
例を示す:
ユーザーが自由形式のフィードバックをくれた場合（「良さそう」「ほとんど良いけど...」など）、希望を抽出して進む。
選択されたものに基づいて、[セクション名]セクションで重要なものが欠けていないか確認する。
選択されたものに基づいてこのセクションを草稿する。
str_replaceを使ってこのセクションのプレースホルダーテキストを実際の草稿内容に置き換える。
アーティファクトを使用している場合: 草稿後にアーティファクトへのリンクを提供する。
読み通して変更したい点を伝えるよう依頼する。具体的に伝えると次のセクションへの学習に役立つと伝える。
ファイルを使用している場合: 草稿完了を確認する。
[ファイル名]に[セクション名]セクションを草稿した旨を伝え、読み通して変更したい点を伝えるよう依頼する。
ユーザーへの重要な指示（最初のセクション草稿時に含める）: ドキュメントを直接編集するのではなく、変更したい点を伝えるよう依頼する。例:「Xの箇条書きを削除 - Yで既にカバーされている」「3段落目をもっと簡潔に」のように。これにより、以降のセクションのスタイル学習に役立てる。
ユーザーのフィードバックに従い:
str_replaceで編集する（全文を再印刷しない）ユーザーが満足するまで反復を続ける。
実質的な変更のない3回連続の反復後、重要な情報を失わずに削除できるものがないか確認する。
セクションが完了したら[セクション名]完了を確認し、次のセクションに進む準備ができているか確認する。
すべてのセクションで繰り返す。
完成が近づいたら（セクションの80%以上完了時）、以下を確認するためにドキュメント全体を再読する意図を告げる:
ドキュメント全体を読み、フィードバックを提供する。
すべてのセクションが草稿・推敲されたら: すべてのセクションが草稿完了であることを告げ、もう一度完全な文書をレビューする意図を伝える。
全体的な一貫性・フロー・完全性をレビューする。
最終的な提案を提供する。
読者テストに進む準備ができているか、それとも何か推敲したいかを確認する。
目標: コンテキストのない新鮮なAIインスタンスで文書を検証し、読者にとって機能するか確認する。
ユーザーへの説明: 読者にとって文書が実際に機能するかテストすることを説明する。著者には意味が通るが他の人を混乱させる盲点を見つけるためのものだと伝える。
サブエージェントが利用可能な場合:
ユーザーの関与なしに直接テストを実行する。
読者がこのドキュメントを発見しようとするときに尋ねそうな質問を予測する意図を告げる。
読者が現実的に尋ねる5〜10個の質問を生成する。
これらの質問を、このコンテキストを持たない新鮮なAIインスタンスでテストする意図を告げる。
各質問について、ドキュメントの内容と質問のみを持つサブエージェントを呼び出す。
各質問について読者AIが正しく回答したか・間違えたかを要約する。
追加チェックを実施する意図を告げる。
あいまいさ・誤った仮定・矛盾を確認するサブエージェントを呼び出す。
発見された問題を要約する。
問題が見つかった場合: 読者AIが特定の問題で詰まったことを報告する。
具体的な問題をリストアップする。
これらのギャップを修正する意図を告げる。
問題のあるセクションの推敲に戻る。
サブエージェントが利用できない場合:
ユーザー自身でテストを行う必要がある。
ドキュメントを発見しようとする際に人々が尋ねそうな質問を確認する。
読者が現実的に尋ねる5〜10個の質問を生成する。
別のAIチャットセッション（現在の会話とは別）を用意してもらう。ドキュメントの内容を貼り付けるか参照させ、生成した質問を尋ねるよう指示する。
各質問について、読者AIに以下を求めるよう指示する:
読者AIが正しく回答するか、それとも何か誤解するかを確認する。
読者AIに以下も尋ねる:
読者AIが間違えたり詰まったりした点を確認する。それらのギャップを修正する意図を告げる。
問題のあるセクションの推敲に戻る。
読者AIが質問に一貫して正しく答え、新たなギャップやあいまいさを指摘しなくなったとき、文書は完成している。
読者テストが通過したら: 文書が読者AIテストを通過したことを告げる。完了前に:
もう一度レビューしたいか、作業が完了したかを確認する。
ユーザーが最終レビューを希望する場合は提供する。そうでない場合: 文書完成を告げる。最後のヒントを提供する:
トーン:
逸脱への対応:
コンテキスト管理:
アーティファクト管理:
create_file を使用する（エージェントがアーティファクトをサポートしている場合）str_replace を使用するWindowsでのファイル管理:
\）と汎用形式（/）を両方案内するNew-Item、Get-Content等）IDEエージェント連携（Copilot、Kiro等）:
#file・@workspace）品質よりスピード優先にしない: