fe-spec

FE Spec 작성 스킬

사용자의 기능 설명을 받아 실행 가능한 프론트엔드 스펙으로 변환합니다.

When to Use

• 새로운 페이지나 컴포넌트 개발 시작 전
• 기획 내용을 구체적인 개발 태스크로 나눠야 할 때
• feature.md가 없거나 내용이 불충분할 때

Instructions

Phase 0 — 에이전트 분석 (선택적 위임)

요구사항이 복잡하거나 디자인 시안이 있는 경우, 스펙 작성 전 아래 에이전트에 위임한다:

상황	위임 에이전트
요구사항이 모호하거나 갭이 있을 때	fe-analyst — 6갭 분석 후 명확화 질문 도출
Figma·스크린샷·디자인 시안이 있을 때	fe-vision — 레이아웃·컴포넌트·색상 추출
특정 라이브러리·API 조사가 필요할 때	fe-researcher — 공식 문서 기반 조사
RSC 경계·아키텍처·스타일링 전략(Tailwind/shadcn) 결정이 필요할 때	fe-architect — 구조 자문

Phase 1 — 목적 명확화

사용자에게 반드시 확인:

1. 누가 쓰는가? (사용자 페르소나)
2. 무엇을 해결하는가? (핵심 문제)
3. 완료의 기준은? (Acceptance Criteria)

Phase 2 — 스펙 문서 생성

feature.md 파일을 프로젝트 루트에 생성합니다:

# [기능명]

## 목적


## 컴포넌트 구조

- 신규: 
- 수정: 

## 기술 상세
- 관련 페이지/라우트: 
- API 엔드포인트: 
- 상태관리: (예: Zustand·Pinia·NgRx | TanStack Query | 로컬 state)
- 스타일링: (Tailwind 클래스 / shadcn/ui 컴포넌트 / 커스텀 CSS)
- 의존 컴포넌트: 

## 완료 기준 (Acceptance Criteria)
- [ ] TypeScript 타입 에러 0개
- [ ] 린터(ESLint/Biome) 경고 0개
- [ ] Vitest 테스트 통과
- [ ] 반응형: 모바일(375px) / 태블릿(768px) / 데스크탑(1280px)
- [ ] 접근성: 키보드 네비게이션, aria-label 적용


## 금지 사항
- [ ] any 타입 사용
- [ ] 컴포넌트 라이프사이클에서 서버 데이터 직접 fetch
- [ ] 컴포넌트에 비즈니스 로직 직접 작성

Phase 3 — 승인 요청

스펙 작성 후 반드시 물어봅니다:

"위 스펙으로 구현을 진행할까요? 수정할 부분이 있으면 말씀해주세요."

승인 전에는 절대 구현을 시작하지 않습니다.

Anti-patterns (하지 말 것)

• 스펙 없이 바로 컴포넌트 코드 작성
• "대충 이런 느낌"으로 넘어가기
• 완료 기준 없이 시작하기