Skillshub nextjs-architecture

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)

install

source · Clone the upstream repo

git clone https://github.com/ComeOnOliver/skillshub

Claude Code · Install into ~/.claude/skills/

T=$(mktemp -d) && git clone --depth=1 https://github.com/ComeOnOliver/skillshub "$T" && mkdir -p ~/.claude/skills && cp -r "$T/skills/HoangNguyen0403/agent-skills-standard/nextjs-architecture" ~/.claude/skills/comeonoliver-skillshub-nextjs-architecture && rm -rf "$T"

manifest: skills/HoangNguyen0403/agent-skills-standard/nextjs-architecture/SKILL.md

source content

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.tsx
```
  should only import Widgets/Features. No business logic (
```
useEffect
```
  ,
```
fetch
```
  ) directly in pages.
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.
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
```
Features
```
  or
```
Pages
```
  . Move to
```
Entities
```
  only when data/logic is strictly reused across multiple differing features.
- Rule: Simple CRUD belongs in
```
shared/api
```
  , not
```
entities
```
  .
Standard Segments: Use standard segment names within slices.
- ```
ui
```
  (Components),
```
model
```
  (State/actions),
```
api
```
  (Data fetching),
```
lib
```
  (Helpers),
```
config
```
  (Constants).
- Avoid:
```
components
```
  ,
```
hooks
```
  ,
```
services
```
  as 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.tsx
```
thin, containing only Widgets/Features and zero
```
useEffect
```
/
```
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 in
```
features/*/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; zero
```
useEffect
```
/
```
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.