スキル一覧に戻る
k35o

doc-coauthoring

by k35o

This is my site.

5🍴 0📅 2026年1月24日
GitHubで見るManusで実行

SKILL.md


name: doc-coauthoring description: ドキュメント共同執筆ワークフロー。提案書、技術仕様書、設計ドキュメントなどを3段階プロセス(コンテキスト収集→洗練・構造化→読者テスト)で作成。高品質なドキュメントを効率的に共同執筆する際に使用。

ドキュメント共同執筆スキル

このスキルは、ドキュメント、提案書、技術仕様書などを高品質に作成するための構造化されたワークフローを提供する。

使用タイミング

以下のような場面でこのワークフローを提案する:

  • 設計ドキュメントの作成
  • 技術仕様書の作成
  • 提案書・企画書の作成
  • 意思決定文書の作成
  • READMEやガイドの作成

注意: ブログ記事の作成には /blog-prep スキルを使用してください。

3段階ワークフロー

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

目的: ユーザーが知っていることとClaudeが知っていることのギャップを埋める

収集する情報

カテゴリ質問例
目的このドキュメントで何を達成したい?
読者誰が読む?技術レベルは?
背景なぜこのドキュメントが必要?
制約期限、フォーマット、長さの制約は?
既存資料参考にできる資料やテンプレートはある?
成功基準何をもって「良いドキュメント」とする?

実践方法

  1. オープンな質問から開始

    「このドキュメントについて、持っている情報をすべて教えてください」
    
  2. 明確化の質問

    • 曖昧な点を具体化
    • 前提条件を確認
    • 優先順位を把握
  3. 十分な理解を確認

    • 収集した情報を要約して確認
    • 不足している情報がないかチェック

ステージ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/skillsdoc-coauthoring をベースに作成されています。

Copyright 2025 Anthropic, PBC

原作は Apache License 2.0 でライセンスされています。

MODIFIED: このファイルは原作から以下の変更を加えています:

  • 日本語に翻訳
  • k8oプロジェクト固有の活用例を追加
  • ブログ記事作成手順を別スキル(blog-prep)に分離

スコア

総合スコア

50/100

リポジトリの品質指標に基づく評価

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

レビュー

💬

レビュー機能は近日公開予定です