50+ Next.js Prompts for Claude Opus 4.7 (2026 Edition)

Building Next.js apps with Claude Opus 4.7 changes the math. A Server Component refactor that used to eat two hours of careful manual rewriting now happens in under five minutes — if you ask the right question. A middleware bug that would have buried an afternoon in stack-trace archaeology gets diagnosed in two turns — if you point Opus at the right files.

What follows is 60 production-tested Claude Opus 4.7 prompts, organized by what you are actually trying to ship: routing, Server Components, data fetching, middleware, performance, SEO, testing, deployment. Every template here is pulled directly from the prompts we run on Claude Code at PromptsRush — including the codebase this article lives in. Nothing recycled. Nothing speculative.

Three reasons Opus 4.7 dominates Next.js work in 2026: a 1M-token context window that holds an entire mid-sized App Router repo without RAG gymnastics (which is why Opus actually understands how your layout.tsx at /dashboard affects rendering in your /dashboard/[org]/settings route), genuine TypeScript reasoning that does not paper over a problem with any when the right answer is a discriminated union, and the agentic loop that makes Claude Code, Cursor, and Cline reliable for multi-file refactors instead of just one-shot codegen.

If you want the broader case for choosing Opus over the cheaper Flash-class models, our Gemini 3.5 Flash vs Claude Opus 4.7 for coding deep-dive lays out the tradeoff cleanly. For prompts that extend beyond Next.js into general Opus workflows, 100 Best Claude Opus 4.7 Prompts for Power Users is the companion library.

How to Use This Cheat Sheet

• Templates use [BRACKETS] for variables. Replace with your actual values. Some prompts assume you paste in a file, a route config, or a stack trace.
• Run them anywhere Opus 4.7 lives. Claude Code, Cursor, Cline, Continue, claude.ai, or the API directly. The phrasings are model-prompt, not interface-specific.
• Pair them with the right context. For multi-file work, also paste your next.config.ts, your app/ tree, and any relevant layout.tsx files. Opus uses the context — give it real context.
• Use Claude Code project memory for repeated context. Things like your file structure, type aliases, and design system stay in CLAUDE.md so you do not paste them every turn.

10 Meta-Rules for Getting Production Next.js Code Out of Opus 4.7

1. Name your Next.js version. App Router semantics evolve every minor release. "Next.js 15.4" or "Next.js 16 LTS" changes Opus answers materially.
2. State the rendering strategy up front. "Statically generated", "ISR with 60s revalidate", "fully dynamic", "PPR with a dynamic shell" — Opus calibrates everything else to this.
3. Always declare Server vs Client. If you forget, Opus will guess — and the guess will sometimes be wrong, leading to invisible "use client" creep.
4. Paste the route file structure. Not just the file you are editing — show the surrounding layout.tsx, any loading.tsx, the parent route group. App Router is composition; show the composition.
5. For data fetching, name the cache strategy explicitly. "Force-cache with tag posts", "no-store", "revalidate 3600". Vague asks get vague fetch() calls.
6. Forbid invented APIs. Add "Do not use any API that does not exist in Next.js [VERSION]. If unsure, say so." This kills the most common Opus failure mode in Next.js: confidently using a hook that does not exist.
7. Ask for the test alongside the code. Opus writes better code when it knows a test is coming. Always.
8. For middleware, paste the matcher. Middleware behavior depends entirely on matcher config. Without it, every answer is half right.
9. Name your deployment target. Vercel, self-hosted Node, Cloudflare Workers, Docker — the right answer for "make this fast" depends entirely on this.
10. Use extended thinking for refactors. Turn on Opus 4.7 extended thinking for any task that touches more than 2 files. The wall-clock cost is 10–30 seconds. The cleanup cost without it is much higher.

Pro tip: When Opus suggests a Next.js API that does not look familiar, do not trust it without checking. Even Opus 4.7 occasionally invents plausible-sounding hooks (useRouteCache, revalidatePathAndTag) that simply do not exist. The fix is one line in your prompt: "Cite the Next.js docs URL for any API you use."

---

1. App Router & Routing (Prompts 1–8)

1. The Route Generator

Create a new App Router route from scratch.

