Web Development · Front-end
The Best Prompt for Planning a Next.js Feature
The best prompt for Next.js makes the model settle the App Router decisions that are hard to change later: the route tree, which components run on the server, how each data read is cached and where authorization is enforced. This prompt asks for that plan first and stops for your approval, then implements file by file against the version you named. It also tells the model to flag anything whose behavior depends on the Next.js version instead of guessing.
Next.js App Router Feature Prompt
A plan-then-build prompt for App Router work: routes, server and client boundaries, caching, mutations and authorization, approved before any code.
- Works with
- ChatGPT, Claude, Gemini, Cursor
- Difficulty
- Advanced
- Complexity
- Conversation
- Variables
- 6
- Version
- 1.0
Customize this prompt
Fill in what you know. Anything left blank stays as a [bracketed placeholder]. Nothing you type leaves your browser.
6 variables · fields marked * matter most
You are a senior engineer who has shipped production apps on the Next.js App Router. Help me plan, then build, one feature. ## Feature [Feature] ## Project facts - Next.js version: [Next.js version] - Data layer: [Data layer] - Authentication and who may do what: [Authentication and permissions] - How fresh the data must be: [Data freshness] - Existing structure and conventions: [Existing structure and conventions] ## Stage 1: plan only Write no implementation code in this stage. Produce: A. Route map. A file tree of every file you would add or change under app/, with one line on what each is for (page, layout, loading, error, not-found, route handler, server action). B. Server and client boundary. A table with columns: component, server or client, reason. Default to server. A component is client only if it needs state, effects, event handlers or browser APIs. Place the boundary as low in the tree as possible and note what is passed across it. C. Data reads. For each read: where it runs, whether its result is cached, what invalidates it, and how that satisfies the freshness requirement. Caching defaults differ between Next.js versions, so state the behavior you are relying on for the version above and mark anything you are not certain of [VERIFY]. D. Mutations. For each write: server action or route handler, input validation, the authorization check and where it runs, what is revalidated afterward, and what the user sees while it is pending and when it fails. E. Risks. Anything that could expose data to the wrong user, send secrets or oversized payloads to the client, or cause a request waterfall. F. Questions for me, at most five. Then stop and wait for my reply. ## Stage 2: after I approve Implement the plan one file at a time: complete files with their paths, in dependency order. If you need to depart from the approved plan, say so before the file in question. ## Rules for both stages - Use only APIs that exist in the stated version. If unsure, say so; do not guess a signature. - Never rely on client-side checks or hidden UI for authorization. - Do not add packages or invent database tables, columns or environment variables. Ask instead.
Use it when you are
- Adding an authenticated dashboard section with its own layouts and data loading
- Deciding between server actions and route handlers for a set of mutations
- Working out a caching and revalidation approach for content with mixed freshness needs
- Migrating a feature from the Pages Router and wanting a file-level plan first
Why this prompt works
The hard-to-reverse choices come first
In the App Router, the route tree, the server and client split and the caching approach shape every file that follows. Changing them after implementation means rewriting, not editing. Splitting the work into an approved plan and a build stage puts your review at the point where a correction costs one message.
Client components have to earn the label
The boundary table asks for a reason beside every client component and sets server as the default. That counters the habit of marking a whole page as client because one button needs a handler, and it produces a record you can check against what each component actually does.
Version-dependent behavior is flagged, not assumed
A model's knowledge of Next.js blends several major versions, and caching defaults are one of the places they differ. Naming the version, requiring the model to state the behavior it relies on and marking uncertain points [VERIFY] gives you a short list to confirm in the official documentation.
Authorization is a line item for every write
Server actions are reachable endpoints, so each one needs its own check. Requiring the check and its location per mutation, and banning reliance on hidden UI, makes a missing check visible in the plan as an empty cell instead of leaving it to be found in production.
How to use it
- Look up your exact Next.js version in package.json and enter it. Do not write "latest".
- State freshness per kind of data. "Always current" and "a few minutes stale is fine" lead to different caching plans.
- Describe roles and permissions in plain sentences, including who must not see what.
- Send the prompt and review sections B, C and D of the plan closely. Check every [VERIFY] item against the Next.js documentation for your version.
- Answer the model's questions, correct the plan, and only then tell it to begin Stage 2.
- Build and run after each group of files instead of waiting for the full implementation.
AI model compatibility
| Model | Status | Notes |
|---|---|---|
| ChatGPT | Expected to work | No model-specific adjustment needed. Paste the prompt as written. |
| Claude | Expected to work | For long schemas or existing files, wrap each in its own XML-style tag below the project facts, as Anthropic's prompting guidance suggests, so the plan can refer to them by name. |
| Gemini | Expected to work | Keep the lettered plan sections as written. Google's prompting guidance favors explicit, ordered instructions, and the letters make it easy to ask for a revision of one section. |
| Cursor | Expected to work | Run Stage 1 as a question rather than an edit so no files change, and point the existing-structure field at your app directory and data-access files instead of describing them. |
“Expected to work” means the prompt uses plain, model-independent structure and has been reviewed for that — not that it has been run on that model. A model is marked Tested only when a test record is published below.
Worked example
Scenario: An illustrative case: a B2B SaaS app adding a members area to team settings.
You are a senior engineer who has shipped production apps on the Next.js App Router. Help me plan, then build, one feature. ## Feature A team settings area at /settings/members where admins see all members, invite by email, change a member's role and remove a member. Regular members can view the list but not change it. ## Project facts - Next.js version: 15.3 - Data layer: PostgreSQL via Drizzle; query functions live in src/db/queries - Authentication and who may do what: Auth.js session cookie. Roles: owner, admin, member. Only owner and admin can invite, change roles or remove. Nobody can remove the owner. - How fresh the data must be: Member list must reflect changes immediately after any mutation; pending invites can be up to a minute old - Existing structure and conventions: app/(dashboard)/settings/layout.tsx already exists with a sidebar. Server actions go in actions.ts beside the page. Forms use plain form elements with useActionState. ## Stage 1: plan only Write no implementation code in this stage. Produce: A. Route map. A file tree of every file you would add or change under app/, with one line on what each is for (page, layout, loading, error, not-found, route handler, server action). B. Server and client boundary. A table with columns: component, server or client, reason. Default to server. A component is client only if it needs state, effects, event handlers or browser APIs. Place the boundary as low in the tree as possible and note what is passed across it. C. Data reads. For each read: where it runs, whether its result is cached, what invalidates it, and how that satisfies the freshness requirement. Caching defaults differ between Next.js versions, so state the behavior you are relying on for the version above and mark anything you are not certain of [VERIFY]. D. Mutations. For each write: server action or route handler, input validation, the authorization check and where it runs, what is revalidated afterward, and what the user sees while it is pending and when it fails. E. Risks. Anything that could expose data to the wrong user, send secrets or oversized payloads to the client, or cause a request waterfall. F. Questions for me, at most five. Then stop and wait for my reply. ## Stage 2: after I approve Implement the plan one file at a time: complete files with their paths, in dependency order. If you need to depart from the approved plan, say so before the file in question. ## Rules for both stages - Use only APIs that exist in the stated version. If unsure, say so; do not guess a signature. - Never rely on client-side checks or hidden UI for authorization. - Do not add packages or invent database tables, columns or environment variables. Ask instead.
What a good response should contain
- A file tree under app/(dashboard)/settings/members that includes loading and error files, not only page.tsx
- A boundary table where the member list is a server component and only the role select, invite form and remove button are client components
- A statement of how the member list read behaves in the stated version, with at least one [VERIFY] marker where the model is unsure
- Each of the three mutations listed with validation, a server-side role check, the owner-removal rule and what is revalidated
- Questions about things it cannot know, such as how invites are delivered and what happens to an invited email that already has an account
This is an illustrative scenario showing how to fill in the prompt and what to look for. It is not a recorded model output. Recorded outputs will be published here once this prompt has a test record.
Testing and editorial review
Status: Untested. Reviewed for structure and clarity by the editorial team. No recorded model test yet.
No test record has been published for this prompt yet. When it is tested, this section will show the model and version, the date, the inputs, the actual output and notes against our seven-point rubric. We do not publish numerical scores.
| Author | TheBestPromptFor Editorial Team — The editorial team writes, reviews and maintains the prompts and guides on TheBestPromptFor. Prompts are drafted with AI assistance and reviewed against published editorial standards. |
|---|---|
| Published | November 15, 2026 |
| Last reviewed | November 15, 2026 |
| Last tested | Not yet tested |
| Version history |
|
Limitations and things to check
- The model may describe APIs or defaults from a different Next.js version than yours. Treat every [VERIFY] item, and anything about caching, as something to confirm.
- A plan that looks secure is not a security review. Test each mutation as a user who should be refused.
- The model cannot see runtime behavior such as actual cache hits, waterfalls or bundle size. Measure those in your app.
- Hosting platforms differ in how they handle caching and revalidation; the plan assumes the framework's documented behavior.
Alternative prompts
Web Development
React Component Prompt
Makes the model plan components, state and effects before coding, then deliver complete files, tests and a list of what it assumed.
- ChatGPT
- Claude
- Gemini
- Cursor
Web Development
Technical Specification Prompt
Interviews you briefly, then drafts a reviewable spec: goals and non-goals, design, alternatives, rollout, risks and open questions.
- ChatGPT
- Claude
- Gemini
Web Development
REST API Design Prompt
Turns a description of your domain and consumers into a consistent REST contract: resources, endpoints, errors, pagination and open decisions.
- ChatGPT
- Claude
- Gemini
Web Development
Core Web Vitals Diagnosis Prompt
Works from your own field and lab data to rank likely causes of poor LCP, INP or CLS, with a way to confirm each one before you change code.
- ChatGPT
- Claude
- Gemini
- Cursor
Related resources
Technical guide
Prompt Chaining: Breaking a Task Into Linked Prompts
How to split a large task into a sequence of focused prompts, design the handoffs between them, and debug the chain when a step goes wrong.
Guide
How to Improve AI Responses
A diagnostic approach to weak AI answers: name the fault, trace it to the gap in your prompt, then follow up precisely or rewrite and start again.
Frequently asked questions
Why does the prompt stop after the plan?
Because the plan is where your knowledge matters most. You know which data is sensitive, which routes already exist and how fresh things must be. Approving the route map, boundaries and caching before code is written avoids a full rewrite when one of those turns out to be wrong.
Can I use this with the Pages Router?
No. The plan sections assume App Router concepts such as layouts, server components and server actions. For a Pages Router project, use the technical spec prompt to plan and the React component prompt to build the interactive parts.
What if I don't know how fresh my data needs to be?
Say what would go wrong if a user saw data that was a minute old, or an hour old. That consequence is enough for the model to propose a requirement, which it should then list among its questions for you to confirm.
Sources and references
- Next.js documentation — Vercel
- React documentation: Learn — React
- Prompt design strategies — Google AI for Developers
Was this prompt useful?
No account needed. Do not include personal information.