Enforces Feature-Sliced Design (FSD) architecture in React/TypeScript projects by scaffolding compliant folder structures, validating layer boundaries and import directions, detecting and fixing layer violations, and teaching FSD conventions during code generation and review. Use when asked to 'create a page', 'add an entity', 'build a widget', 'scaffold FSD structure', 'refactor to FSD', 'where should I put this code', 'what layer does X go in', 'organize my React code', 'fix layer violation', or 'review my FSD structure'. Triggers on any React/TypeScript task involving FSD layers, slices, segments, cross-layer imports, or public API boundaries.
72
89%
Does it follow best practices?
Run evals on this skill
Adds up to 20 points to the overall score
View guide
Passed
No findings from the security scan
Architectural guide for organizing React/TypeScript frontends following Feature-Sliced Design (FSD) — a methodology that splits code into layers and slices with strict dependency rules. Tailored for React function components, hooks, and the React ecosystem.
FSD treats every slice as a Grey Box module: a clear public API (index.ts) with hidden internals (ui/, model/, api/, lib/). This is both human- and AI-friendly:
@/entities/customer, not internal filessrc/
├── app/ # Providers, router, global styles, entry point (no slices)
├── pages/ # Route components (one per route)
├── widgets/ # Composite UI blocks
├── features/ # User interactions (auth, search, filters)
├── entities/ # Business domain (components, hooks, types)
└── shared/ # Reusable infrastructure (no slices)
app/andshared/are divided directly into segments — they do not contain slices.
Imports flow DOWN only. Same-layer imports are FORBIDDEN.
| Layer | Can Import From | Cannot Import From |
|---|---|---|
| app | pages, widgets, features, entities, shared | — |
| pages | widgets, features, entities, shared | app |
| widgets | features, entities, shared | app, pages |
| features | entities, shared | app, pages, widgets |
| entities | shared | app, pages, widgets, features |
| shared | — | app, pages, widgets, features, entities |
| Question | Layer |
|---|---|
| App-level setup (providers, router, global init)? | app |
| Route/page? | pages |
| Reusable UI block used across multiple pages? | widgets |
| User action (submit form, search, filter, like)? | features |
| Business entity (user, customer, project)? | entities |
| Shared utilities, config, API client? | shared |
Every slice follows the same internal layout (all segments optional):
{slice-name}/
├── ui/ # Components (.tsx, one per file)
├── model/ # Hooks, state, types
├── api/ # Data fetching (REST/GraphQL)
├── lib/ # Pure helpers, utility hooks
├── config.ts # Constants, configuration
├── index.ts # PUBLIC API — only exports for external use
└── CLAUDE.md # Purpose + non-obvious context (required)Each segment directory has its own index.ts re-exporting all items. External code imports ONLY from the slice's root index.ts.
| Type | Convention | Example |
|---|---|---|
| All Files | kebab-case | employee-picker.tsx |
| Components | PascalCase | EmployeePicker |
| Hooks | camelCase with use prefix | useEmployeeData |
| Utilities | camelCase | formatCurrency |
| Types | PascalCase | EmployeeData |
| Directories | kebab-case | employee-picker/ |
If using a component library:
components/ui/ or node_modules)shared/ui/ or slice ui/Every slice must have a CLAUDE.md. Keep it very short: what this module is for + anything non-obvious. Everything else is discoverable from code. See references/claude-md-template.md for the template.
src/{layer}/{slice-name}/ with needed segments (ui/, model/, api/, lib/)index.ts with explicit named exports (no export *)index.ts, (c) no export * re-exportsA minimal entities/customer/ slice:
// entities/customer/model/types.ts
export interface Customer {
id: string;
name: string;
email: string;
status: 'active' | 'inactive';
}
// entities/customer/model/use-customer.ts
import { useState, useEffect } from 'react';
import { fetchCustomer } from '../api';
import type { Customer } from './types';
export function useCustomer(id: string) {
const [customer, setCustomer] = useState<Customer | null>(null);
useEffect(() => { fetchCustomer(id).then(setCustomer); }, [id]);
return customer;
}
// entities/customer/api/customer-api.ts
import type { Customer } from '../model';
export async function fetchCustomer(id: string): Promise<Customer> {
const res = await fetch(`/api/customers/${id}`);
return res.json();
}
// entities/customer/index.ts — PUBLIC API
export { useCustomer } from './model';
export type { Customer } from './model';
export { CustomerCard } from './ui';Actively teach FSD principles — explain decisions, don't just apply rules:
| Situation | Action |
|---|---|
| Writing code | Explain layer/segment choice in 1-2 sentences |
| Spot a violation | Flag it, explain why it breaks FSD, show the fix |
| "Where should I put this?" | Walk through the Layer Decision Guide |
| Reviewing code | Check FSD compliance, suggest corrections with reasoning |
| Project deviates from guide | Ask for reasoning first — project consistency matters more than strict compliance |
| Violation | Fix |
|---|---|
Upward import (entity → feature) | Move shared logic to shared/ or compose in a higher layer |
Same-layer import (entity → entity) | Use @x cross-imports or compose in widget//feature/ |
Direct internal import (./ui/card) | Import from slice's index.ts instead |
Wildcard re-export (export *) | List exports explicitly |
shared/ with domain-specific codeindex.ts public APIexport * from is forbidden)| Need | Read |
|---|---|
| Layer rules, when to create each layer, cross-entity patterns | references/layers.md |
| Segment rules (ui, model, api, lib, config, index) | references/segments.md |
| CLAUDE.md template | references/claude-md-template.md |
| Slice examples (entity, feature, widget, page) | references/slice-examples.md |
This skill is a React/TypeScript adaptation of Feature-Sliced Design. For the canonical spec, use WebFetch to read from fsd.how/llms.txt:
Do NOT fetch these URLs proactively. Only use
WebFetchwhen the engineer explicitly asks for the full FSD specification or you encounter a question this skill doesn't cover.
Consult the official spec when you need details beyond what this skill covers (e.g., migration strategies, advanced decomposition patterns, framework-agnostic rules).
298fce7
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.