You are a Next.js [VERSION] expert. Generate the files for a new route at [PATH], including page.tsx, layout.tsx (only if it needs its own layout), loading.tsx, and error.tsx. The page is a [SERVER/CLIENT] component that does [DESCRIPTION]. Use TypeScript, no default exports of unnamed functions, and Tailwind for styling. Output each file in its own code block with the file path as a comment on line 1.

2. The Nested Layout Generator

Shared layout for a route subtree.

Generate a Next.js App Router layout.tsx for the route group [PATH]. It must: (1) render shared chrome [DESCRIBE: nav, sidebar, header], (2) NOT re-render when child routes change, (3) accept a children prop typed as React.ReactNode, (4) include a Suspense boundary around children for streaming. Export metadata too if it applies to all children.

3. The Parallel Route Generator

For modals and slot-based UI.

I want a parallel route at [PATH] with a @[SLOT_NAME] slot for [PURPOSE — e.g., an auth modal, a dashboard side panel]. Generate: (1) the @[SLOT_NAME] folder structure with page.tsx and default.tsx, (2) the updated parent layout.tsx that receives the slot as a prop, (3) explanation of when default.tsx renders vs page.tsx. Use the latest App Router conventions.

4. The Intercepting Route Generator

Soft-modal pattern that survives reload.

Build an intercepting route for [USE CASE — e.g., a photo viewer that opens as a modal from the feed but renders as a full page on direct URL load]. Show: (1) the directory structure with the (.) or (..) prefix, (2) the page.tsx for both the intercepted modal version and the standalone version, (3) the Link component usage from the feed page that triggers it. Next.js [VERSION].

5. The Dynamic Segment Generator

Single, catch-all, optional catch-all.

Generate the page.tsx for a dynamic route at [PATH], where [PATH] uses [DYNAMIC/CATCH_ALL/OPTIONAL_CATCH_ALL] segment style. Type the params prop precisely (it is a Promise in Next.js 15+). Include generateStaticParams for ISR if applicable. The page renders [DESCRIPTION]. TypeScript, App Router.

6. The Loading State Generator

loading.tsx with proper Suspense skeleton.

Generate a loading.tsx for the route at [PATH]. It should: (1) render a skeleton that matches the actual page layout dimensions (no layout shift on load), (2) use Tailwind animate-pulse, (3) include accessibility — aria-busy and a visually-hidden "Loading" announcement. Use the page.tsx below as the structural reference.
===PAGE===
[PASTE]
===END===

7. The Error Boundary Generator

error.tsx with reset and reporting.

Generate an error.tsx for the route [PATH]. Requirements: (1) "use client" directive, (2) typed error prop with optional digest, (3) reset function wired to a retry button, (4) error reporting to [Sentry/PostHog/console], (5) graceful fallback UI matching the route style. Do not expose error.message to the user in production — log it, show a friendly message.

8. The Route Group Reorganizer

Refactor routes into (groups) without breaking URLs.

My current App Router structure is below. I want to reorganize using route groups [DESCRIBE GROUPS — e.g., (marketing), (app), (auth)]. Constraints: (1) public URLs must not change, (2) each group can have its own root layout, (3) explain any layout that needs to move. Output: the new directory tree, then a numbered list of file moves with "from → to" syntax.
===CURRENT TREE===
[PASTE tree output of app/]
===END===

---

2. Server Components & Server Actions (Prompts 9–18)

9. The RSC Data Fetcher

Server Component that fetches and renders.

Build a Server Component at [PATH] that fetches [DATA DESCRIPTION] from [SOURCE — Supabase, Postgres via Drizzle, REST API, etc.] and renders [UI DESCRIPTION]. Do not use useEffect — this is RSC. Type the fetched data precisely. Handle the empty/loading/error cases. If the data is user-specific, get the user from [auth() / getServerSession() / your auth helper].

10. The Server Action Form Handler

Form with progressive enhancement.

Build a form that [DESCRIBE — e.g., creates a new post]. Requirements: (1) Server Action handles the submission with "use server", (2) form works without JavaScript (progressive enhancement), (3) uses useFormStatus for pending state, (4) uses useActionState for returning errors, (5) revalidates [PATH/TAG] on success, (6) redirects to [PATH] on success. Zod for validation.

11. The Server Action with Zod Validation

