pr-description

name	pr-description
description	현재 브랜치의 변경사항을 분석해 레포 PR 템플릿에 맞춘 한국어 PR 본문을 "바로 복붙 가능한" 형태로 작성한다. 사용자가 "PR 작성", "PR 본문", "PR 템플릿에 맞게", "PR 문서" 등을 요청할 때 사용.

PR 문서 작성

현재 브랜치의 변경사항을 분석해 .github/pull_request_template.md 구조에 맞춘 한국어 PR 본문을 작성한다. 결과는 사용자가 그대로 복사·붙여넣기 할 수 있도록 하나의 코드블록으로 출력한다.

절차

1. 템플릿 로드 — .github/pull_request_template.md 를 Read 한다. 섹션 구조·순서·주석은 이 파일을 기준으로 삼는다 (템플릿이 바뀌면 자동으로 따라간다).
2. 변경사항 수집
   • git log --oneline main..HEAD — 커밋 목록 (이슈 번호 추출)
   • git diff --stat main...HEAD — 변경 파일 전체
   • 핵심 코드 변경은 git diff main...HEAD -- <경로> 로 실제 내용 확인 (에셋/자동생성물 나열보다 의도를 파악)
3. 이슈 번호 — 커밋 메시지의 (#숫자) 에서 추출해 Closes #N 에 채운다. 여러 개면 가장 빈번한 번호를 쓰고, 불확실하면 결과 하단에 "이슈 번호 확인 필요"로 안내.
4. 본문 작성 — 아래 스타일 규칙대로 작성.
5. 출력 — 전체를 하나의 ```markdown 코드블록으로 출력하고, 코드블록 밖에 짧은 참고사항(이슈 번호·스크린샷 등 사용자가 채워야 할 부분)을 덧붙인다.

스타일 규칙 (가독성 우선)

• 변경 내용은 변경 파일 나열이 아니라 작업 영역별로 그룹핑하고 이모지 소제목(###)을 붙인다. 예: 🎨 디자인 토큰 / 🖼️ 에셋 / 🧩 컴포넌트 / 📱 데모앱 / 🔧 설정·인프라. 영역은 실제 변경에 맞게 취사선택. 이모지 소제목은 필수 — 빼지 말 것.
• 타입·심볼 이름을 나열하지 않는다. 코드를 보면 바로 알 수 있는 것(만든 타입·프로퍼티 목록)은 제외하고, 무슨 기능인지 / 어떤 정책·규칙·비즈니스 로직을 담았는지 중심으로 쓴다. (정책·규칙은 **입력 정책**, **동시성 정책** 처럼 굵게 라벨링하면 리뷰어가 잡기 쉽다.)
• 각 항목은 - **핵심** — 설명 형태로, 무엇을·왜 바꿨는지 리뷰어가 맥락을 잡을 수 있게 쓴다.
• 값·매핑이 여러 개면 표로 정리한다 (예: 토큰 이름/값).
• 자동 생성물(Colors+.swift, Image+.swift 등)은 개별 나열하지 않고 "런스크립트 생성물, 손편집 안 함"으로 요약.
• 리뷰 포인트는 실제로 고민한 설계 선택·네이밍·확신 없는 부분을 구체적으로. 형식적 문구 금지.
• 테스트/확인 방법은 리뷰어가 재현할 수 있도록 번호 매긴 단계로. 데모앱이 있으면 실행 경로(메뉴 > 하위메뉴)까지 명시.
• 스크린샷 표: UI 변경이 있으면 빈 표를 남기고, 없으면 "해당 없으면 표째 삭제" 안내와 함께 남긴다.
• 톤: 습니다체(정중체)로 통일한다 — "~했습니다 / ~합니다 / 확인 부탁드립니다". 군더더기는 지양하되 팀 컨벤션이 습니다체이므로 해요체·반말은 쓰지 않는다. 기술 용어는 원문 유지.

참고

• 도구로 검증 가능한 사실(변경 파일·라인 수)은 추측하지 말고 git 명령으로 확인한다.
• 커밋/푸시는 하지 않는다. 본문 텍스트만 생성한다.