Install
npx skills add feature-sliced/skills누구에게 맞나
프론트엔드 프로젝트 디렉터리를 다시 정리하고 있거나, 한 줄 코드를 app, pages, features, entities, shared 어디에 넣을지 반복해서 고민한다면 이 Agent 스킬 세트가 더 맞다. 코딩 대리에게 Feature-Sliced Design(FSD) v2.1을 적용하게 가르친다: 층 나누기, 임포트 규칙, 배치 결정, 흔한 패턴. 방법론 본문은
https://fsd.how/
이미 프론트엔드 저장소가 있고 npx로 스킬을 코딩 대리에 넣는 것을 받아들인다고 가정한다. 방법론만 읽고 대리가 디렉터리를 바꾸게 할 생각이 없는 사람은 위 문서만 보면 된다. 페이지는 클라이언트 명단을 주지 않았고 FSD를 특정 프레임워크 전용 플러그인으로 쓰지도 않았다. 프레임워크 묶음을 스스로 보태지 말 것.
3분 만에 첫 시도 끝내기
공식 설치 명령은 이 하나뿐이다:
npx skills add feature-sliced/skills
스킬을 Agent 환경에 쓴다. 먼저 이 기기에 npx가 있고 이것이 바꾸려는 코딩 대리인지 확인한 뒤 실행한다.
넣은 뒤 먼저 읽기 전용 대조한다. 바로 저장소를 재편하지 말 것. 대리에게 FSD v2.1과 대조해 현재 프론트엔드 구조를 보게 한다: 무엇이 이미 app/, pages/, shared/에 있는지, 어떤 임포트 방향이 수상한지. 성공 신호: 층 나누기와 임포트 규칙을 말할 수 있고 pages-first 편향을 보인다 — 이 세 층을 먼저 본다. 바로 features/나 entities/를 만들지 않는다. 파일을 일괄 옮기기 시작하면 먼저 멈춘다.
SKILL.md가 입구다. 대리는 작업이 필요할 때만 참고 파일을 읽는다. 초기 맥락을 작게 유지하기 위해서다. 첫 질문은 「구조 검사 / 이 코드는 어디에」로 구체화한다. 참고 자료를 한 번에 모두 싣게 하지 말 것.
사용 사례
사례 1: 프론트엔드 프로젝트 구조를 짜거나 다시 정리. 공식은 이런 작업을 사용 시기로 든다. 대리는 v2.1 층 나누기와 흔한 패턴을 적용해야 한다. 다만 편견은 pages-first: app/, pages/, shared/에서 시작한다. 안정된 공유 책임이 경계에 맞을 때만 features나 entities를 연다. 발췌에 디렉터리 템플릿 압축은 없고 이전 스크립트도 쓰지 않았다. 따라서 첫 재정리는 먼저 대조 설명을 내고 옮길 경로를 나열한다. 당신이 확인한 뒤 파일을 바꾼다.
사례 2: 코드 착지를 판단. 다른 사용 시기는 코드가 app, pages, features, entities, shared 어디에 속하는지 정하는 것이다. 기존 모듈을 대리에게 주고 「FSD v2.1로 어느 층인지, 임포트가 규칙을 어기는지」만 묻는다. 자동 수리 규칙은 쓰지 않았고 특정 라우터 라이브러리와의 대조표도 없다. 검수는 층 제안과 임포트 이유가 나오는 것만 본다. 바로 feature/entity를 자르라고 하면 그 공유 책임이 왜 이미 안정한지도 함께 설명해야 한다. 설명 없이 새 경계를 열면 이 자료 밖이다.
사용 경계
이 스킬 세트가 가르치는 것은 FSD v2.1이며 임의 연도의 FSD 구술판이 아니다. 방법론 세부는
https://fsd.how/
를 따른다. 페이지는 백엔드 층 나누기를 덮지 않았고 확인 없이 대규모 이름 바꾸기를 대리에게 허용하지 않았다.
설치 경로는 npx skills add feature-sliced/skills다. 설치기를 둘 나란히 두지 말 것. 입구는 항상 SKILL.md다. 참고 파일은 필요할 때 읽는다. 이 발췌로 그 참고 파일들을 지목할 수 없다. 완전한 목록을 이미 안다고 가장하지 말 것.
처음에는 구조 검사와 착지 판단에서 멈춘다. 디렉터리 이동, features/entities 신설, 임포트 별칭 변경은 먼저 대리에게 바꿀 파일과 이유를 나열하게 하고 당신이 확인한 뒤 이어간다.