Strict input validation, typed errors.

Write a Server Action named [NAME] that accepts FormData, validates against a Zod schema [DESCRIBE FIELDS], and returns either { ok: true, data } or { ok: false, errors }. Use safeParse, not parse. The returned errors object must be shaped for direct field-level rendering in the client. TypeScript with full type inference from the Zod schema.

12. The Optimistic UI Pattern

useOptimistic with rollback.

Convert the component below to use useOptimistic for [ACTION — e.g., liking a post]. Requirements: (1) optimistic state updates immediately on click, (2) Server Action runs in the background, (3) on error, state rolls back automatically, (4) the optimistic state is derived from the real state so it self-heals on the next render. Show both the client component and the Server Action.
===COMPONENT===
[PASTE]
===END===

13. The Server-to-Client Boundary

Pass server data into a client component cleanly.

I have a Server Component that fetches [DATA] and a Client Component that needs to render it interactively. Show me: (1) how to type the props, (2) how to serialize correctly (no Date, no Map, no class instances passed across), (3) where to put the "use client" boundary, (4) how to avoid passing the entire server response when only a subset is needed. Code below.
===SERVER COMP===
[PASTE]
===CLIENT COMP===
[PASTE]
===END===

14. The Client-to-Server Component Converter

Identify what can move server-side.

Audit the client component below. Identify every piece that does NOT need to be a client component — anything not using hooks, browser APIs, or event handlers. Then refactor: extract the server-safe parts into a parent Server Component, leave only the interactive parts in the client child. Output: the new structure as two files. Explain what you moved and why.
===COMPONENT===
[PASTE]
===END===

15. The "use client" Boundary Optimizer

Below is a component tree where "use client" appears at the top. Identify the minimum subtree that actually needs to be client-side, push the boundary down to that subtree, and refactor. The goal: reduce client bundle size. After the refactor, list which props now cross the server/client boundary and confirm they are all serializable.
===TREE===
[PASTE]
===END===

16. The Server Action Mutation + Revalidate

Write a Server Action that mutates [RESOURCE] (insert/update/delete) and revalidates the right cache surfaces. Decide between revalidatePath and revalidateTag based on what the mutation affects. Explain the choice in a one-line comment above the revalidate call. If the mutation is part of a transaction, wrap it. Use [DB CLIENT — e.g., Drizzle, Supabase].

17. The Form Action with Progressive Enhancement

Refactor the JavaScript-driven form below to use a native form action with a Server Action. Requirements: (1) form posts even with JS disabled, (2) loading state via useFormStatus, (3) error state via useActionState, (4) no client-side fetch call at all, (5) preserves the existing styling. Output the new form component and Server Action.
===FORM===
[PASTE]
===END===

18. The Server Component Composition Refactor

I have a Server Component that is becoming too large. Below it is. Split it into 3–5 smaller Server Components, each with a single responsibility. Keep all fetching as close to the rendering as possible (no top-of-tree fetching what a leaf needs). Show the new structure as a parent + children layout.
===COMPONENT===
[PASTE]
===END===

---

3. Data Fetching & Caching (Prompts 19–26)

19. The Fetch with Cache Strategy

Write a fetch call for [ENDPOINT] in a Server Component with cache strategy [force-cache / no-store / revalidate N]. Include a cache tag of [TAG] for selective invalidation. Type the response precisely. Handle non-2xx with a thrown Error that error.tsx can catch. If the data is user-scoped, explain how that interacts with the cache (it usually means no-store).

20. The unstable_cache Wrapper

Wrap the function below in unstable_cache with: (1) a stable cache key that includes [PARAMS], (2) tags [TAG1, TAG2] for revalidation, (3) revalidate of [N] seconds. Note any caveats — closure variables, Date.now, randomness. If the function takes parameters, make sure they are reflected in the key, not closed over.
===FUNCTION===
[PASTE]
===END===

21. The Cache Tag Strategy

Design the cache tag strategy for my app. Resources: [LIST — e.g., posts, comments, users]. For each, list: (1) the tag(s) to attach to fetch/unstable_cache, (2) which Server Actions revalidate which tags, (3) whether tags should be hierarchical (e.g., posts vs posts:[id]) or flat. Output: a markdown table mapping each Server Action to the tags it revalidates.

