Nextjs architecture
Skill ComeOnOliver/skillshub/skills/HoangNguyen0403/agent-skills-standard/nextjs-architecture
🧠The right skill, one API call. AI agent skills registry with token-efficient skill resolution. 5,000+ skills from 500+ top repos.
npx -y skills add ComeOnOliver/skillshub --skill nextjs-architectureAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
What its author says it does
Copied from the file, not written here
Scalable project structure using Feature-Sliced Design (FSD). Use when structuring a Next.js project with Feature-Sliced Design architecture. (triggers: src/features/**, src/entities/**, src/widgets/**, FSD, Feature Sliced Design, slices, segments)
SKILL.md
3.5 KB, 838 tokens by cl100k_base, as published. Nobody here has run it
Architecture (Feature-Sliced Design)
Priority: P2 (MEDIUM)
Adopt Feature-Sliced Design (FSD) for scalable applications. Warning: FSD introduces boilerplate. Use it only if the project is expected to grow significantly (e.g., 20+ features). For smaller projects, a simple module-based structure is preferred.
Strategy
- RSC Boundaries: Enforce strict serialization rules for props passed from Server to Client. See RSC Boundaries & Serialization.
- App Layer is Thin: The
app/directory (App Router) is only for Routing.- Rule:
page.tsxshould only import Widgets/Features. No business logic (useEffect,fetch) directly in pages.
- Rule:
- Slices over Types: Group code by Business Domain (User, Product, Cart), not by File Type (Components, Hooks, Utils).
- Bad:
src/components/LoginForm.tsx,src/hooks/useLogin.ts - Good:
src/features/auth/login/containing both.
- Bad:
- Layer Hierarchy: Code can only import from layers below it.
App->Widgets->Features->Entities->Shared.
- Avoid Excessive Entities: Do not preemptively create Entities.
- Rule: Start logic in
FeaturesorPages. Move toEntitiesonly when data/logic is strictly reused across multiple differing features. - Rule: Simple CRUD belongs in
shared/api, notentities.
- Rule: Start logic in
- Standard Segments: Use standard segment names within slices.
ui(Components),model(State/actions),api(Data fetching),lib(Helpers),config(Constants).- Avoid:
components,hooks,servicesas segment names.
Structure Reference
For the specific directory layout and layer definitions, see the reference documentation.
Architecture Checklist (Mandatory)
-
Layer Imports: Does any layer import from a layer ABOVE it? (App > Widgets > Features > Entities > Shared)
-
Page Logic: Is
page.tsxthin, containing only Widgets/Features and zerouseEffect/fetch? -
RSC Boundaries: Are Server Components isolated from Client Components with proper 'use client' boundaries?
-
Public API: Is all access to a slice performed via the top-level
index.ts(public API)? -
Cross-Slice: Do slices within the same layer (e.g., two features) import from each other directly? (Prohibited)
-
Server Actions: Place them in the
model/folder of a Feature (e.g.,features/auth/model/actions.ts). -
Data Access (DAL): Place logic in the
model/folder of an Entity (e.g.,entities/user/model/dal.ts). -
UI Components: Base UI (shadcn) belongs in
shared/ui. Feature-specific UI belongs infeatures/*/ui.
Anti-Patterns
- No cross-slice imports: Slices in the same layer must not import from each other directly.
- No business logic in
page.tsx: Pages import Widgets/Features only; zerouseEffect/fetch. - No file-type folders: Group by domain (
features/auth/), not type (components/,hooks/). - No premature Entity creation: Start in Features; move to Entities only on strict reuse.
What ships with it
Read from the repository
Just SKILL.md. No reference files, no scripts.