Claude/ChatGPT Prompt to Master Next.js 15 Server Component Data Fetching

What this prompt does

This prompt asks the AI to build the data-fetching layer for a feature you name in Next.js 15 with the App Router and Server Components, returning a file tree plus full code. You set [example_feature], the [data_source], the [rendering_target], and the [freshness] need. The AI then produces async Server Components with explicit fetch cache and tags, parallel fetching to avoid waterfalls, Suspense boundaries with a loading.tsx skeleton, revalidation matching your freshness, a Server Action for one mutation, and notes on server-vs-client boundaries.

The structure works because the App Router's caching defaults are where most people trip. By forcing explicit cache tags and a revalidation strategy tied to [freshness], the prompt makes the caching behaviour deliberate instead of accidental. [data_source] shapes how fetches are written (an internal REST API differs from a database client), [rendering_target] decides how much is static versus streamed, and [freshness] drives whether you lean on time-based revalidate, on-demand revalidateTag, or both.

When to use it

• You're starting an App Router feature and want caching and streaming decided up front.
• You keep fighting "why is this data stale" caused by mismatched cache tags.
• You need parallel data fetching to kill request waterfalls on a page.
• You want Suspense boundaries and a sensible loading skeleton wired correctly.
• You're adding a mutation and need revalidatePath/revalidateTag after the write.
• You're unsure where 'use client' is actually required versus server-only code.

Example output

You get the file structure first, then each file in full: async Server Components fetching from [data_source] with explicit cache settings and tags; independent requests fetched in parallel to avoid waterfalls; Suspense boundaries with streaming and a loading.tsx skeleton; revalidation matching [freshness] using time-based revalidate plus on-demand revalidateTag; a Server Action for one mutation that calls revalidatePath or revalidateTag after writing; and notes on what runs on the server versus client and where 'use client' is genuinely needed.

Pro tips

• Get [freshness] right early — mismatched cache tags between fetch and revalidation are the usual cause of stale data, and deliverable 4 hinges on this value.
• Set [data_source] to your real source; an internal REST API and a direct database client produce different fetch and caching code.
• Use [rendering_target] to express how much should be static versus streamed, so the AI places Suspense boundaries where they actually help.
• Keep the parallel-fetch deliverable honest — only mark requests parallel when they're truly independent, or you'll introduce subtle ordering bugs.
• Confirm the Server Action revalidates the exact tag your list reads, otherwise a write succeeds but the UI shows old data.
• Ask a follow-up for error boundaries; the base prompt focuses on the happy path, so adding error.tsx handling rounds it out.