feature-slicing

Proactively apply when creating new features/components/pages or setting up frontend project structure. Triggers on FSD, feature slicing, frontend architecture, layer structure, module boundaries, scalable frontend, slice organization. Use when restructuring React/Next.js/Vue/Remix projects, organizing frontend code, fixing import violations, or migrating legacy codebases. Feature-Sliced Design (FSD) architecture for frontend projects.

Safety Notice

This listing is imported from skills.sh public index metadata. Review upstream SKILL.md and repository scripts before running.

Copy this and send it to your AI assistant to learn

Install skill "feature-slicing" with this command: npx skills add ccheney/robust-skills/ccheney-robust-skills-feature-slicing

Feature-Sliced Design Architecture

Frontend architecture methodology with strict layer hierarchy and import rules for scalable, maintainable applications. FSD organizes code by business domain rather than technical role.

Official Docs: feature-sliced.design | GitHub: feature-sliced


THE IMPORT RULE (Critical)

Modules can ONLY import from layers strictly below them. Never sideways or upward.

app → pages → widgets → features → entities → shared
 ↓      ↓        ↓          ↓          ↓         ✓
 ✓      ✓        ✓          ✓          ✓      (external only)
ViolationExampleFix
Cross-slice (same layer)features/authfeatures/userExtract to entities/ or shared/
Upward importentities/userfeatures/authMove shared code down
Shared importing upshared/entities/Shared has NO internal deps

Exception: app/ and shared/ have no slices, so internal cross-imports are allowed within them.


Layer Hierarchy

LayerPurposeHas SlicesRequired
app/Initialization, routing, providers, global stylesNoYes
pages/Route-based screens (one slice per route)YesYes
widgets/Complex reusable UI blocks (header, sidebar)YesNo
features/User interactions with business value (login, checkout)YesNo
entities/Business domain models (user, product, order)YesNo
shared/Project-agnostic infrastructure (UI kit, API client, utils)NoYes

Minimal setup: app/, pages/, shared/ — add other layers as complexity grows.


Quick Decision Trees

"Where does this code go?"

Code Placement:
├─ App-wide config, providers, routing    → app/
├─ Full page / route component            → pages/
├─ Complex reusable UI block              → widgets/
├─ User action with business value        → features/
├─ Business domain object (data model)    → entities/
└─ Reusable, domain-agnostic code         → shared/

"Feature or Entity?"

Entity (noun)Feature (verb)
user — user data modelauth — login/logout actions
product — product infoadd-to-cart — adding to cart
comment — comment datawrite-comment — creating comments
order — order recordcheckout — completing purchase

Rule: Entities represent THINGS with identity. Features represent ACTIONS with side effects.

"Which segment?"

Segments (within a slice):
├─ ui/      → React components, styles
├─ api/     → Backend calls, data fetching, DTOs
├─ model/   → Types, schemas, stores, business logic
├─ lib/     → Slice-specific utilities
└─ config/  → Feature flags, constants

Naming: Use purpose-driven names (api/, model/) not essence-based (hooks/, types/).


Directory Structure

src/
├── app/                    # App layer (no slices)
│   ├── providers/          # React context, QueryClient, theme
│   ├── routes/             # Router configuration
│   └── styles/             # Global CSS, theme tokens
├── pages/                  # Page slices
│   └── {page-name}/
│       ├── ui/             # Page components
│       ├── api/            # Loaders, server actions
│       ├── model/          # Page-specific state
│       └── index.ts        # Public API
├── widgets/                # Widget slices
│   └── {widget-name}/
│       ├── ui/             # Composed UI
│       └── index.ts
├── features/               # Feature slices
│   └── {feature-name}/
│       ├── ui/             # Feature UI
│       ├── api/            # Feature API calls
│       ├── model/          # State, schemas
│       └── index.ts
├── entities/               # Entity slices
│   └── {entity-name}/
│       ├── ui/             # Entity UI (Card, Avatar)
│       ├── api/            # CRUD operations
│       ├── model/          # Types, mappers, validation
│       └── index.ts
└── shared/                 # Shared layer (no slices)
    ├── ui/                 # Design system components
    ├── api/                # API client, interceptors
    ├── lib/                # Utilities (dates, validation)
    ├── config/             # Environment, constants
    ├── routes/             # Route path constants
    └── i18n/               # Translations

Public API Pattern

Every slice MUST expose a public API via index.ts. External code imports ONLY from this file.

// entities/user/index.ts
export { UserCard } from './ui/UserCard';
export { UserAvatar } from './ui/UserAvatar';
export { getUser, updateUser } from './api/userApi';
export type { User, UserRole } from './model/types';
export { userSchema } from './model/schema';
// ✅ Correct
import { UserCard, type User } from '@/entities/user';

// ❌ Wrong
import { UserCard } from '@/entities/user/ui/UserCard';

Avoid wildcard exports — they expose internals and harm tree-shaking:

// ❌
export * from './ui';

// ✅
export { UserCard } from './ui/UserCard';

Cross-Entity References (@x Notation)

When entities legitimately reference each other, use the @x notation:

entities/
├── product/
│   ├── @x/
│   │   └── order.ts    # API specifically for order entity
│   └── index.ts
└── order/
    └── model/types.ts  # Imports from product/@x/order
// entities/product/@x/order.ts
export type { ProductId } from '../model/types';

// entities/order/model/types.ts
import type { ProductId } from '@/entities/product/@x/order';

Guidelines: Keep cross-imports minimal. Consider merging entities if references are extensive.


Anti-Patterns

Anti-PatternProblemFix
Cross-slice importfeatures/afeatures/bExtract shared logic down
Generic segmentscomponents/, hooks/Use ui/, lib/, model/
Wildcard exportsexport * from './button'Explicit named exports
Business logic in sharedDomain logic in shared/libMove to entities/
Single-use widgetsWidget used by one pageKeep in page slice
Skipping public APIImport from internal pathsAlways use index.ts
Making everything a featureAll interactions as featuresOnly reused actions

TypeScript Configuration

{
  "compilerOptions": {
    "baseUrl": ".",
    "paths": {
      "@/*": ["./src/*"]
    }
  }
}

Reference Documentation

FilePurpose
references/LAYERS.mdComplete layer specifications, flowcharts
references/PUBLIC-API.mdExport patterns, @x notation, tree-shaking
references/IMPLEMENTATION.mdCode patterns: entities, features, React Query
references/NEXTJS.mdApp Router integration, page re-exports
references/MIGRATION.mdIncremental migration strategy
references/CHEATSHEET.mdQuick reference, import matrix

Resources

Official Sources

Community

Source Transparency

This detail page is rendered from real SKILL.md content. Trust labels are metadata-based hints, not a safety guarantee.

Related Skills

Related by shared tags or category signals.

General

clean-ddd-hexagonal

No summary provided by upstream source.

Repository SourceNeeds Review
1.1K-ccheney
General

postgres-drizzle

No summary provided by upstream source.

Repository SourceNeeds Review
General

mermaid-diagrams

No summary provided by upstream source.

Repository SourceNeeds Review
General

modern-javascript

No summary provided by upstream source.

Repository SourceNeeds Review