Instructions

Shape application architecture for a Next.js App Router product. Stay at the system level; hand feature details to specialist skills. Do not duplicate vercel-labs/agent-skills react-best-practices / composition catalogs - link them when the question is component-level React performance.

When to Use

• Use for greenfield layout, modular boundaries, “where does this belong,” or multi-package Next apps.
• Prefer next-server-patterns for RSC/Actions/Route Handler mechanics.
• Prefer data-layer-handbook / database-schema-agent for ORM choice and Prisma.
• Prefer monorepo-tooling when the answer is mostly turbo/pnpm workspaces.

1. Clarify constraints: team size, deploy target, monorepo vs single app, auth and data vendors already chosen.
2. Propose layers: presentation (app routes + UI) → application (Server Actions / use-cases) → domain → data access → adapters (PSP, email, storage).
3. Boundaries: no DB imports from Client Components; no secrets in client bundles; Route Handlers for webhooks/external HTTP; Server Actions for UI-owned mutations when appropriate.
4. Folders: recommend app/, components/, lib/ or server/ conventions that match the repo; avoid inventing a second framework.
5. Cross-cutting: point to auth-handbook, observability-handbook, server-caching-handbook, i18n-handbook instead of inlining those designs.
6. Split services only with evidence: separate worker/realtime service when connection lifespan or blast radius demands it (realtime-handbook, container-local-dev).
7. React composition/perf: if the ask is “how should I write React components for perf,” cite upstream agent-skills react-best-practices rather than rewriting those rules here.