A Sanity content change has been detected. Use the Sanity MCP to investigate and sync the codebase with the content changes. **Step 1: Gather Content Details** Use Sanity MCP tools to gather comprehensive information about the changed document: - Get full document details including all fields and references - Understand the document type and its schema - Check for related/referenced documents that may be affected - Review the document's history if relevant **Step 2: Determine Actionability** Carefully analyze the content change to determine if there is anything actionable in the codebase: - Search the codebase for references to this document ID, type, or content - Look for hardcoded content that mirrors Sanity data (constants, seed data, fixtures) - Check for TypeScript types or interfaces that should match the schema - Look for tests that reference this content - If no code references this content, explain why no changes are needed and stop here Common patterns that require code updates: - Hardcoded navigation menus, footer links, or site metadata - Feature flags or configuration stored in Sanity - Static content used in tests or storybook - Generated types from Sanity schema - Content validation or transformation logic **Step 3: Analyze Impact** If code changes are needed: - Identify all files that reference the changed content - Determine if the change is additive (new field) or breaking (removed/renamed field) - Check if the change affects multiple environments (dev, staging, prod) - Consider if dependent content or code needs updating **Step 4: Implement Updates** If there is something actionable (based on your analysis): - Update code to reflect the content changes - Keep changes minimal and focused on the content sync - Maintain consistency with existing code patterns - Do not refactor unrelated code - Ensure type safety if TypeScript is used Common update patterns: - Update hardcoded strings or content arrays - Regenerate TypeScript types if schema changed - Update test fixtures or mock data - Adjust content validation logic - Update static site generation queries **Step 5: Create Draft Pull Request** Create a draft pull request with the following structure: --- **PR Title:** [Sanity] Sync <document type>: <brief description> ## Content Change Summary **Document Type:** `<_type>` **Document ID:** `<_id>` **Action:** <Created | Updated | Deleted> ## What Changed <Brief description of the content change and why code updates were needed> ## Code Updates - <List of files changed and why> ## Content Metadata - **Project:** <projectId> - **Dataset:** <dataset> - **Updated At:** <_updatedAt> ## Links - **Sanity Studio:** [Edit Document](https://<projectId>.sanity.studio/desk/<_type>;_id=<_id>) <details> <summary>Document Details</summary> ```json <Full document from Sanity MCP> <Complete webhook payload> ---Note for AI: - Use Sanity MCP tools to fetch complete document data, not just the webhook payload - The webhook payload contains basic document info; use MCP to get full content - Search thoroughly for code references before concluding no changes are needed - If the content type is not referenced anywhere in code, that's a valid outcome - explain and stop - Focus on content sync, not schema changes (schema changes are handled by sanity-schema-docs) ---Below is the webhook payload from the Sanity content change: