product-design-review

Files (1)

• SKILL.md

SKILL.md (first lines)

# 제품 화면 제작과 검수

사용자가 화면·흐름의 구현이나 수정을 요청하면 그 범위의 제품 코드 변경과 검증을 바로 진행한다. 검수대 작성·후보 선택·화면별 승인은 구현의 선행 조건이 아니다. 과거 repo·스킬의 검수대 승인 전 적용 금지 문구보다 이 원칙을 우선하며, 사용자가 현재 작업에서 명시적으로 승인 대기를 요청한 경우에만 기다린다.

## 제품 레퍼런스를 화면으로 옮기기

새 화면을 만들거나 색·글꼴·배치를 의미 있게 바꿀 때 적용한다. 작은 문구·간격 수정은 기존 방향을 재사용한다.

1. 사용자가 제공한 제품 레퍼런스와 현재 제품의 실제 화면·디자인 기준을 좁게 확인한다. 레퍼런스가 없으면 기존 제품의 컴포넌트·색상·서체를 출발점으로 삼는다. 접근하지 못한 레퍼런스는 미확인으로 표시하고 확인 가능한 근거로 진행한다.
2. 사용자 목적과 레퍼런스에서 가져올 요소를 연결한다. 예: 업무 도구의 빠른 비교를 위해 단정한 정보 배치와 절제된 색을 사용한다. 색의 역할, 글꼴·제목/본문 위계, 여백·정보 밀도, 배치·작은 화면 동작을 구현에 필요한 만큼 구체화한다. 해당 제품의 기존 디자인 토큰·컴포넌트를 우선 사용한다.
3. 확인한 기준으로 요청 범위를 구현한다. 레퍼런스의 인상을 제품의 실제 정보·행동에 맞게 옮기고 기존 브랜드·사용 흐름·접근성을 보존한다. 레퍼런스 선택이나 별도 기획 문서·후보 생성·승인을 구현의 필수 선행 단계로 만들지 않는다.
4. 실제 화면에서 레퍼런스의 선택한 요소가 반영됐는지와 가독성·정보 우선순위·작은 화면·핵심 조작을 변경 범위에 맞게 확인한다. 참고한 요소와 제품에 맞춰 달리한 부분을 짧게 설명한다. 지침 적용과 실제 화면 검증을 구분한다.

## 구현과 검증 경계

- 기존 제품 결정과 검수 기록은 설계 근거로 참고한다. 승인 기록이 없다는 이유로 구현을 중단하거나 검수 작업대만 만들고 끝내지 않는다. 배포·게시·유료 호출·계정·데이터 변경은 해당 작업의 권한 경계를 따른다.
- 변경 대상의 코드와 실제 화면을 좁게 확인하고, 필요한 구현 후 변경을 증명하는 가장 작은 충분한 화면·동작 검증을 수행한다. Product Design은 시각 대안이나 정밀 비교가 필요할 때 선택한다.
- 검수 작업대는 사용자가 요청했거나 비교에 도움이 될 때 만든다. 실제 제품과 분리된 한 페이지에서 `목차 | 만들어갈 UI | 실제 제품 UI | 기획 의도`를 동시에 보여 준다. 전체 목차를 제공하되 목록만 만든 항목을 완성으로 보고하지 않는다.
- 비교 근거는 실제 제품 캡처나 검증된 렌더만 사용한다. 시각 대안이 필요하면 기존 제품·참조 화면과 사용자의 요구를 바탕으로 준비한다. 후보 세 개 생성이나 선택 대기를 모든 UI 작업에 강제하지 않는다. 이미지가 필요하면 제공된 이미지 도구를 쓰고 개인 이메일 계정이나 별도 API key를 요구하지 않는다.
- 만들어갈 UI와 실제 제품 UI frame은 원본 viewport와 종횡비를 유지한다. `contain` 방식으로 전체를 보여 주며 crop·cover·늘어짐·잘림을 허용하지 않는다.
- 우측 기획 의도는 실제 텍스트로 제공하고 핵심 제목 21px, 주 설명 16px, 세부 본문 15px, 보조 설명 14px 이상을 기본으로 한다. 화면에 맞추기 위해 핵심 문장을 작은 글자로 줄이지 않는다.
- frontend와 backend가 별도 Git이면 각 Git 루트와 연결된 제품 계약을 확인하고 필요한 범위만 구현·검증한다. 검수 화면의 승인 상태를 코드 변경 조건으로 삼지 않는다.
- 검수 작업대의 목차·비교 frame·기획 의도 패널은 실제 제품 UI에 포함하지 않는다. 요청한 목표 화면과 필요한 제품 동작만 구현한다.

From dhddldid/Codex-Setup, MIT.

More from dhddldid/Codex-Setup