docs-watch

celopedia-skills ドキュメント上流監視

目的: skills/celopedia-skill/references/ にミラーリングされている事実が、そのライブソースから乖離した時点を検出し、すべての検出結果 — 機械的な修正も、曖昧または重要なフラグも同様に — を 1 回の実行につき 1 つのレビュー可能なプルリクエスト で提示すること。これは celo-org/celopedia-skills:main（フォークではなく、正規の上流リポジトリ）に対してオープンされ、人間が承認、編集、またはクローズできるようにします。これは、このリポジトリの README.md ですでに文書化されているプロセス（「Contributing」セクション: docs.celo.org を確認 → ファイルを更新 → バージョンを上げる → PR をオープン）を土台にしていますが、その場限りのレポートや issue を、すべてがレビューされる唯一の場所としての単一の PR に置き換えます。

確認するソース

#	ソース	取得コマンド（詳細は live-data-sources.md を参照）	参照ファイル
1	Docs サイトマップ	curl -s https://docs.celo.org/llms.txt	docs-map.md
2	コントラクトアドレス	https://docs.celo.org/tooling/contracts/core-contracts + token-contracts + l1-contracts + uniswap-contracts (WebFetch)	contracts.md
3	ネットワーク情報	https://docs.celo.org/build-on-celo/network-overview (WebFetch)	network-info.md
4	エコシステム / TVL	curl -s https://api.llama.fi/protocols | jq '[.[] | select(.chains[]? == "Celo")]'	ecosystem.md
5	助成プログラム	curl -s https://www.celopg.eco/programs (WebFetch)	grants-funding.md
6	MiniPay ドキュメント	https://docs.minipay.xyz/ のページツリー + getting-started/submit-your-miniapp.html + getting-started/best-practices.html + technical-references/deeplinks.html (WebFetch)	minipay-docs-map.md、minipay-requirements.md、minipay-common-mistakes.md

ソース 6 — MiniPay: 慎重に分類する

MiniPay のドキュメントは 構造（どのページやディープリンクが存在するか）と ポリシー（掲載されるために何が必須か）を混在させています。これらは同じ扱いを受けません:

• reference update — ドキュメントページの追加 / 削除 / 名前変更、または新規もしくは変更された ディープリンク。これらは構造的な事実です。minipay-docs-map.md を直接編集してください。
• needs review — 掲載要件への変更: 対応または必須のトークン、SLA、依存関係セキュリティポリシー、申請フォームの URL またはフィールド、ホワイトリスト規則、最小ビューポート、またはパフォーマンス基準。これらはデータではなくポリシーであり、スキルがビルダーに何を構築するよう伝えるかを左右します。ドキュメントの差分から minipay-requirements.md や minipay-common-mistakes.md を自動編集してはいけません — 何が変更されたかをキャッシュされている内容と比較して記述し、人間に判断を委ねてください。
• また、minipay-requirements.md と minipay-docs-map.md で引用されている URL が依然として解決できることを確認してください（curl -o /dev/null -w "%{http_code}"）。デッドリンクが reference update になるのは、置き換え先が明確な場合のみです。それ以外の場合はフラグを立ててください。

手順

1. .claude/skills/docs-watch/snapshot.md にある スナップショットを読み込みます — 現在依拠している事実と、それぞれが最後に検証された日付です。

2. 上記の各ソースを 取得し、対応する参照ファイルが文書化しているのと同じ事実（ページ一覧、アドレス表、チェーンパラメータ、プロトコル一覧、プログラムステータス表）を抽出します。

3. 各ソースを、スナップショットとその参照ファイルの現在の内容の両方と 差分比較します。

4. すべての差分を分類します:

   • no action — 見た目上のみ/無関係（例: ドキュメントページの文章が変わったが、 その存在や URL は変わっていない）。PR では言及しません。
   • reference update — 機械的で明白な事実の変更: サイトマップのページが 追加/削除/改名された、Celo チェーンリストに DeFi プロトコルが追加/削除された、 助成プログラムの Live/Past ステータスが反転した、新しい手数料通貨トークンが 追加された。修正した事実を参照ファイルに直接編集し、 実行のブランチ上で行います（ステップ 5 を参照）— 項目ごとにコミットや PR はしません。
   • needs review — 曖昧または重要なもの（一致しないコントラクトアドレス、 チェーン ID / 手数料通貨アドレスの変更、contracts.md のコアプロトコルアドレスや network-info.md のチェーン ID に触れるもの）。ファイルを編集しないでください — これらについて 修正を推測してはいけません。代わりに、観測された内容とキャッシュされている内容を正確に記述した 明確にマークされたエントリを、PR 本文の「Needs review」セクション用に書きます（ステップ 5）。

