- Home
- Skills
- Jeongsk
- Claude Skills
- Applying Fsd Architecture
applying-fsd-architecture_skill
- Python
3
GitHub Stars
1
Bundled Files
2 months ago
Catalog Refreshed
4 months ago
First Indexed
Readme & install
Copy the install command, review bundled files from the catalogue, and read any extended description pulled from the listing source.
Installation
Preview and clipboard use veilstrat where the catalogue uses aiagentskills.
npx veilstrat add skill jeongsk/claude-skills --skill applying-fsd-architecture- SKILL.md3.0 KB
Overview
This skill helps apply Feature-Sliced Design (FSD) to frontend projects by guiding layer, slice, and segment structure design and enforcing dependency rules. It supports creating scalable, maintainable codebases and assists during migration or refactor to FSD. The guidance targets practical folder layout, import directions, and role separation within slices.
How this skill works
The skill inspects your intended or existing project structure and maps files into FSD layers: app, pages, widgets, features, entities, and shared. It advises segmenting each slice into ui, api, model, lib, and config and checks for dependency violations (upper layers importing only lower layers and no cross-slice imports within the same layer). For migrations it provides stepwise strategies and concrete refactor suggestions to move code into FSD-compliant slices and segments.
When to use it
- Designing a new frontend project structure with FSD principles
- Planning or executing a migration from existing architecture to FSD
- Deciding where to place components, utilities, or state logic
- Resolving import direction and dependency rule questions
- Creating or naming slices and their internal segments
Best practices
- Keep layer imports one-directional: app → pages → widgets → features → entities → shared
- Avoid cross-slice imports inside the same layer; create shared slices instead
- Put UI and styles under ui/, business state under model/, and API calls under api/
- Start migration by isolating entities and shared utilities before moving features
- Prefer small focused slices for single responsibility and easier testing
Example use cases
- Designing folder layout for a multi-page app with reusable widgets and features
- Refactoring a monolithic components folder into feature-scoped slices
- Guiding team conventions for import rules and segment naming
- Converting global state and APIs into entity and api segments
- Reviewing pull requests to detect FSD dependency rule violations
FAQ
Yes, widgets are higher than features, so widgets may import features but features must not import widgets.
Where should shared utilities that multiple features use live?
Place them in the shared layer, ideally in small, purpose-specific slices so multiple layers can import them without breaking dependency rules.