22. The ISR Configuration

I have a dynamic route at /[SEGMENT] that should be ISR with a [N]-second revalidate. Show me: (1) the generateStaticParams that pre-builds the top [N] items at build time, (2) the dynamicParams setting, (3) the fetch with the right cache option, (4) what happens to a request that hits a stale page during revalidation, (5) on-demand revalidation endpoint to bust the cache manually.

23. The On-Demand Revalidation Endpoint

Build a POST API route at /api/revalidate that accepts a secret in the Authorization header, validates it against process.env.REVALIDATE_SECRET, and revalidates [TAG/PATH] from the request body. Return 401 on bad secret, 400 on missing body, 200 on success. Include a curl example in a comment at the bottom.

24. The Parallel Data Fetching Pattern

Below is a Server Component that fetches data sequentially with three awaits. Refactor to fetch in parallel using Promise.all. If any single fetch is allowed to fail without breaking the page, switch that one to Promise.allSettled and handle the rejected case in the render. Type the destructured result correctly.
===COMPONENT===
[PASTE]
===END===

25. The Sequential vs Parallel Audit

Audit the data-fetching in the Server Component below. For each fetch, decide: must this run after a prior fetch (true dependency), or can it run in parallel? Identify the waterfall. Then output a refactored version that maximizes parallelism without creating overfetch. Add comments at every fetch explaining why it is sequential or parallel.
===COMPONENT===
[PASTE]
===END===

26. The Cache Invalidation Debugger

My cache is not invalidating after a Server Action. Below: the Server Action, the fetch that should be invalidated, and the route. Diagnose the most likely causes in order of probability. For each, explain how to verify and how to fix. Common suspects to consider explicitly: missing tags, wrong tag name, full route cache vs data cache, build-time vs runtime, dev mode caching off.
===ACTION===
[PASTE]
===FETCH===
[PASTE]
===ROUTE===
[PASTE]
===END===

---

4. API Routes & Middleware (Prompts 27–34)

27. The Route Handler with Validation

Build a [GET/POST/PATCH/DELETE] route handler at /api/[PATH]. Requirements: (1) Zod-validate the [body/query/params], (2) auth check via [AUTH HELPER], (3) typed response with NextResponse.json, (4) proper status codes (200/201/400/401/403/404/500), (5) no leaking of internal error messages. Use export async function [METHOD] syntax — App Router, not Pages.

28. The Edge Runtime Handler

Build a route handler at /api/[PATH] that runs on the edge runtime. Requirements: (1) export const runtime = "edge", (2) no Node-only APIs (no fs, no Buffer of the wrong size, no native modules), (3) explicitly call out anything I am using that would not work on edge, (4) stream the response if applicable. The handler does [DESCRIPTION].

29. The Middleware Auth Gate

Write middleware.ts that: (1) protects all routes under /dashboard and /admin, (2) reads the session token from the [cookie name], (3) verifies it via [JWT verify / session lookup], (4) redirects unauthenticated requests to /login with the original path as a returnTo param, (5) does NOT run on /api/auth, static assets, or /_next. Output: the middleware function and the matcher config.

30. The Locale Redirect Middleware

Write middleware that handles i18n routing: (1) detects the user locale from cookie first, Accept-Language header second, (2) if the path lacks a locale segment, redirects to /[locale][path], (3) sets a NEXT_LOCALE cookie on every response, (4) skips /api, /_next, and static files via the matcher. Supported locales: [LIST].

31. The Middleware Rewrite

I need to A/B test [PATH] between two implementations. Write middleware that: (1) reads a feature-flag cookie (or assigns one), (2) rewrites the URL to /[PATH] or /[PATH-experiment] based on the bucket, (3) the URL bar stays at /[PATH] (rewrite, not redirect), (4) the experiment assignment is sticky via cookie. Set the cookie if it does not exist.

32. The CORS Middleware

Add CORS handling to my Next.js app. Allowed origins: [LIST]. Required for: routes under /api/public. Requirements: (1) handle OPTIONS preflight, (2) reflect the origin only if it is in the allowlist, (3) set Access-Control-Allow-Credentials: true, (4) set the right methods and headers. Implement as middleware with the right matcher — not as logic in every route handler.