5. すべての実行は 3 つのいずれかの方法で終わります — このスキルはレポート ファイルを一切書かないため、PR が表示されるかどうか/どのように表示されるかによって、 常に互いに区別できます:

   • ドリフト検出（reference update および/または needs review の差分がある）: 実行全体に対して1 つのプルリクエストを開きます。

     1. main からブランチを作成します（例: docs-watch/<YYYY-MM-DD>）。
     2. そのブランチ上で reference update の編集をすべて適用し、参照ファイルが 変更された場合は skills/celopedia-skill/SKILL.md の version をバンプします （純粋なデータ更新の場合はパッチバンプ）。
     3. 同じブランチ上でスナップショット（ステップ 6）を更新します。
     4. ブランチを celo-org/celopedia-skills に直接プッシュし（この チェックアウトにはプッシュアクセスがあります — フォーク不要）、PR を開きます: gh pr create --repo celo-org/celopedia-skills --base main --head <branch> --title "docs-watch: weekly refresh — <date>" --body "..."
     5. PR 本文がレポートです — 別途レポートファイルはありません。構成は次のとおりです: 冒頭に「何が変わったか」の一行サマリー、ソースごとにその差分と分類を記す セクション、人間の判断を要するもののための明確に分離された Needs review セクション（レビュアーが承認、編集をプッシュ、または PR をクローズします）、 そして diff にすでに適用済みの機械的編集。
     6. 1 つの PR が実行全体をカバーします — reference update と needs review の検出結果を別々の PR に分割しないでください。

   • ブロック（1 つ以上のソースに到達不能 — ネットワークエラー、403、 タイムアウトなど — のため、それらのソースについて差分を評価できなかった）: 小さなプルリクエストも開きます。これにより、ブロックされた実行がクリーンな実行と 黙って区別できなくなることはありません。

     1. main からブランチを作成し（例: docs-watch/blocked-<YYYY-MM-DD>）、 snapshot.md（ステップ 6）の「Last attempt」行のみを編集します — 実際には 何も検証されていないため、参照ファイルもバージョンバンプもありません。
     2. プッシュして、タイトル docs-watch: blocked — <date> で PR を開き、 どのソースが失敗したか、どのように失敗したか（ステータスコード / エラー）、 および（もしあれば）今回の実行で成功したソースを列挙した本文を付けます。
     3. この PR は情報提供目的であり、コンテンツのためにマージするものではありません — レビュアーの本当の修正は根本的なブロッカー（例: ネットワーク エグレス許可リスト）です。マージは単に試行を記録するだけであり、マージせずに クローズしても同様に問題ありません。

   • クリーン（すべてのソースに到達可能、すべての差分が no action）: PR を開かず、何もコミットしません — 完全に沈黙を保ちます。代わりに 最終メッセージで短いサマリーを述べて終了します。

6. スナップショットを更新する。手順 5 で使用したブランチ上で行います：

   • ソースに到達できた drift-found または clean の実行では： ソースごとのファクトを新たに検証した値で更新し、確認した各ソースに Last verified: <date> を設定します。
   • blocked の実行では：ソースごとのファクトには手を付けず（実際には 再検証されていないため）、ファイル先頭の Last attempt: <date> — BLOCKED (<hosts>) 行のみを更新します。
   • ファイルは小さく保ちます — 上記で確認したファクトのみを記載し、 参照ファイルの完全なコピーは含めません。

注意事項

• live-data-sources.md にはすでに優先順位（ライブ API > 公式ドキュメント > ハードコードされた参照 > エコシステムディレクトリ）が 記載されています — このスキルは「ハードコードされた参照」の階層を 誠実に保つためのものであり、他の場所でのライブルックアップを 置き換えるものではありません。
• needs review の項目を「修正」するためにコントラクトアドレスやチェーンパラメータを 推測してはいけません — この階層は、セキュリティ上重要なデータへの事実訂正が 必ず人間の目を最初に通るようにするために存在しています。