pdr

name	pdr
description	Product Design Review — 신규 기능/화면/API/모듈을 만들거나 크게 바꾸기 전에 목표·사용자 시나리오·제약·엣지케이스·검증 기준을 짧게 결정해 docs/design-reviews/에 남긴다.
disable-model-invocation	true

pdr (Product Design Review)

이 skill은 구현 전에 설계 의사결정을 짧게 잠그는 데 쓴다. 큰 PRD가 아니라, "이번 변경에서 결정되어야 할 것"만 한 페이지로 남기는 설계 리뷰다. 파일 생성/수정 workflow이므로 수동 호출 전용이다.

사용 시점

• 신규 기능·화면·API·모듈을 만든다.
• 기존 기능을 비호환적으로 바꾼다(데이터 모델, 인증, 결제, 권한 등).
• 사용자 시나리오·입출력·검증 기준이 머릿속에만 있고 문서로 남아 있지 않다.
• explorer 탐색에서 영향 범위가 크다고 판단했다.
• 사용자가 "알아서", "잘 만들어줘"처럼 넓은 요청을 했는데 그대로 구현하면 핵심 결정이 묻힌다.

사용하지 않는 경우

• 단일 파일의 명확한 수정·버그 수정.
• 리팩터링만 있고 외부 동작이 바뀌지 않는다.
• 평가, 비교, 검증처럼 파일 변경 없는 답변만 필요하다.
• 기존 설계 문서에 같은 결정이 이미 있고 갱신만으로 충분하다.

작성 위치

• 기본 위치는 docs/design-reviews/<slug>.md. slug는 변경 단위(예: payment-refund-v2, auth-magiclink).
• 기존 프로젝트가 ADR/RFC/PDR 디렉터리 체계를 이미 가지고 있으면 그 구조와 문체를 따른다.
• 하네스 변경 결정은 여기 쓰지 않는다. 그건 .claude/notes/harness-decisions.md에 짧게 남긴다.

문서 형식

# <변경 단위> Design Review

## 목표
- <이번 변경으로 달성할 사용자/시스템 효과>

## 사용자 시나리오
- 주 시나리오: <누가, 어떤 상황에서, 무엇을 한다>
- 보조 시나리오: <예외/대안>

## 입력 / 출력
- 입력: <데이터, 호출자, 트리거>
- 출력: <응답, 상태 변경, 부수 효과>

## 제약
- 기술 제약: <스택, 성능, 호환성>
- 비즈니스 제약: <오너십, 규정, 일정>

## 엣지케이스
- <빈 값/실패/타임아웃/동시성/권한 누락 등>

## 검증 기준
- 기능 검증: <테스트, 시나리오>
- 비기능 검증: <성능, 보안, 접근성, 로깅>

## Out of Scope
- <이번 변경에서 명시적으로 제외하는 것>

## 미해결 질문
- <답이 필요한 질문 또는 없음>

진행 방식

1. explorer 결과나 사용자 요청에서 변경 단위를 한 문장으로 정의한다.
2. 기존 코드·문서에서 확인 가능한 사실을 먼저 채운다.
3. 결정이 필요한 부분만 사용자에게 1~3개 질문으로 좁힌다.
4. 답을 받은 뒤 문서를 채운다.
5. 미해결 질문이 남으면 그 자체를 문서에 남긴다.

완료 기준

• 목표·사용자 시나리오·입출력·제약·엣지케이스·검증 기준·Out of Scope·미해결 질문 항목이 모두 있다.
• 사용자 시나리오는 1인칭 또는 행위자 명시로 구체적이다.
• 검증 기준이 실행 가능한 형태다("로그인 후 5초 안에 토큰 발급" 같은 측정 가능 표현).
• 기존 SSOT(스펙, 디자인 문서, ADR)와 충돌하지 않는다.
• 코드 작업 전에 이 문서가 coder의 참조 입력이 된다.