nextjs-fullstack-engineering
Skill0 starsChanged 13 days agoMITView on GitHub
Build, review, debug, or optimize Next.js public websites and authenticated SaaS applications, including rendering, routing, data fetching, caching, security, UX, and deployment. Use for meaningful Next.js engineering; skip non-Next.js React work, trivial copy edits, and standalone backend or database tasks.
In this repository17 other files it gives its agents.
- AGENTS.mdAGENTS.md
- api-design-engineeringSkill
- deep-readonly-system-auditSkill
- distributed-systems-reliabilitySkill
- engineering-research-intelligenceSkill
- flutter-app-engineeringSkill
- go-backend-engineeringSkill
- multi-tenant-access-controlSkill
- nodejs-backend-engineeringSkill
- postgresql-data-engineeringSkill
- react-vite-dashboard-engineeringSkill
- real-world-test-engineeringSkill
- redis-production-engineeringSkill
- repository-structure-engineeringSkill
- saas-security-engineeringSkill
- task-subagent-orchestrationSkill
- universal-database-engineeringSkill
The file
We split this skill into the rules it gives an agent
3 rules. About 0 are common, 1 is distinctive, and 2 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈1
Distinctive · estimate
This author's own choices. Worth a look.
2
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 12
Read applicable instructions, including managed Next.js guidance in AGENTS.md.
- Very specific: line 40
Before editing, state the root failure or required invariant and the simplest suitable approach.
- Distinctive: line 42
Place client interactivity where needed.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Next.js Full-Stack Engineering
Deliver the requested behavior with correct data ownership, useful UI, and evidence appropriate to its risk. Public content and private workflows can share a project without sharing one rendering or caching policy. Preserve sound architecture and keep changes proportional to the task.
Establish the project and route context
Read applicable instructions, including managed Next.js guidance in AGENTS.md. Locate the actual application directory and inspect the lockfile, resolved Next.js/React versions, package scripts, next.config.*, route tree, relevant consumers, authentication, data clients, and tests. Determine:
- The requested outcome: new feature, focused repair, review, migration, incident, or measured optimization.
- App Router, Pages Router, or both; JavaScript/TypeScript; runtime and deployment adapter/provider.
- The affected route's audience: anonymous public content, personalized public experience, authenticated workspace, or a combination.
- Data sensitivity, tenant/resource ownership, freshness and mutation requirements; current cache and state owners.
- The affected initial load, client navigation, background refresh, or mutation path, including relevant production evidence.
Resolve documentation from the app's installed Next.js package. When available, read only relevant files under node_modules/next/dist/docs/; honor an existing version-matched .next-docs index too. Otherwise consult matching official version documentation. Check current security advisories when the task involves exposure or upgrades. Do not apply canary behavior, current-site defaults, or a new cache model to an older project by assumption.
Read only the relevant reference
| Task or decision | Reference |
| Server/client boundaries, rendering strategy, App/Pages compatibility, project organization | Rendering and structure |
| Duplicate requests, fetching ownership, cache scope/freshness, invalidation | Data and caching |
| Sessions, tenant isolation, Server Actions, Route Handlers, mutation correctness | Security and mutations |
| Layouts, preserved state, remounts, loading/recovery, dashboard interactions | Navigation and UX |
| Public content, SEO, images/fonts/scripts, bundles, rendering performance | Public delivery and performance |
| Deployment constraints, production diagnosis, focused tests and verification | Production and verification |
| Current versions, authoritative sources, specialized Vercel skill selection | Source and compatibility register |
Vercel's specialized skills own supported development-loop, cache-adoption, partial-prefetching, and optimization workflows. Use an installed compatible workflow when it fits; read its prerequisites and preserve the user's scope. Do not recreate its recipes, install optional tooling automatically, or require a framework migration for ordinary work. If unavailable, use relevant official docs and existing project tools, stating what could not be verified.
This skill owns Next.js decisions across public sites and dashboards. Existing API, Node.js, PostgreSQL, and UI skills can help with genuinely separate specialist work; none is required. Do not apply Vite configuration or assume a browser-only architecture merely because dashboard components use React.
Make a focused engineering change
Before editing, state the root failure or required invariant and the simplest suitable approach. Trace the affected data and interaction across browser, Next.js, backend, and cache boundaries. Reuse existing components, clients, auth, validation, state libraries, and conventions. Avoid parallel systems or a universal folder tree.
Place client interactivity where needed; retain server-only secrets and authorization. A layout redirect or hidden button cannot protect an endpoint. Cache scope must preserve user/tenant isolation and revocation requirements. Keep render paths free of business mutations: prefetching and repeated renders must be safe.
For performance work, establish which request, render, or dependency is expensive. Reduce redundant work without losing freshness, input, navigation state, or authorization. Do not disable Strict Mode, blanket-memoize, add unscoped shared caching, or add proxies/infrastructure to conceal a symptom.
Verify and finish
Run existing focused checks suited to the change. Browser/network evidence is necessary for claims about navigation, request counts, hydration, or interactions; production-mode checks matter when development behavior differs. Select realistic failure cases from the actual flow. Do not impose an exhaustive suite, agent evaluations, or benchmarks on every task.
Review the diff for compatibility, cache/data exposure, broken state transitions, duplicate systems, and unrelated edits. Report changes, checks actually executed, observed outcomes, and genuine limitations. A successful build establishes build compatibility, not correct authorization, browser behavior, or production performance.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

