Purpose On pull_request.opened, inspect for dependency drift and anti-patterns, apply safe fixes, and comment with a summary. Scope - Next.js (App Router or Pages Router) + Sanity Content Lake - Agent has repo write access - Only apply safe, non-breaking fixes. For questionable changes, suggest in comments instead of committing. Detection Signals - Next.js: package.json contains next, react, react-dom - Sanity: next-sanity, @sanity/client, sanity.config.(ts|js), /schemas, or GROQ queries - Router: App Router (app/ or src/app/), Pages Router (pages/) --- Agent Steps 1. Identify Project Structure - Determine App Router vs Pages Router - Locate Sanity client config and schema folders - Map GROQ query usage across the app 2. Update Dependencies (Safe Only) - Use project's lockfile manager (npm/pnpm/yarn) - Apply patch/minor only for: next, react, react-dom, next-sanity, @sanity/client, @sanity/image-url, groq - Never auto-apply major updates—suggest with migration links instead - Commit: chore(deps): apply safe minor/patch updates 3. Best-Practice Audit 3.1 Caching & Data Fetching App Router: - Fetch in server components, not client - Add export const revalidate = <seconds> for static-ish pages - Use fetch(..., { next: { revalidate } }) or cache: 'force-cache' - Implement generateStaticParams with dynamicParams = false where feasible Pages Router: - Prefer getStaticProps/getStaticPaths with revalidate over getServerSideProps - Avoid client-side useEffect for initial Sanity data 3.2 GROQ Query Hygiene - Replace * with explicit field projections - Co-locate queries with components or in dedicated modules - Reduce N+1 patterns: use -> for references, limit arrays with [0...N] - Reference: https://www.sanity.io/docs/developer-guides/high-performance-groq 3.3 Sanity Client Config - Pin apiVersion (e.g., '2024-05-01'), never 'vX' - useCdn: true in production, false in preview/draft - Keep tokens server-only - Centralize projectId and dataset in one module 3.4 Images - Use next/image with @sanity/image-url - Always provide width/height or fill + sizes - Compute image URLs server-side when possible 3.5 Anti-Pattern Cleanup - Move above-the-fold Sanity fetches from client to server components - Replace ad-hoc fetch() calls with configured client - Never ship tokens to the browser 3.6 Safety Guardrails - For significant runtime changes (SSR→SSG, aggressive revalidate), suggest only - Add TODO comments for unclear caching semantics 4. Commit Changes Use small, descriptive commits: - chore(deps): safe updates - perf(next/sanity): add caching/revalidate - perf(groq): tighten projections - refactor(sanity): centralize client config - perf(images): use next/image with Sanity URL builder 5. Post PR Comment ## Continuous AI: Next.js + Sanity ### Summary Safe pass for dependency drift and best practices. ### Changes Committed - **Dependencies**: [packages updated] - **Caching**: [files with revalidate added] - **GROQ**: [files with tightened projections] - **Sanity client**: [config improvements] - **Images**: [next/image enforcement] ### Suggestions (Not Auto-Applied) - [file: suggested change] ### Docs - [High-performance GROQ](https://www.sanity.io/docs/developer-guides/high-performance-groq) - [Next.js Data Fetching](https://nextjs.org/docs/app/building-your-application/data-fetching) ### Rollback - `git revert <SHA>` — [description] 6. Idempotency - Skip already-applied changes - Don't flip previous decisions - If nothing to change, comment "No-op" with rationale --- Limits - No framework migrations (Pages→App Router) - No major version bumps - Don't override custom caching logic or webhook setups—suggest instead Success Criteria - PR remains buildable and behaviorally stable - Either: safe commits + detailed comment, or no-op comment with rationale - Clear next steps for any unapplied suggestions