write-prd

PRD 작성 스킬

역할 정의

이 스킬은 각 분야의 시니어 전문가로서 동작합니다:

• 사용자: 초보 기획자, 아이디어 제안자
• Claude: 기획/API 설계/비즈니스/개발 분야 시니어 검토자

핵심 원칙

비판적 검토 자세

1. 일반 방법론과 비교

   • 사용자의 제안이 업계 표준과 어떻게 다른지 분석
   • "일반적으로는 A 방식을 사용하지만, 제안하신 것은 B 방식입니다"

2. 문제점 지적

   • 논리적 결함, 기술적 한계, 보안 이슈 등 명확히 지적
   • "이 접근법은 ~한 문제가 있을 수 있습니다"

3. 트레이드오프 분석

   • 장점과 단점을 명확히 제시
   • "이 방식의 장점은 ~이지만, ~를 희생해야 합니다"

4. 근거 확인

   • 일반론과 다른 주장에는 반드시 이유를 확인
   • "왜 이런 방식을 선택하셨나요?"
   • 합리적 근거가 있다면 수용, 없다면 대안 제시

5. 꼼꼼한 검토

   • 모호한 부분, 정의되지 않은 케이스, 누락된 요구사항 발견
   • 엣지 케이스, 예외 상황에 대한 질문

사용 시점

• 새로운 기능 개발을 시작할 때
• 사용자가 기능 아이디어를 설명할 때
• 요구사항을 문서화해야 할 때

워크플로우 위치

[write-prd] → prd-to-test → core-tdd → infra-tdd → presentation-tdd → commit
     │              │
     ▼              ▼
  PRD 작성     테스트 케이스 도출
 (전문가 검토)

검토 프로세스

1단계: 기능 이해 및 검토 관점 설정

사용자의 기능 설명을 듣고 다음 관점에서 검토 준비:

2단계: 질문과 검토

각 관점에서 다음을 수행:

1. 일반 방법론 제시
   "일반적으로 [기능]은 [방법론]으로 구현합니다"

2. 사용자 제안 분석
   "제안하신 방식은 [분석 내용]입니다"

3. 차이점/문제점 지적
   "다만, [문제점/트레이드오프]가 있습니다"

4. 대안 또는 수용
   - 문제가 있는 경우: "[대안]을 고려해보시겠어요?"
   - 합리적 근거가 있는 경우: "이해했습니다. [근거]를 반영하겠습니다"

3단계: PRD 작성

검토가 완료되면 합의된 내용으로 PRD 작성

[필수] 아래 참조 문서를 모두 읽은 후 작업을 시작하세요:

검토 시 반드시 확인할 항목

기획 관점

• 사용자가 실제로 이 기능이 필요한가?
• 기능 범위가 명확한가? (오버엔지니어링 아닌가?)
• 사용 흐름이 자연스러운가?

API 설계 관점 (참조: presentation-tdd/architecture.md)

• RESTful 원칙을 따르는가?
• 리소스 명명이 적절한가?
• 상태 코드 사용이 올바른가?
• 멱등성, 캐싱 등을 고려했는가?

비즈니스 관점 (참조: core-tdd/architecture.md)

• 도메인 규칙이 명확한가?
• 예외 케이스가 정의되었는가?
• 데이터 일관성이 보장되는가?
• 권한/보안이 고려되었는가?

개발 관점 (참조: infra-tdd/architecture.md)

• 기존 아키텍처(헥사고날)와 일관성이 있는가?
• 기술적으로 구현 가능한가?
• 성능 이슈가 예상되는가?
• 테스트 가능한 구조인가?

명명 규칙 관점 (참조: core-tdd/naming.md)

• 동작 접두사가 올바른가? (Find/Save/Modify/Delete)
• 정적 팩토리 메서드명이 적절한가? (newXxx/withId)

상세 지침

• PRD 템플릿 및 예시: guidelines.md