mcpField
D
docs-update

docs-update

github.com/warpdotdev開発822206 回インストール28 週間前に更新
リポジトリ

docs-update について

コード変更を確認し、ユーザー向けドキュメントを更新してコードベースとの整合性を保つスキルです。一般的なドキュメントプラットフォームに対応し、モノレポと複数リポジトリの構成を扱います。

主な機能

  1. 01重要なコード変更の特定
  2. 02ドキュメントの場所と基盤の確認
  3. 03変更内容をドキュメント更新に対応付け
  4. 04既存ドキュメントのスタイルに準拠
  5. 05ドキュメント変更の作成または報告

活用シーン

  1. 01ユーザー向けコード変更後のドキュメント更新
  2. 02ソースとドキュメントのリポジトリ間の調整
  3. 03ドキュメント編集案のプレビュー

インストール

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

$npx skills add https://github.com/warpdotdev/oz-skills --skill docs-update

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

詳細

Documentation Bot

コードの変更を自動的にレビューし、ユーザー向けドキュメントを更新して、コードベースとの同期を保ちます。複数のドキュメントプラットフォーム（Mintlify、Docusaurus、GitBook、Fumadocs など）に対応し、モノレポとマルチレポの両方の構成をサポートします。

ワークフロー

1. 重要なコード変更を特定する

ドキュメントの更新が必要なコミットを判断します。

  • デフォルトブランチを特定する
  • 最近のコミットを取得する（デフォルトでは過去 24 時間分。ユーザー指定の期間にも対応）
  • 各コミットの変更内容を調べ、何が変更されたかを把握する

重要な変更を絞り込みます：

  • 新機能や新しい機能
  • API の変更（新しいエンドポイント、パラメーター、戻り値）
  • 互換性を損なう変更
  • 新しい設定オプション
  • 新しい CLI コマンドやフラグ
  • ユーザー向けの動作の変更

次の変更についてはドキュメントを更新しません：

  • 内部リファクタリング
  • テストのみの変更
  • 軽微なバグ修正
  • コード内の誤字修正
  • ユーザーへの影響がないパフォーマンス最適化

慎重に判断し、量より質を重視します。重要性に迷う場合は、更新を見送ります。

2. ドキュメントのコンテキストを分析する

ドキュメントの場所を特定します：

  • 現在のリポジトリ内にドキュメント用ディレクトリがあるか確認する（モノレポのパターン）
  • 環境内に独立したドキュメントリポジトリがあるか確認する

ドキュメントプラットフォームを特定します： 設定ファイルとディレクトリ構成を調べて、プラットフォーム（Mintlify、Docusaurus、GitBook、Fumadocs、または一般的な Markdown など）を特定します。

ドキュメントのスタイルを把握します： 既存のドキュメントファイルを複数読み、文調、語り口、構成、コード例のパターン、用語、書式の規則を確認します。スタイルガイドやコントリビューション用ドキュメントも確認します。

3. ドキュメントの更新内容を決定する

コードの変更をドキュメントの更新内容（新規コンテンツ、既存コンテンツの変更や追加）に対応付けます。

ガイドライン：

  • 実装の詳細より、ユーザー向けの変更を優先する
  • 既存ドキュメントの詳しさに合わせる（包括的なものもあれば、簡潔なものもあります）
  • 既存の正確な内容を維持し、可能な限り追加のみで対応する
  • 内容を絞り、一般的な助言は避ける
4. ドキュメントの変更を作成する

既存のスタイルに合わせます：

  • ステップ 2 で特定した文調、語り口、フォーマルさのレベルを踏襲する
  • 見出しの構成と階層を統一する
  • 用語を統一する
  • コードブロックの書式（言語タグ、ハイライト）を合わせる
  • プラットフォームの規則（フロントマター、特殊な構文、カスタムコンポーネント）に従う
5. 実行または報告する

テストモード（ユーザーが「変更内容を確認したい」と依頼した場合）：

次の内容を説明するテキスト要約を出力します。

  • コミットで検出された変更
  • 変更するドキュメントファイル
  • 追加または変更する内容
  • これらの更新が必要な理由

実行モード（自動化として実行する場合）：

  1. 内容がわかるブランチ名を作成する（例：docs/auto-update-YYYYMMDD）

  2. 適切なファイルのドキュメントを変更する

  3. 変更内容がわかるコミットメッセージでコミットする

  4. ブランチをプッシュし、関連するコミットへのリンクを含む説明で PR を作成する：

    • どのコード変更が、どのドキュメント更新を引き起こしたかを列挙する
    • ソースリポジトリのコミット参照または URL を含める
    • 正確性と網羅性についてレビューを依頼する

マルチレポ構成

ソースコードとドキュメントが別々のリポジトリにある場合は、ソースリポジトリで変更を特定した後、ドキュメントリポジトリに切り替えて上記のワークフローに従います。PR の説明にはソースのコミットを記載します。

エッジケース

  • 重要な変更が見つからない場合は、ドキュメントの更新が不要であることを報告する
  • ドキュメントプラットフォームが不明な場合は、標準的な Markdown 構文を使用する
  • 既存の内容と矛盾する場合は、既存の情報を維持し、人による確認が必要な競合として記載する

主な原則

  • 慎重：ドキュメントを煩雑にするより、記載を見送るほうが適切です
  • 一貫性：既存のスタイル、トーン、構成に正確に合わせます
  • 文脈を重視：個々のファイルだけでなく、ドキュメント全体を考慮します
  • 明確さ：変更の重要性と更新の理由を説明します
  • 実用性：実装の説明ではなく、ユーザーがタスクを達成できるよう支援することに重点を置きます

コメント

Markdown 対応