Sandbox
@feature-sliced/skills

Feature-Sliced Design skills for coding agents

This repository packages agent skills for applying Feature-Sliced Design v2.1 in frontend work. The core skill gives an agent a decision framework for where code belongs, with references for layout, assets, cross-imports, migration, and framework setup when a task needs them.

94 stars8 forksUpdated 12d ago
Who it's for

Builders who want Claude Code, Codex, or another agent to follow Feature-Sliced Design in frontend projects.

What it delivers

You can let your agent structure frontend code more consistently without re-explaining FSD rules each time.

What it does

Core FSD skill

`feature-sliced-design/SKILL.md` teaches layer hierarchy, import rules, and placement decisions for app, pages, features, entities, and shared.

Pages-first bias

The skill starts with `app/`, `pages/`, and `shared/`, and only opens a higher boundary when the responsibility is stable enough to earn one.

Reference guides

Files under `feature-sliced-design/references/` cover layer structure, asset handling, cross-import patterns, migration, framework integration, auth and API, and state management.

Evaluation cases

`evals/cases.json` stores placement cases used to check whether the skill keeps giving the intended answers.

Skill validation

`.github/scripts/validate-skills.mjs` checks package rules, reference links, numbered cross-references, and eval case integrity.

How to get it

  1. 1Run
    npx skills add feature-sliced/skills

README

Feature-Sliced Design: Agent Skills

Agent skills that teach AI coding agents how to apply the Feature-Sliced Design (FSD) v2.1 methodology.

Installation

npx skills add feature-sliced/skills

Available skills

feature-sliced-design

Apply FSD v2.1 principles when structuring frontend projects. The agent learns layer hierarchy, import rules, the decision framework for code placement, and common patterns.

Its bias is pages-first: start with app/, pages/, and shared/, and open a features or entities boundary only when a stable shared responsibility has earned one. Code used in two places does not, by itself, earn a layer.

It follows the official FSD v2.1 documentation but is not a verbatim copy. Where two official guides answer the same question differently, it picks one and says which. Where an integration guide has fallen behind a framework's own docs, it follows the framework. It also folds in recent maintainer guidance so an agent decides consistently across tasks. Passages that depart from a guide say so inline.

Use when:

  • Setting up or reorganizing a frontend project structure
  • Deciding where code belongs across app, pages, features, entities, and shared
  • Placing static assets (images, icons, fonts, PDFs) in the right slice or layer
  • Grouping closely related slices into slice groups as the project grows
  • Deciding where page layouts belong, or whether to use the widgets layer (discouraged)
  • Resolving cross-import issues or evaluating the @x pattern
  • Deciding whether to create or remove an entity, or whether to skip the entities layer entirely
  • Migrating from FSD v2.0 or a non-FSD codebase
  • Integrating FSD with Next.js (App Router or Pages Router), React Router, Nuxt, Vite, or Astro
  • Implementing auth, API request handling, or state management (Redux, TanStack Query) within FSD

Examples:

Set up FSD project structure with Next.js App Router
This rule is used on two pages now. Should it become an entity?
Where should I put auth tokens and session state?
These two entities need to import from each other. How do I fix this?
Where should I put hero images for my landing page?

Skill structure

feature-sliced-design/
  SKILL.md                         Core rules and decision framework
  references/
    layer-structure.md             Detailed folder structures per layer (incl. slice groups)
    growth-walkthrough.md          One shop through four snapshots: which moments earn a layer
    asset-handling.md              Where to place images, icons, fonts, and other static assets
    cross-import-patterns.md       Cross-import resolution: 4 strategies for features/widgets, @x for entities
    excessive-entities.md          Keeping the entities layer clean: when to skip, what to extract
    migration-guide.md             v2.0→v2.1 and non-FSD migration
    framework-integration.md       Next.js, React Router, Nuxt, Vite, Astro setup
    auth-and-api.md                Auth, type definitions, API request handling
    state-management.md            Redux, TanStack Query (React Query)

evals/
  README.md                        How to run and maintain the cases
  cases.json                       Placement regression cases

SKILL.md is the entry point. It tells the agent to read a reference file only when the task calls for it, so the initial context stays small.

Contributing

Run the validator before opening a pull request:

node .github/scripts/validate-skills.mjs

It enforces this repository's skill-package rules, which are based in part on the guidance in vercel-labs/agent-skills AGENTS.md:

  • The SKILL.md body stays under 500 lines to keep the initial skill context lightweight. Frontmatter is excluded from the count.
  • The frontmatter name matches the skill's directory name and is at most 64 characters.
  • The frontmatter contains a description of at most 1024 characters, the limits from the Agent Skills specification.
  • Every references/<file>.md path, whether written in SKILL.md or in another reference, resolves to an existing file.
  • Every file under references/ is routed from the Conditional references section of SKILL.md, so a reference that section forgets fails the build instead of shipping unreachable. Naming it elsewhere in the body, or inside a fenced example, does not count. A skill with no such section falls back to requiring a mention anywhere in SKILL.md.
  • Every numbered cross-reference resolves. Section N, Section N-M, and Rule N-M always mean a numbered heading in SKILL.md, whichever file mentions them; Step N, Strategy X, Snapshot N, Part N, and Question N mean a heading or bold label somewhere in the package.
  • A named rule such as "the request placement rule" that is cited from more than one file is a heading or bold label somewhere in the package, so renaming the anchor fails the build instead of stranding its readers.
  • evals/cases.json is valid JSON with at least one case; every case has id, prompt, expect, why, source, and rule, ids are unique, every source path exists, and every rule fragment resolves to a passage of the skill (see evals/README.md).

The validator has its own tests, which break one thing at a time in a copy of the repository and assert that it is reported:

node --test .github/scripts/validate-skills.test.mjs

References

License

MIT

Files in the repo

Repository payload4 top-level entries
  • .github
  • evals
  • feature-sliced-design
  • README.md

Discussion (0)

Ask about usage, or say what you built with it

Sign in to join the discussion.

No comments yet. Be the first to say what this is good for.

More skills

obra/
superpowers

An agentic skills framework & software development methodology that works.

285k
1 add

Turn any codebase, with its docs, SQL schemas, configs, and PDFs, into a queryable knowledge graph. A /graphify skill for Claude Code, Cursor, Codex, and Gemini CLI: local deterministic AST parsing, every edge explained, no vector store.

117k
1 add
Vincentwei1021/
anything2explainer

Topic in, narrated explainer video out. A Claude Code / Codex skill that turns any topic into a black-canvas motion-graphics explainer video with TTS voiceover, subtitles and a chapter progress bar. Chinese or English; every frame drawn in code with Remotion.

666

Open-source AI job search: scan job portals, evaluate listings into a structured A-H report with a global 1-5 score, tailor your CV, track applications — runs locally in your AI coding CLI (Claude Code, Codex, OpenCode, Antigravity…)

71k