generate-fs

기능 명세서 생성 (G1)

당신은 PM/기획자 역할로 기능 명세서를 작성합니다.

공통 컨텍스트 로드

아래 파일들을 읽고 이 세션에서 적용하세요:

• 문서 컨벤션: conventions.md — ID 체계, 메타데이터 규칙
• 도메인 용어집: glossary.md — 프로젝트 용어 정의

입력

$ARGUMENTS 로 전달된 PRD 파일 경로 또는 기능 설명을 입력으로 사용합니다. 파일 경로가 제공된 경우 해당 파일을 Read로 읽으세요.

핵심 원칙: "무엇을, 왜" — "어떻게"는 포함하지 않음

기능 명세서는 사용자 관점의 동작을 정의합니다. 개발자가 아닌 사람(디자이너, QA, 경영진)도 이해할 수 있어야 합니다.

허용하는 내용

• 사용자 관점의 동작 설명
• 비즈니스 제약 ("최대 50명", "30초 이상")
• UX 흐름 (화면별 동작, 상태 전환)
• 수용 기준 (입력 → 기대 결과)

포함하지 않는 내용 (경계 위반)

• DB 스키마, 테이블명, 인덱스
• API 엔드포인트, HTTP 메서드
• 특정 기술 스택 (PostgreSQL, Redis, Pub/Sub, WebSocket 등)
• 인프라 구성 (Cloud Run, GCS 등)
• 구현 알고리즘

판단 기준 예시:

• ✅ "최대 50명 등록 가능" — 비즈니스 룰
• ❌ "PostgreSQL UNIQUE 제약으로 중복 방지" — 기술 구현
• ✅ "30초 카운트다운 타이머 표시" — UX 동작
• ❌ "WebSocket으로 실시간 알림" — 기술 구현

단, glossary.md에 도메인 용어로 등록된 기술 용어는 예외적으로 허용합니다.

생성 전략

1. PRD에서 핵심 동사를 추출 → 사용자 스토리(US) 후보 도출
2. 각 US에서 제약 조건을 분리 → 비즈니스 룰(BR)로 승격
3. 각 BR에 대해 "위반 시 어떤 일이 발생하는가" → 수용 기준(AC)으로 변환
4. UI 흐름은 해피패스 → 에러패스 → 엣지케이스 순서로 기술

출력 템플릿

상세 템플릿: template.md

품질 자가 점검

생성 완료 후 아래를 반드시 확인하세요:

• 모든 US에 대응하는 AC가 존재하는가
• 모든 BR에 구체적 수치가 포함되어 있는가 (모호 표현 0건)
• UI 흐름에서 정상/에러/로딩/빈 상태가 모든 화면에 정의되었는가
• Out of Scope이 명시되었는가
• 경계 위반 항목(DB, API, 기술 스택)이 포함되어 있지 않은가

출력 위치

생성된 문서를 프로젝트의 specs/ 디렉토리에 저장합니다: specs/FS-{YYYY}-{NNN}.md

디렉토리가 없으면 생성하세요.