33. The Rate Limiter Middleware

Implement IP-based rate limiting in middleware: [N] requests per [WINDOW] per IP, applied to /api/* only. Use [Upstash Redis / Vercel KV / in-memory map with TTL]. Return 429 with a Retry-After header when exceeded. Identify the client IP correctly behind Vercel (x-forwarded-for first entry). Include a comment about the in-memory limitation if that backend is chosen.

34. The Signed Webhook Handler

Write a POST route handler at /api/webhooks/[PROVIDER] that: (1) reads the raw request body as text (not parsed JSON), (2) verifies the signature against the [PROVIDER] signing secret using [HMAC algorithm], (3) returns 401 if invalid, (4) parses and processes the event in a switch on event.type, (5) returns 200 quickly and offloads slow work to a background task or queue.

---

5. Performance & Optimization (Prompts 35–42)

35. The Bundle Analyzer Setup

Set up @next/bundle-analyzer in my Next.js project. Output: (1) the next.config.ts changes, (2) the package.json script to run it (ANALYZE=true), (3) what to look for in the report — first-load JS over [N] kB, suspiciously large dependencies, duplicate packages. After the setup, audit my package.json (below) and flag the top 3 likely culprits.
===PACKAGE.JSON===
[PASTE]
===END===

36. The Hero Image Optimization

Convert the <img> tag below to a Next.js <Image> component for an above-the-fold hero. Requirements: (1) priority=true to preload, (2) explicit width and height, (3) sizes attribute matching my responsive breakpoints, (4) fetchPriority="high" if not set by priority, (5) AVIF/WebP output. Add a placeholder="blur" only if I provide a blurDataURL.
===IMG===
[PASTE]
===END===

37. The Blog Content Image Pattern

Generate a reusable BlogImage component for inline article images. Requirements: (1) wraps next/image, (2) accepts src, alt, caption, (3) renders the caption as a styled figcaption, (4) lazy loads (no priority), (5) sizes="(min-width: 768px) 720px, 100vw", (6) responsive aspect ratio preserved. TypeScript, Tailwind, App Router compatible.

38. The Font Optimization Setup

Configure next/font for my app. I want [FONT NAMES — e.g., Inter for body, JetBrains Mono for code]. Requirements: (1) use next/font/google with subsets, (2) variable fonts where possible, (3) display: "swap", (4) preload only the body font, (5) expose them as CSS variables on the html element, (6) reference them in tailwind.config.ts. Output every file that needs to change.

39. The Streaming Suspense Pattern

Below is a Server Component that awaits slow data inline, blocking the entire page. Refactor to stream: (1) hoist the fast/static UI above any slow fetches, (2) wrap each slow fetch in a Suspense boundary with a meaningful fallback, (3) move the slow fetches into named async sub-components, (4) explain what the user sees on first paint vs after streaming completes.
===COMPONENT===
[PASTE]
===END===

40. The Partial Prerendering Setup

Convert the route below to use Partial Prerendering. Identify the static shell vs the dynamic holes. Wrap each dynamic hole in Suspense with a sensible fallback. Update next.config.ts to enable PPR if not already enabled. Output the converted page.tsx and call out which parts will be cached at the edge vs rendered per request.
===ROUTE===
[PASTE]
===END===

41. The Dynamic Import Pattern

The component below is loaded on every page but only used after a user interaction. Refactor it with next/dynamic: (1) dynamic import with ssr: false if it has browser-only deps, (2) loading state with a skeleton, (3) only load on the interaction (click handler triggers a state change that mounts it). Show before and after.
===COMPONENT===
[PASTE]
===END===

42. The Lighthouse Audit Prompt

I ran Lighthouse on [URL] and got the report below. For each metric under [TARGET — e.g., LCP under 2.5s, CLS under 0.1], output: (1) the most likely Next.js-specific cause, (2) the smallest change that would move the metric, (3) the file or config I should edit. Skip metrics already in the green. Prioritize fixes by impact-to-effort ratio.
===REPORT===
[PASTE LIGHTHOUSE METRICS]
===END===

---

6. SEO & Metadata (Prompts 43–48)

43. The Static Metadata Builder

Generate a typed Metadata export for the page at [PATH]. Include: title (with template), description, keywords (only if I name them), openGraph (title, description, url, type, images, siteName), twitter (card: summary_large_image), alternates (canonical). The page is about [DESCRIPTION]. Output a single typed Metadata object that I can paste at the top of page.tsx.

44. The Dynamic generateMetadata

Write generateMetadata for the dynamic route at /[SLUG]. It fetches the resource by slug, then builds metadata from the fetched data. Requirements: (1) typed params (Promise in Next.js 15+), (2) cache the fetch so generateMetadata and the page do not double-fetch (use cache from React or unstable_cache), (3) fallback metadata if the resource is not found, (4) canonical URL based on slug.

45. The Sitemap Generator

Generate app/sitemap.ts that produces a Next.js sitemap covering: (1) static routes [LIST], (2) dynamic routes from [DATA SOURCE — e.g., all blog posts from Supabase]. Each entry must include url, lastModified, changeFrequency, priority. Use the MetadataRoute.Sitemap type. Cap at 50,000 entries — implement pagination via sitemap.xml index if the count could exceed that.

46. The Robots.ts Generator

Generate app/robots.ts that: (1) allows crawling of all public routes, (2) disallows [LIST — e.g., /admin, /api, /draft], (3) sets the sitemap URL to [URL]/sitemap.xml, (4) sets host to [URL]. Use the MetadataRoute.Robots type. If [STAGING] is true, disallow everything.

47. The OpenGraph Image Generator

Create a dynamic OG image at app/[ROUTE]/opengraph-image.tsx using ImageResponse. The image should: (1) be 1200x630, (2) include the page title prominently, (3) include [BRAND ELEMENT — e.g., logo, gradient background], (4) use only the limited subset of CSS supported by ImageResponse, (5) load a custom font from a public URL or embedded buffer. The title comes from [PARAMS / FETCH / STATIC].

48. The JSON-LD Structured Data

Add JSON-LD structured data to my [Article / Product / Review / FAQ / HowTo] page. Output: a typed JSON-LD object using schema.org vocabulary, then a small JsonLd component that injects it via a script tag with type="application/ld+json". Validate that the JSON is well-formed. Reference the official schema.org docs for [TYPE]. Do not invent properties — omit anything I have not supplied data for.

---

7. Testing & Quality (Prompts 49–54)

49. The Playwright E2E for a User Flow

Write a Playwright test covering this user flow: [DESCRIBE STEP BY STEP — e.g., sign in, navigate to /new, fill the form, submit, assert redirect, assert the new item appears]. Requirements: (1) use accessibility selectors (getByRole, getByLabel) over CSS, (2) one test per flow, (3) handle async waits with web-first assertions, (4) isolate test data with beforeEach setup. TypeScript.

50. The Vitest Test for a Server Action

Write Vitest unit tests for the Server Action below. Cover: (1) happy path with valid input, (2) validation failure for each required field, (3) auth failure when no session, (4) DB error path. Mock [DB CLIENT / AUTH HELPER] cleanly. The Server Action returns a discriminated union — type your assertions accordingly.
===ACTION===
[PASTE]
===END===

51. The React Testing Library Component Test

Write React Testing Library tests for the client component below. Cover: (1) initial render matches expected accessible structure, (2) user interaction [DESCRIBE] triggers expected state change, (3) loading and error states render correctly, (4) form submission calls the action with the right args. Use userEvent over fireEvent. Vitest as the runner.
===COMPONENT===
[PASTE]
===END===

52. The MSW Handler Setup

Set up Mock Service Worker handlers for the external APIs my Next.js app calls. APIs: [LIST]. For each: write a handler with realistic response shapes, support both success and failure modes, and place them in /mocks/handlers.ts. Then show the test-setup file that registers them. Include the [Vitest / Jest] config change needed to start the server.

53. The Accessibility Audit Prompt

Audit the component below for accessibility issues. Check: semantic HTML, ARIA roles, focus management, keyboard navigation, color contrast (if you can infer from the classes), screen reader announcements for dynamic content, form labels, and image alt text. For each issue: severity (BLOCKER/MAJOR/MINOR), the WCAG criterion it violates, and the smallest fix.
===COMPONENT===
[PASTE]
===END===

54. The TypeScript Strict Mode Migrator

I am migrating my Next.js project to TypeScript strict mode. tsconfig below. (1) Output the strict-mode tsconfig diff. (2) Then audit the file below and list every strict-mode violation that will appear, with the exact line and the recommended fix. Prefer narrowing over assertions, discriminated unions over optional chaining chains, satisfies over as.
===TSCONFIG===
[PASTE]
===FILE===
[PASTE]
===END===

---

8. Deployment & Production (Prompts 55–60)

55. The Vercel Deployment Config

Generate the Vercel deployment config for my Next.js app. Requirements: (1) the vercel.json (only if I need overrides — defaults are usually right), (2) the environment variables I must set (split into Preview / Production), (3) the recommended Node version, (4) build and install commands if non-default, (5) any Edge function configs for routes I name [LIST]. Flag anything that would prevent zero-config deployment.

56. The Self-Hosting Dockerfile

Generate a production Dockerfile for self-hosting my Next.js app. Requirements: (1) multi-stage build (deps, builder, runner), (2) Next.js standalone output (set in next.config.ts too), (3) non-root user, (4) Alpine base for size, (5) HEALTHCHECK against [URL], (6) PORT env respected, (7) only production deps in the final stage. Output the Dockerfile and the next.config.ts change.

57. The Environment Variable Audit

Audit my env var usage. Files: [PASTE .env.example, paste any file using process.env]. For each variable, output: (1) name, (2) where it is used, (3) whether it is server-only or NEXT_PUBLIC, (4) whether it is safe to expose to the client, (5) recommended default for local dev. Flag any NEXT_PUBLIC var holding a secret. Flag any server-only var read in a client component.

58. The Sentry Integration

Integrate Sentry into my Next.js [VERSION] app. Output: (1) the sentry.client.config.ts, sentry.server.config.ts, sentry.edge.config.ts, (2) the next.config.ts wrapper (withSentryConfig), (3) the instrumentation.ts file for the new App Router integration, (4) recommended sample rates for production (0.1 default, 1.0 for critical txs), (5) how to capture Server Action errors specifically.

59. The Production Logging Strategy

Design a logging strategy for my Next.js app on [Vercel / self-hosted]. Requirements: (1) structured JSON logs (not console.log strings), (2) request correlation ID through middleware, (3) Server Action and Route Handler errors logged with stack, (4) sensitive fields redacted (password, token, email when not needed), (5) log level per environment. Recommend a library and output the wrapper file.

60. The Pre-Deploy Checklist

I am about to deploy [APP DESCRIPTION] to production for the first time. Walk through a pre-deploy checklist covering: environment variables, build verification, security headers, robots.txt + sitemap, error tracking, analytics, custom domain + SSL, redirects from any legacy URLs, rate limiting on public APIs, database migration plan, rollback plan. For each item, output: status check command or file to verify, severity (must-have vs nice-to-have).

---

How to Chain These Into Multi-File Workflows

The real power of Opus 4.7 on Next.js work shows up when you chain prompts together inside an agentic loop. Five chains we run weekly:

• Feature build: Prompt 1 (Route Generator) → Prompt 9 (RSC Data Fetcher) → Prompt 10 (Server Action Form) → Prompt 49 (Playwright E2E). Whole feature, end to end, in a single Claude Code session.
• Performance regression hunt: Prompt 42 (Lighthouse Audit) → Prompt 35 (Bundle Analyzer) → Prompt 41 (Dynamic Import). Three calls, dramatic improvement, measurable in the next Lighthouse run.
• Server-side refactor: Prompt 14 (Client-to-Server Converter) → Prompt 15 ("use client" Boundary Optimizer) → Prompt 18 (Server Component Composition). The single biggest bundle-size win we got this year.
• Cache invalidation debugging: Prompt 26 (Cache Invalidation Debugger) → Prompt 21 (Cache Tag Strategy) → Prompt 16 (Server Action Mutation + Revalidate). Solves the most common production-only bug class in App Router apps.
• Production hardening: Prompt 57 (Env Var Audit) → Prompt 58 (Sentry Integration) → Prompt 59 (Logging Strategy) → Prompt 60 (Pre-Deploy Checklist). Run this before every major launch.