ccheney

feature-slicing

2
0
# Install this skill:
npx skills add ccheney/robust-skills --skill "feature-slicing"

Install specific skill from multi-skill repository

# Description

|

# SKILL.md


name: feature-slicing
description: |
Apply Feature-Sliced Design (FSD) architecture to frontend projects. Triggers on: FSD, feature slicing,
frontend architecture, layer structure, module boundaries, scalable frontend, slice organization.

Use when: creating new features/components/pages, restructuring React/Next.js/Vue/Remix projects,
organizing frontend code, setting up project structure, fixing import violations, or migrating legacy codebases.


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)
Violation Example Fix
Cross-slice (same layer) features/auth β†’ features/user Extract to entities/ or shared/
Upward import entities/user β†’ features/auth Move shared code down
Shared importing up shared/ β†’ entities/ Shared has NO internal deps

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


Layer Hierarchy

Layer Purpose Has Slices Required
app/ Initialization, routing, providers, global styles No Yes
pages/ Route-based screens (one slice per route) Yes Yes
widgets/ Complex reusable UI blocks (header, sidebar) Yes No
features/ User interactions with business value (login, checkout) Yes No
entities/ Business domain models (user, product, order) Yes No
shared/ Project-agnostic infrastructure (UI kit, API client, utils) No Yes

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 model auth β€” login/logout actions
product β€” product info add-to-cart β€” adding to cart
comment β€” comment data write-comment β€” creating comments
order β€” order record checkout β€” 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-Pattern Problem Fix
Cross-slice import features/a β†’ features/b Extract shared logic down
Generic segments components/, hooks/ Use ui/, lib/, model/
Wildcard exports export * from './button' Explicit named exports
Business logic in shared Domain logic in shared/lib Move to entities/
Single-use widgets Widget used by one page Keep in page slice
Skipping public API Import from internal paths Always use index.ts
Making everything a feature All interactions as features Only reused actions

TypeScript Configuration

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

Reference Documentation

File Purpose
references/LAYERS.md Complete layer specifications, flowcharts
references/PUBLIC-API.md Export patterns, @x notation, tree-shaking
references/IMPLEMENTATION.md Code patterns: entities, features, React Query
references/NEXTJS.md App Router integration, page re-exports
references/MIGRATION.md Incremental migration strategy
references/CHEATSHEET.md Quick reference, import matrix

Resources

Official Sources

  • Official Documentation: https://feature-sliced.design
  • GitHub Organization: https://github.com/feature-sliced
  • Official Examples: https://github.com/feature-sliced/examples
  • Specification: https://feature-sliced.design/docs/reference

Community

  • Awesome FSD: https://github.com/feature-sliced/awesome (curated articles, videos, tools)

# Supported AI Coding Agents

This skill is compatible with the SKILL.md standard and works with all major AI coding agents:

Learn more about the SKILL.md standard and how to use these skills with your preferred AI coding agent.