Non-negotiable rules:
- Read
references/stack.md first.
- Read the repository's
AGENTS.md, CLAUDE.md, and closest module map when present. They define
the real route families, localization, design/theme, auth, transport, and test contracts.
- Read the application
package.json, resolved lockfile, and the installed version-matched Next.js
docs under that package's node_modules/next/dist/docs/ before applying version-specific guidance.
- Follow the installed version unless the user explicitly requests an upgrade. Never upgrade,
downgrade, or switch release channels during unrelated work.
- Then load only the references needed for the actual task.
- Keep user-visible text translated and all backend traffic in the project's shared API transport.
- Keep the heavy Next.js guidance in
references/, not inline here.
nextjs
Inputs
$request: The Next.js page, component, routing, caching, or testing task
Goal
Route Next.js work through the project's App Router conventions so implementation follows the established patterns for data access, metadata, localization, and rendering boundaries.
Step 0: Read the stack contract
Always start with:
That establishes the locked decisions for runtime, config, and project-wide Next.js patterns.
For a new application, version recommendation, or framework upgrade, also read:
Success criteria: The project’s Next.js architecture assumptions are explicit before editing.
Step 1: Load only the relevant references
Use the routing table to pick reference files that match the task. Do not bulk-load the full reference tree.
| Task |
Read |
| New application, version choice, Next.js 15 to 16 upgrade |
references/upgrading.md |
| Folder layout, file conventions, project structure |
references/folder-structure.md |
| Route groups, dynamic routes, parallel/intercepting routes |
references/routing.md |
| Creating or editing a page or layout |
references/page-checklist.md |
| Component structure, client/server boundaries |
references/component-anatomy.md |
| Data fetching, API client, fetch wrappers |
references/api-client-pattern.md |
| Polling, pagination, autosave, stale async responses |
references/client-async-state.md |
| Server actions, mutations, revalidation |
references/server-actions.md |
| Caching, ISR, on-demand revalidation |
references/caching-strategy.md |
| Translations, locale routing, message files |
references/i18n-conventions.md |
| Error boundaries, error.tsx, not-found.tsx |
references/error-handling.md |
| Structured logging, log levels |
references/logging.md |
| Analytics, event tracking, consent |
references/tracking.md |
| Authentication, middleware, session |
references/auth.md |
| Security headers, CSP, CSRF, rate limiting |
references/security.md |
| SEO, metadata, Open Graph, sitemap |
references/seo.md |
| Agent-ready public pages, trust anchors, 404s, llms.txt |
references/agent-readiness.md |
| Accessibility, ARIA, keyboard navigation |
references/accessibility.md |
| Unit tests, component tests |
references/testing-unit.md |
| E2E tests, Playwright |
references/testing-e2e.md |
| Machine-readable output, JSON-LD, structured data |
references/machine-readable.md |
Multiple tasks? Read multiple files. The references are self-contained.
Success criteria: The active context only contains the task-relevant Next.js conventions.
Step 2: Implement with the core Next.js guardrails
Keep these rules active:
- async request-bound APIs are awaited
- data access uses the project API client, not ad hoc backend fetches or ORM calls
- RSC/server calls use the project's server domain modules; approved interactive clients use its
browser domain modules; both converge on the shared transport
- visible strings go through the localization layer
- pages and layouts stay server-first unless a leaf component truly needs client mode
- metadata and SEO requirements stay attached to page work
- authentication and authorization come from the verified backend session, never browser-controlled
role or workspace headers
Success criteria: The change fits the project’s App Router architecture instead of generic framework defaults.
Step 3: Verify the affected surface
Run the repository's own scripts at the level that can prove the behavior:
- lint,
next typegen, typecheck, and focused unit/component tests
- a built production Next.js server for HTTP status, headers, raw HTML, negotiation, redirects, and
browser behavior
- the canonical integrated Compose stack when Laravel session, CSRF, queues, billing, downloads,
webhooks, or another backend boundary is involved
Direct handler invocation cannot prove production HTTP behavior. A frontend run with Laravel mocked
is not a full-stack test.
Success criteria: The changed Next.js surface still behaves correctly.
Guardrails
- Do not inline the whole Next.js handbook in
SKILL.md.
- Do not skip
references/stack.md.
- Do not hardcode user-facing strings when i18n is required.
- Do not bypass the project’s API-client and caching conventions.
- Do not replace or relocate the project's authentication/session authority during unrelated work.
- Do not add or remove theme support contrary to the project's locked design contract.
- Do not apply Next.js 16-only APIs to an older project unless the task includes the upgrade.
- Do not downgrade a project that already declares or resolves Next.js 16.3.x.
- Do not recommend
next@canary or another prerelease unless the user explicitly opts into that
release channel.
- Do not add
disable-model-invocation; this is a normal domain skill.
For a public-page task, also load agent-readiness.md, page-checklist.md, seo.md,
machine-readable.md, and testing-e2e.md. Do not call it complete until the applicable raw-HTML, canonical identity,
structured-data, trust-page, HTML/Markdown 404, and live HTTP checks pass. Report external search
engine and brand-discoverability work separately from code completion.
When To Load References
references/stack.md
Always.
references/upgrading.md
New applications, version choices, and framework upgrades.
then only the task-relevant files under references/
Output Contract
Report:
- the declared and resolved Next.js version and which installed documentation was consulted
- which Next.js references were loaded
- the repository architecture or project profile followed
- the change made
- the verification run at each applicable test level
- remaining deployment, live-endpoint, integration, or external-discoverability work
1---2name: nextjs3description: Build or review a Next.js App Router surface against the project's installed framework version and established architecture. Covers pages, layouts, async request APIs, server and browser API clients, authentication, client concurrency, Route Handlers, metadata, i18n, accessibility, machine-readable content, and layered testing. Use when a task touches Next.js and must preserve project-specific decisions such as the resolved framework version, backend session protocol, canonical domain, and locked visual theme.4---5
6<EXTREMELY-IMPORTANT>
7This skill is a routing shell over the Next.js reference set, not the full framework manual.
8
9Non-negotiable rules:
101. Read `references/stack.md` first.
112. Read the repository's `AGENTS.md`, `CLAUDE.md`, and closest module map when present. They define
12 the real route families, localization, design/theme, auth, transport, and test contracts.
133. Read the application `package.json`, resolved lockfile, and the installed version-matched Next.js
14 docs under that package's `node_modules/next/dist/docs/` before applying version-specific guidance.
154. Follow the installed version unless the user explicitly requests an upgrade. Never upgrade,
16 downgrade, or switch release channels during unrelated work.
175. Then load only the references needed for the actual task.
186. Keep user-visible text translated and all backend traffic in the project's shared API transport.
197. Keep the heavy Next.js guidance in `references/`, not inline here.
20</EXTREMELY-IMPORTANT>
21
22# nextjs
23
24## Inputs
25
26- `$request`: The Next.js page, component, routing, caching, or testing task
27
28## Goal
29
30Route Next.js work through the project's App Router conventions so implementation follows the established patterns for data access, metadata, localization, and rendering boundaries.
31
32## Step 0: Read the stack contract
33
34Always start with:
35
36- `references/stack.md`
37
38That establishes the locked decisions for runtime, config, and project-wide Next.js patterns.
39
40For a new application, version recommendation, or framework upgrade, also read:
41
42- `references/upgrading.md`
43
44**Success criteria**: The project’s Next.js architecture assumptions are explicit before editing.
45
46## Step 1: Load only the relevant references
47
48Use the routing table to pick reference files that match the task. Do not bulk-load the full reference tree.
49
50| Task | Read |
51|------|------|
52| New application, version choice, Next.js 15 to 16 upgrade | `references/upgrading.md` |
53| Folder layout, file conventions, project structure | `references/folder-structure.md` |
54| Route groups, dynamic routes, parallel/intercepting routes | `references/routing.md` |
55| Creating or editing a page or layout | `references/page-checklist.md` |
56| Component structure, client/server boundaries | `references/component-anatomy.md` |
57| Data fetching, API client, fetch wrappers | `references/api-client-pattern.md` |
58| Polling, pagination, autosave, stale async responses | `references/client-async-state.md` |
59| Server actions, mutations, revalidation | `references/server-actions.md` |
60| Caching, ISR, on-demand revalidation | `references/caching-strategy.md` |
61| Translations, locale routing, message files | `references/i18n-conventions.md` |
62| Error boundaries, error.tsx, not-found.tsx | `references/error-handling.md` |
63| Structured logging, log levels | `references/logging.md` |
64| Analytics, event tracking, consent | `references/tracking.md` |
65| Authentication, middleware, session | `references/auth.md` |
66| Security headers, CSP, CSRF, rate limiting | `references/security.md` |
67| SEO, metadata, Open Graph, sitemap | `references/seo.md` |
68| Agent-ready public pages, trust anchors, 404s, llms.txt | `references/agent-readiness.md` |
69| Accessibility, ARIA, keyboard navigation | `references/accessibility.md` |
70| Unit tests, component tests | `references/testing-unit.md` |
71| E2E tests, Playwright | `references/testing-e2e.md` |
72| Machine-readable output, JSON-LD, structured data | `references/machine-readable.md` |
73
74Multiple tasks? Read multiple files. The references are self-contained.
75
76**Success criteria**: The active context only contains the task-relevant Next.js conventions.
77
78## Step 2: Implement with the core Next.js guardrails
79
80Keep these rules active:
81
82- async request-bound APIs are awaited
83- data access uses the project API client, not ad hoc backend fetches or ORM calls
84- RSC/server calls use the project's server domain modules; approved interactive clients use its
85 browser domain modules; both converge on the shared transport
86- visible strings go through the localization layer
87- pages and layouts stay server-first unless a leaf component truly needs client mode
88- metadata and SEO requirements stay attached to page work
89- authentication and authorization come from the verified backend session, never browser-controlled
90 role or workspace headers
91
92**Success criteria**: The change fits the project’s App Router architecture instead of generic framework defaults.
93
94## Step 3: Verify the affected surface
95
96Run the repository's own scripts at the level that can prove the behavior:
97
98- lint, `next typegen`, typecheck, and focused unit/component tests
99- a built production Next.js server for HTTP status, headers, raw HTML, negotiation, redirects, and
100 browser behavior
101- the canonical integrated Compose stack when Laravel session, CSRF, queues, billing, downloads,
102 webhooks, or another backend boundary is involved
103
104Direct handler invocation cannot prove production HTTP behavior. A frontend run with Laravel mocked
105is not a full-stack test.
106
107**Success criteria**: The changed Next.js surface still behaves correctly.
108
109## Guardrails
110
111- Do not inline the whole Next.js handbook in `SKILL.md`.
112- Do not skip `references/stack.md`.
113- Do not hardcode user-facing strings when i18n is required.
114- Do not bypass the project’s API-client and caching conventions.
115- Do not replace or relocate the project's authentication/session authority during unrelated work.
116- Do not add or remove theme support contrary to the project's locked design contract.
117- Do not apply Next.js 16-only APIs to an older project unless the task includes the upgrade.
118- Do not downgrade a project that already declares or resolves Next.js 16.3.x.
119- Do not recommend `next@canary` or another prerelease unless the user explicitly opts into that
120 release channel.
121- Do not add `disable-model-invocation`; this is a normal domain skill.
122
123For a public-page task, also load `agent-readiness.md`, `page-checklist.md`, `seo.md`,
124`machine-readable.md`, and `testing-e2e.md`. Do not call it complete until the applicable raw-HTML, canonical identity,
125structured-data, trust-page, HTML/Markdown 404, and live HTTP checks pass. Report external search
126engine and brand-discoverability work separately from code completion.
127
128## When To Load References
129
130- `references/stack.md`
131 Always.
132
133- `references/upgrading.md`
134 New applications, version choices, and framework upgrades.
135
136- then only the task-relevant files under `references/`
137
138## Output Contract
139
140Report:
141
1421. the declared and resolved Next.js version and which installed documentation was consulted
1432. which Next.js references were loaded
1443. the repository architecture or project profile followed
1454. the change made
1465. the verification run at each applicable test level
1476. remaining deployment, live-endpoint, integration, or external-discoverability work