create-pr

name	create-pr
description	PR을 생성한다. "PR 올려줘", "PR 업로드 해줘", "PR 생성해줘", "PR 만들어줘", "/pr", "풀 리퀘스트" 등 PR 생성이 필요한 모든 상황에서 반드시 이 스킬을 먼저 실행해라. 브랜치 변경사항과 .Codex/plans 계획서를 분석해 PR 본문을 자동 작성하고, 이슈 연결·라벨·리뷰어 지정까지 한 번에 처리한다.
argument-hint	["이슈번호 또는 PR 제목"]

현재 브랜치의 변경사항을 분석하고, PR 템플릿에 맞는 본문을 생성한 뒤 gh pr create로 PR을 올린다.

절차

1. 브랜치 및 이슈 파악

git branch --show-current
git log develop..HEAD --oneline

• 브랜치명에서 이슈 번호를 추출한다 (예: feat/127 → #127, fix/issue-42 → #42)
• 이슈 번호가 있으면 gh issue view <번호>로 제목, 본문, 라벨을 읽는다
• 이슈 번호가 없으면 $ARGUMENTS 또는 대화 컨텍스트에서 파악한다

2. 변경사항 분석

git diff develop...HEAD --stat
git diff develop...HEAD

변경된 모듈과 주요 파일을 파악한다. 어떤 레이어(presentation / domain / data / core)가 변경됐는지 확인한다.

3. 계획서 참조

.Codex/plans/ 디렉토리에 현재 작업과 관련된 계획서가 있는지 확인한다.

• 있으면: 계획서의 목적, 완료 기준, 체크리스트 완료 항목을 Work Description 작성에 반영한다
• 없으면: git diff와 커밋 메시지만으로 Work Description을 작성한다

Work Description은 1~2문단 수준으로 간략하게 작성한다. "무엇을 왜 변경했는가"에 집중한다. 변경 목록을 나열하는 대신 의도와 결과를 설명한다.

4. 라벨 결정

브랜치명 접두사와 이슈 라벨을 조합해 라벨을 하나 선택한다:

브랜치 접두사	라벨
feat/, feature/	feature
fix/	fix
hotfix/	hotfix
refactor/	refactoring
chore/	chore
design/	design
docs/	documentation
improve/, enhance/	enhancement

이슈 라벨이 위 목록에 있으면 그것을 우선한다.

5. 리뷰어 결정

변경된 레이어와 파일을 보고, 리뷰어를 1~2명 선택한다. 팀 협업자 목록: HamBP, leeeyubin

PR 작성자 본인은 리뷰어에서 제외한다. 변경 범위가 넓으면 최대 2명까지만 지정한다.

6. To Reviewers 작성

리뷰어가 집중해서 봐야 할 지점을 2~4개 bullet로 작성한다. 예시:

• 어떤 패턴/아키텍처 결정을 검토해야 하는지
• 사이드이펙트가 있을 수 있는 변경점
• 테스트가 없어 수동 검증이 필요한 부분
• 의존성 변경이나 새로운 라이브러리 도입

7. PR 생성

아래 PR 템플릿 형식을 정확히 따른다:

## Issue
- closed #<이슈번호>

## Work Description
<변경 내용을 1~2문단으로>

## Screenshot
<!-- <img src="이미지 주소" width=270 /> -->

## To Reviewers
- <리뷰 포인트 1>
- <리뷰 포인트 2>
- ...

이슈 번호가 없으면 ## Issue 섹션을 생략한다. 스크린샷은 UI 변경이 없으면 주석 상태 그대로 둔다.

gh pr create \
  --base develop \
  --title "<PR 제목>" \
  --body "$(cat <<'EOF'
<위 템플릿대로 작성한 본문>
EOF
)" \
  --label "<라벨>" \
  --reviewer "<리뷰어1>,<리뷰어2>"

PR 제목은 이슈 제목이 있으면 그것을 기반으로, 없으면 변경 내용을 요약해 작성한다. 한국어로 작성한다.

8. 완료 안내

PR URL을 출력하고, 지정한 리뷰어와 라벨을 한 줄로 확인해 준다.