← Back to list

doc-coauthoring
by k35o
This is my site.
⭐ 5🍴 0📅 Jan 24, 2026
SKILL.md
name: doc-coauthoring description: ドキュメント共同執筆ワークフロー。提案書、技術仕様書、設計ドキュメントなどを3段階プロセス(コンテキスト収集→洗練・構造化→読者テスト)で作成。高品質なドキュメントを効率的に共同執筆する際に使用。
ドキュメント共同執筆スキル
このスキルは、ドキュメント、提案書、技術仕様書などを高品質に作成するための構造化されたワークフローを提供する。
使用タイミング
以下のような場面でこのワークフローを提案する:
- 設計ドキュメントの作成
- 技術仕様書の作成
- 提案書・企画書の作成
- 意思決定文書の作成
- READMEやガイドの作成
注意: ブログ記事の作成には
/blog-prepスキルを使用してください。
3段階ワークフロー
ステージ1: コンテキスト収集
目的: ユーザーが知っていることとClaudeが知っていることのギャップを埋める
収集する情報
| カテゴリ | 質問例 |
|---|---|
| 目的 | このドキュメントで何を達成したい? |
| 読者 | 誰が読む?技術レベルは? |
| 背景 | なぜこのドキュメントが必要? |
| 制約 | 期限、フォーマット、長さの制約は? |
| 既存資料 | 参考にできる資料やテンプレートはある? |
| 成功基準 | 何をもって「良いドキュメント」とする? |
実践方法
-
オープンな質問から開始
「このドキュメントについて、持っている情報をすべて教えてください」 -
明確化の質問
- 曖昧な点を具体化
- 前提条件を確認
- 優先順位を把握
-
十分な理解を確認
- 収集した情報を要約して確認
- 不足している情報がないかチェック
ステージ2: 洗練と構造化
目的: セクションごとにドキュメントを構築し、品質を高める
プロセス
各セクションについて:
1. 明確化質問 → 何を書くべきか確認
2. ブレインストーミング → 5〜20のオプションを生成
3. キュレーション → 最適な選択肢を選定
4. ギャップチェック → 不足情報を確認
5. ドラフト作成 → 実際に執筆
6. フィードバック → ユーザーの意見を反映
推奨事項
- 未知が多いセクションから着手: 不確実性を早期に解消
- 外科的編集を心がける: 全体を再印刷せず、必要な部分のみ修正
- 選択肢を提示: 判断が必要な箇所は複数案を示す
セクション構築の例
## [セクション名] について
### 質問
- このセクションで最も伝えたいことは?
- 読者がここで知りたいことは?
### オプション(5案)
1. [アプローチA]: 技術的な詳細から入る
2. [アプローチB]: ユースケースから入る
3. [アプローチC]: 問題提起から入る
4. [アプローチD]: 結論ファーストで進める
5. [アプローチE]: 比較表で示す
### 推奨
オプション4を推奨。理由: 読者の時間を尊重し、結論を先に示すことで...
どのアプローチがよいですか?
ステージ3: 読者テスト
目的: 著者の盲点を発見し、読者にとって機能するドキュメントを確保
テスト方法
方法1: サブエージェントによるシミュレーション
新しいClaudeインスタンスに以下を依頼:
- 読者として質問を予測
- 理解度をテスト
- 曖昧な箇所を指摘
方法2: 新しい会話でテスト
「このドキュメントを、何も背景知識がない状態で読んで、
わかりにくい点や疑問点を教えてください」
チェックリスト
- 専門用語は説明されているか
- 前提知識は明示されているか
- 論理の飛躍がないか
- 読者の「なぜ?」に答えているか
- アクションアイテムは明確か
ユーザーエージェンシーの尊重
このワークフローは提案であり、強制ではない:
- ステージをスキップしてよい
- 自由形式で進めてよい
- 一部のステージだけ使ってもよい
「構造化されたプロセスで進めますか?
それとも自由形式で進めますか?」
編集原則
する
- 外科的な編集(必要な部分のみ修正)
- 選択肢の提示(複数案を示す)
- 確認してから変更
- バージョン管理の意識
しない
- 全体を毎回再印刷
- 勝手に大幅な変更
- ユーザーの意図を無視した「改善」
使用例
例1: 技術設計書の作成
ユーザー: 「新しい認証システムの設計書を作りたい」
Claude: 「設計書の作成ですね。3段階のワークフローで進めましょうか?
まずコンテキストを集めさせてください:
1. この認証システムは何を解決しますか?
2. 誰がこの設計書を読みますか?(開発者、PM、セキュリティチーム等)
3. 既存の認証システムはありますか?
4. 参考にしたいテンプレートや過去の設計書はありますか?」
例2: README更新
ユーザー: 「READMEを更新したい」
Claude: 「READMEの更新ですね。どのような更新を考えていますか?
簡単な更新であれば直接編集できます。
大幅な改訂であれば、共同執筆ワークフローで進めることもできます。
どちらがよいですか?」
このプロジェクトでの活用
k8oプロジェクトでは以下のドキュメントで活用できる:
| ドキュメント | 活用場面 |
|---|---|
docs/API.md | 新しいAPIエンドポイントの仕様書作成 |
docs/ARCHITECTURE.md | アーキテクチャ変更の設計 |
CONTRIBUTING.md | 開発ガイドラインの更新 |
| 新機能提案 | RFC・設計ドキュメントの作成 |
品質チェックリスト
最終確認として:
- 目的が冒頭で明確に述べられている
- 読者の前提知識レベルに合っている
- 構造が論理的で追いやすい
- 専門用語は初出時に説明されている
- 図表や例が適切に使われている
- アクションアイテムが明確(該当する場合)
- タイポや文法ミスがない
- リンクが有効
ライセンス
このスキルは anthropics/skills の doc-coauthoring をベースに作成されています。
Copyright 2025 Anthropic, PBC
原作は Apache License 2.0 でライセンスされています。
MODIFIED: このファイルは原作から以下の変更を加えています:
- 日本語に翻訳
- k8oプロジェクト固有の活用例を追加
- ブログ記事作成手順を別スキル(blog-prep)に分離
Score
Total Score
50/100
Based on repository quality metrics
✓SKILL.md
SKILL.mdファイルが含まれている
+20
○LICENSE
ライセンスが設定されている
0/10
○説明文
100文字以上の説明がある
0/10
○人気
GitHub Stars 100以上
0/15
○最近の活動
3ヶ月以内に更新がある
0/10
○フォーク
10回以上フォークされている
0/5
✓Issue管理
オープンIssueが50未満
+5
✓言語
プログラミング言語が設定されている
+5
○タグ
1つ以上のタグが設定されている
0/5
Reviews
💬
Reviews coming soon