blume-update-docs

Blume Docs の更新

Blume は Astro/Vite 上のMarkdown ファーストなドキュメントフレームワークです。コンテンツはコンテンツルート（デフォルトは docs/）配下の Markdown/MDX として保存され、ナビゲーションはファイルツリーと任意の meta.ts ファイルから生成されます。blume build はフロントマターと重複ルートを検証し、blume validate はリンクとアンカーをチェックします。

あなたの仕事はドキュメントの保守であり、執筆ではありません。リリース済みのユーザー向け動作とドキュメントの記述にずれがある箇所を見つけ、そのずれだけを修正し、サイトが引き続きビルドできることを確認して、プルリクエストとして提出してください。対応すべき内容が見つからなかった場合は、簡潔な報告で終了し、ブランチ、コミット、プルリクエストは作成しません。ノイズの多いプルリクエストを作るより、何もしないことを優先してください。

基本ルール

• リリース済みの機能だけを記載してください。 機能、スケジュール、料金、API、互換性に関する記述を決して創作しないでください。フィーチャーフラグの背後にある機能は、ドキュメントの対象ユーザー向けにフラグが有効になっているか、リポジトリで未リリースの動作について明示的に説明されていない限り、ドキュメントに記載できる状態ではありません。
• 表現の洗練より事実を優先してください。 コマンド、オプション、デフォルト値、ルート、プロパティ、ワークフローに誤りや記載漏れがある場合に編集してください。主観的な言い換え、マーケティング向けの推敲、構成変更、書式だけの変更は避けてください。
• 正しさを保った最小限の差分にしてください。 ずれを解消するために必要な最小限のページだけを編集してください。サイトの文体、フロントマターの形式、コンポーネントの使い方、meta.ts のナビゲーションパターンを維持してください。
• コマンド、フラグ、設定キー、環境変数、ルート、バージョン番号は、情報源と完全に一致する表現を使ってください。記憶を頼りに言い換えず、コードからそのまま転記してください。
• リポジトリのルールを守ってください。 AGENTS.md／CLAUDE.md の規約に従い、生成された出力（.blume/、dist/）には触れず、無関係なローカル変更を上書きしないでください。

ワークフロー

1. コンテキストを把握します。

   • リポジトリのエージェント／コントリビューター向けの指示（AGENTS.md、CLAUDE.md、コントリビューション関連ドキュメント）を読み、それに従います。
   • ドキュメントアプリとコンテンツのルートを特定します。blume.config.ts（content.root）、.md／.mdx ページのディレクトリ、meta.ts ファイル、パッケージマネージャーとドキュメントのビルドコマンドを確認します。
   • この実行にトリガー、調査期間、ドキュメントパス、対象ブランチ、PR ポリシーが設定されている場合は、それに従います。プロンプトに記載がない場合に限り、以下のデフォルトを使用します。

2. メンテナンスブランチを再利用するか、作成します。

   • 前回の実行で作成されたドキュメントメンテナンス用の未完了の PR（head ブランチ名が blume/ で始まるもの）がある場合は、重複して PR を作成せず、そのブランチをチェックアウトして更新します。
   • それ以外の場合は、デフォルトブランチから blume/docs-refresh-YYYY-MM-DD としてブランチを作成します。編集が必要だと確認できてから、ブランチを作成してください。

3. 差分を見つけます。 変更元の一覧と変更基準については、references/audit-checklist.md を読み、以下を行います。

   • デフォルトでは直近 7 日間を対象に、調査期間内にデフォルトブランチへマージされた PR を確認し、ユーザー向けの変更点を抽出します。
   • それらの変更点と、変更履歴、リリースノート、設定スキーマ、エクスポートされた API、CLI のヘルプ、サンプルをドキュメントの内容と照らし合わせます。
   • 確認対象のページが外部リンクに依存している場合に限り、そのリンクを確認します。二次情報より、公式ドキュメントやリリースノートを優先してください。
   • 確認した内容、上流での変更点、各編集が必要（または不要）な理由を記録します。

4. ドキュメントを更新します。

   • 古くなったページを修正します。ページの追加、名前変更、削除に伴い、meta.ts のエントリーを追加、変更、削除します。
   • 周辺のページに合わせます。フロントマターの形式、既に使用されている Blume コンポーネント、コードフェンスのスタイル、ルート相対の内部リンクを確認します。

5. 検証します。

   • ドキュメントのビルド（blume build またはリポジトリで定められたドキュメントの QA コマンド）を実行します。フロントマターと重複ルートが検証されます。
   • 内部リンクとアンカーを確認するため、blume validate を実行します。
   • リポジトリの規約でドキュメントの変更に対して必要な場合は、lint、フォーマット、型チェックを実行します。
   • 編集によって発生した失敗を修正します。既存の失敗はこの PR で修正せず、分けて報告してください。

6. 提出します。

   • 変更がある場合： メンテナンスに関する編集のみをコミットし、blume/* ブランチをプッシュして、デフォルトブランチに対する PR を作成または更新します。タイトルは blume: refresh docs for YYYY-MM-DD のようにします。本文には、確認した情報源、変更したドキュメント、検証コマンドと結果、スキップしたチェック、残存リスクを記載します。
   • 変更が不要な場合： 確認した PR とドキュメントの範囲、および変更不要との結果を報告します。ブランチ、コミット、PR は作成しないでください。

リソース

• references/audit-checklist.md — 情報源のチェックリスト、編集／スキップの基準、Blume 固有の編集ガイドラインです。ドキュメントを変更する前に読んでください。