Update to microCMS

{
  "name": "microcms-nextjs",
  "description": "Next.jsとmicroCMSの連携を公式情報に基づいて実装・改善する。SDKセットアップ、App Routerのデータ取得・動的ルート、キャッシュ・ISR・Webhook、Draft Mode、next/imageの実装や不具合調査で使用する。フレームワーク非依存のAPI仕様・コンテンツ設計のみの相談はmicrocms-guideを優先する。",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 148
    },
    {
      "relative_path": "references/caching.md",
      "size_in_bytes": 14592
    },
    {
      "relative_path": "references/data-fetching.md",
      "size_in_bytes": 10386
    },
    {
      "relative_path": "references/images.md",
      "size_in_bytes": 11496
    },
    {
      "relative_path": "references/preview.md",
      "size_in_bytes": 10801
    },
    {
      "relative_path": "references/setup.md",
      "size_in_bytes": 7808
    }
  ],
  "skill_md_contents": "---\nname: microcms-nextjs\ndescription: Next.jsとmicroCMSの連携を公式情報に基づいて実装・改善する。SDKセットアップ、App Routerのデータ取得・動的ルート、キャッシュ・ISR・Webhook、Draft Mode、next/imageの実装や不具合調査で使用する。フレームワーク非依存のAPI仕様・コンテンツ設計のみの相談はmicrocms-guideを優先する。\nlicense: MIT\n---\n\n# microCMS + Next.js\n\nNext.jsプロジェクトでmicroCMSを適切に利用できるよう、既存コード・Next.jsのバージョン・キャッシュ構成を確認しながら具体的な実装まで支援する。\n\n原則として日本語で回答する。ユーザーが別の言語を指定した場合は、その指定に従う。\n\n## 基本方針\n\n1. 既存プロジェクトが利用可能なら、コードを生成する前に構成を確認する。\n2. Next.jsのバージョン、App Router / Pages Router、`cacheComponents` の有無を確認する。\n3. ユーザーが求める更新反映時間、静的生成の必要性、プレビュー要件を確認する。\n4. microCMS共通の詳細は、`microcms-guide` が利用可能なら関連リファレンスのみを読む。未導入・未読でも、このSkill内の説明と各リファレンスの公式情報から作業を進める。別Skillの自動読み込みを前提にしない。\n5. 新規の例ではApp Routerを基本とするが、既存プロジェクトがPages Routerなら無理に移行させない。\n6. APIキーはサーバー側で扱い、書き込み・下書き全取得・非公開データへアクセスできるキーをブラウザへ渡さない。CSRで直接取得する要件がある場合のみ、公開可能なAPIへのGET専用キーを検討する。Draft Keyも秘密情報として扱う。\n7. Next.jsのキャッシュ仕様はバージョン依存性が高いため、古いパターンを機械的に適用しない。\n\n## 最初にプロジェクト状態を判定する\n\nキャッシュ・データ取得・Draft Modeに関する作業では、可能なら次を先に確認する。\n\n- `package.json` の `next` バージョン\n- `app/` または `src/app/` の有無\n- `pages/` または `src/pages/` の有無\n- `next.config.*` の `cacheComponents` 設定\n- `microcms-js-sdk` のバージョン\n- microCMSクライアントの作成場所\n- APIキーの環境変数名\n- ホスティング先と実行Runtime\n- `output: 'export'` の有無（静的エクスポートではサーバー上のISR・Draft Mode・Webhook受信は実行できない）\n- 既存の `revalidate`、`revalidatePath`、`revalidateTag`、`use cache`、`cacheLife`、`cacheTag` の利用状況\n\nこれらをコードから確認できる場合、ユーザーへ同じ情報を質問しない。\n\n## Next.js 16以降のキャッシュモデルを区別する\n\nNext.js 16では `cacheComponents: true` を有効にした場合と、従来のキャッシュモデルで設計が異なる。\n\n- `cacheComponents: true` の場合は `use cache`、`cacheLife`、`cacheTag` を中心に考える。\n- `cacheComponents` を利用していない場合は、`fetch` の `cache` / `next.revalidate`、Route Segment Config、`revalidatePath` / `revalidateTag` など従来モデルを確認する。\n\n`export const revalidate = 60` をすべてのNext.jsプロジェクトへ無条件に提案しない。\n\n詳細は [references/caching.md](references/caching.md) を読む。\n\n## Server Componentsを基本にする\n\nApp RouterでmicroCMSの公開データをページ表示に使う場合は、特別な理由がなければServer Componentからサーバー側で取得する方法を第一候補にする。\n\n以下の理由だけでClient Componentへしない。\n\n- microCMSを使っているから\n- API取得があるから\n- ページ内に一部インタラクションがあるから\n\nクライアント側の状態・イベント・ブラウザAPIが必要な部分だけをClient Componentへ分離する。\n\nServer Componentから自分自身のRoute Handlerを経由してmicroCMSへアクセスする二重構成も、認証・BFF等の具体的理由がなければ作らない。\n\n## 必要なリファレンスだけを読み込む\n\n- **セットアップ**: `microcms-js-sdk`、環境変数、クライアント、型、安全な配置については [references/setup.md](references/setup.md) を読む。\n- **データ取得**: Server Components、一覧・詳細、Dynamic Routes、`generateStaticParams`、ページネーション、大量ページのビルド時の429については [references/data-fetching.md](references/data-fetching.md) を読む。\n- **キャッシュ・ISR**: Next.js 16のCache Components、従来モデル、ISR、On-demand Revalidation、Webhook、更新反映問題については [references/caching.md](references/caching.md) を読む。\n- **プレビュー**: microCMSのDraft KeyとNext.js Draft Mode、プレビュー開始・終了Route Handlerについては [references/preview.md](references/preview.md) を読む。\n- **画像**: `next/image`、`remotePatterns`、microCMS画像API、custom loaderの使い分けについては [references/images.md](references/images.md) を読む。\n\n複数領域にまたがる場合は必要なリファレンスを組み合わせる。\n\n例:\n\n- 「Webhookで記事更新を即反映したい」 → `caching.md`\n- 「下書きプレビューが古い」 → `preview.md` + `caching.md`\n- 「画像転送量を減らしたい」 → `images.md` + `microcms-guide` の画像・performance原則\n\n## 実装を変更するとき\n\n既存プロジェクトでは次の順に進める。\n\n1. 現在のmicroCMSクライアントとデータ取得関数を確認する。\n2. キャッシュ戦略を確認する。\n3. 問題を再現する経路を特定する。\n4. 最小限の変更で解決する。\n5. プロジェクト既存の命名・ディレクトリ・型・lint/format方針に従う。\n6. 不要な依存パッケージや抽象化を追加しない。\n\nユーザーがコード修正を求めている場合は、説明だけで終わらせず、可能なら実際のファイルへ一貫した変更を行う。\n\n## 更新が反映されない問題を診断する\n\n「microCMSでは更新したのにNext.jsへ反映されない」場合は、次の順序で切り分ける。\n\n1. microCMS Content APIを直接確認し、期待する公開データが返っているか。\n2. Next.jsがどのデータ取得方式を使っているか。\n3. `cacheComponents` の有無とキャッシュ設定。\n4. 時間ベースのrevalidationかOn-demand Revalidationか。\n5. Webhookが受信できているか。\n6. `revalidatePath` / `revalidateTag` / `cacheTag` の対象が正しいか。\n7. ホスティング・CDNなど別キャッシュ層があるか。\n\nmicroCMSのCDNとNext.jsのキャッシュを混同しない。\n\n## 品質基準\n\n公式開発者ドキュメントの取得・仕様確認には、利用可能なら `microcms-docs` を併用する。設計判断や実装はこのSkillで進め、必要なページだけ確認する。未導入の場合は各referenceの公式出典を直接確認する。\n\n- バージョン依存のNext.js挙動は、可能なら現在の公式Next.jsドキュメントを確認する。\n- 新規コードも導入済みNext.js・SDKのバージョンに合わせる。最新ドキュメントのAPIを旧バージョンへそのまま持ち込まない。同梱内容と対象バージョンの公式仕様が矛盾する場合は公式仕様を優先する。\n- キャッシュ戦略は更新要件から逆算する。\n- 公開予約など時刻の正確性が重要な場合は、時間ベースISRだけで要件を満たせるか慎重に判断する。\n- Draft Modeでは秘密情報とリダイレクト先を検証する。\n- 画像最適化では、Next.js Image OptimizationとmicroCMS画像APIの役割を明確にし、二重最適化を目的なく行わない。\n- microCMS固有の仕様をNext.jsの仕様として、Next.js固有の仕様をmicroCMSの仕様として説明しない。\n"
}