skills/feature-slicing/SKILL.md
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.
npx skillsauth add ccheney/robust-skills feature-slicingInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
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
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 | 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.
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/
| 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.
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/).
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
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';
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-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 |
{
"compilerOptions": {
"baseUrl": ".",
"paths": {
"@/*": ["./src/*"]
}
}
}
| 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 |
development
Proactively apply when generating any Slack text content, chat.postMessage text fields, or text objects with type "mrkdwn". Triggers on mrkdwn, Slack formatting, Slack markdown, Slack bold, Slack italic, Slack link syntax, Slack mentions, Slack date formatting, Slack escaping, Slack text object, verbatim, plain_text, Slack mrkdwn vs markdown, Slack blockquote, Slack code block, Slack strikethrough, Slack user mention, Slack channel mention, Slack emoji, link_names, auto-parsing. Use when formatting Slack message text, writing mrkdwn strings, constructing text objects, escaping user content for Slack, adding mentions or date formatting to messages, or debugging text rendering issues. Slack mrkdwn text formatting syntax for messages, text objects, and attachments.
development
Proactively apply when generating Slack API payloads with blocks, chat.postMessage calls with structured content, streaming AI responses, or views.open/views.publish calls. Triggers on Block Kit, Slack blocks, section block, actions block, header block, divider block, context block, alert block, card block, carousel block, table block, markdown block, rich text block, image block, input block, video block, context_actions block, plan block, task_card block, chat.startStream, chat.appendStream, chat.stopStream, Slack modal, Slack App Home, Slack surfaces, Slack interactive elements, Slack button, Slack select menu, Slack overflow, Slack datepicker, Slack checkboxes, Slack radio buttons, Work Objects, Slack link unfurl, chat.postMessage blocks, views.open, views.update, views.push, views.publish, Slack composition objects. Use when building Block Kit payloads, constructing blocks arrays, creating modals or App Home views, adding interactive elements, implementing link unfurling with Work Objects, streaming agent output, or designing rich message layouts. Slack Block Kit UI framework for building rich message layouts, modals, App Home views, and AI agent responses.
development
Proactively apply when creating APIs, backends, or data models. Triggers on PostgreSQL, Postgres, Drizzle, database, schema, tables, columns, indexes, queries, migrations, ORM, relations, joins, transactions, SQL, drizzle-kit, connection pooling, N+1, JSONB, RLS. Use when writing database schemas, queries, migrations, or any database-related code. PostgreSQL and Drizzle ORM best practices.
development
Proactively apply when creating web applications, Node.js services, or any JavaScript project. Triggers on JavaScript, ES6, ES2020, ES2022, ES2024, modern JS, refactor legacy, array methods, async/await, optional chaining, nullish coalescing, destructuring, spread, rest, template literals, arrow functions, toSorted, toReversed, at, groupBy, Promise, functional programming. Use when writing new JavaScript code, refactoring legacy code, modernizing codebases, implementing functional patterns, or reviewing JS for performance and readability. Modern JavaScript (ES6-ES2025) patterns and best practices.