PR Message Generator

이 스킬은 Pull Request 생성 시 브랜치의 모든 변경사항을 분석하여 구조화되고 상세한 한글 PR 메시지를 자동으로 생성합니다.

목적

PR 작성 시 일관된 형식과 충분한 정보를 제공하여 코드 리뷰어가 변경사항을 쉽게 이해하고 검토할 수 있도록 돕습니다.

사용 시점

사용자가 다음과 같은 요청을 할 때 이 스킬을 사용합니다:

• "PR 만들어줘"
• "Pull Request 생성해줘"
• "PR 메시지 작성해줘"
• 또는 Pull Request 생성을 요청하는 모든 경우

PR 메시지 형식

상세한 템플릿은 references/pr-template.md 파일을 참조합니다.

기본 구조:

1. 요약 - 전체 변경사항의 핵심을 2-3문장으로 요약
2. 주요 변경사항 - 중요한 변경 사항을 bullet point로 나열
3. 변경 내용 - 카테고리별로 상세한 변경 내용 정리
4. 테스트 - 테스트 관련 정보 및 검증 방법
5. 스크린샷 - 스크린샷 섹션 (사용자가 직접 추가)
6. 관련 이슈 - 연결된 이슈 번호
7. 완료 - 완료된 작업 체크리스트

작성 프로세스

1. 변경사항 전체 분석

PR 메시지를 작성하기 전에 반드시 다음 정보를 수집합니다:

# 현재 브랜치 확인
git branch --show-current

# base 브랜치(보통 develop)와의 차이 확인
git diff develop...HEAD

# 분기 이후 모든 커밋 히스토리 확인
git log develop..HEAD --oneline

# 분기 이후 커밋 상세 내용 확인
git log develop..HEAD

# 변경된 파일 목록 확인
git diff develop...HEAD --name-status

중요: 최신 커밋만 보지 말고, 분기 시점부터 현재까지의 모든 커밋과 변경사항을 종합적으로 분석해야 합니다.

2. 요약 작성

전체 변경사항의 핵심 목적과 내용을 2-3문장으로 간결하게 요약합니다.

작성 팁:

• 왜 이 PR이 필요한지 (문제 정의)
• 무엇을 구현했는지 (해결 방법)
• 어떤 결과를 얻었는지 (기대 효과)

3. 주요 변경사항 정리

가장 중요한 변경사항 3-7개를 bullet point로 나열합니다.

우선순위:

1. 새로운 기능 추가
2. 주요 리팩터링
3. 버그 수정
4. 성능 개선
5. 설정/빌드 변경

4. 변경 내용 카테고리화

변경사항을 적절한 카테고리로 분류하여 상세히 기술합니다.

카테고리 가이드는 references/category-guide.md를 참조합니다.

일반적인 카테고리:

• 빌드 및 설정 - 라이브러리, 설정 파일, 환경 변수 등
• UI 컴포넌트 - 새로 추가되거나 수정된 UI 컴포넌트
• 비즈니스 로직 - 상태 관리, API 연동, 데이터 처리 등
• 스타일링 - 디자인 토큰, 테마, CSS 등
• 유틸리티 - 공통 함수, 헬퍼, 훅 등
• 문서화 - README, 주석, API 문서 등
• 테스트 - 테스트 코드 추가/수정

프로젝트 타입별 카테고리 예시:

프론트엔드:

• UI 컴포넌트, 페이지, 라우팅, 상태관리, API 연동, 스타일링

백엔드:

• API 엔드포인트, 비즈니스 로직, 데이터베이스, 인증/인가, 미들웨어

5. 테스트 섹션 작성

테스트 관련 정보를 다음과 같이 정리합니다:

## 테스트

### 추가된 테스트

- [ ] 단위 테스트: useAuth 훅 테스트 추가
- [ ] 통합 테스트: 로그인 플로우 E2E 테스트

### 수동 테스트 가이드

1. 로그인 페이지 접속
2. 이메일/비밀번호 입력
3. 로그인 버튼 클릭
4. 대시보드로 리다이렉트 확인

### 테스트 환경

- 로컬 환경에서 테스트 완료
- iOS 시뮬레이터 / Android 에뮬레이터에서 동작 확인

포함할 내용:

• 추가된 자동화 테스트 (단위/통합/E2E)
• 수동 테스트 방법 및 체크리스트
• 테스트 환경 및 확인 사항
• 알려진 제약사항이나 주의사항

6. 스크린샷 섹션 생성

스크린샷 섹션을 다음과 같이 생성합니다:

## 스크린샷

<!-- 여기에 스크린샷을 추가해주세요 -->

사용자가 직접 이미지를 추가할 수 있도록 플레이스홀더만 제공합니다.

7. 관련 이슈 연결

관련된 GitHub 이슈가 있다면 연결합니다:

## 관련 이슈

- #123 - 로그인 기능 구현
- Closes #456 - 인증 버그 수정

키워드 활용:

• Closes #번호 - PR 머지 시 이슈 자동 종료
• Fixes #번호 - 버그 수정 시 사용
• Relates to #번호 - 관련 있지만 종료하지 않음

8. 완료 체크리스트 작성

구현된 기능과 작업을 체크리스트로 정리합니다:

## 완료

- [x] 로그인 UI 컴포넌트 구현
- [x] 인증 API 연동
- [x] 에러 핸들링 추가
- [x] 단위 테스트 작성
- [x] 문서화 완료

체크리스트 항목:

• 구현된 주요 기능
• 추가된 테스트
• 작성된 문서
• 리팩터링된 컴포넌트
• 수정된 버그

카테고리 분류 전략

변경사항을 자동으로 적절한 카테고리로 분류하는 방법:

파일 경로 기반 분류

components/ → UI 컴포넌트
pages/ → 페이지
hooks/ → 커스텀 훅 / 유틸리티
services/ → API 연동 / 비즈니스 로직
utils/ → 유틸리티
styles/ → 스타일링
__tests__/ → 테스트
docs/ → 문서화
config/ → 빌드 및 설정

변경 내용 기반 분류

• 새 파일 추가 → "추가된 컴포넌트/기능"
• 기존 파일 수정 → "변경된 내용"
• 파일 삭제 → "제거된 내용"
• 설정 파일 (package.json, tsconfig.json 등) → "빌드 및 설정"

커밋 메시지 기반 분류

커밋 메시지의 타입(feat, fix, refactor 등)을 참고하여 카테고리를 결정합니다.

프로젝트 타입별 가이드

React Native / 프론트엔드

주요 카테고리:

• 빌드 및 설정
• UI 컴포넌트
• 페이지 / 스크린
• 상태 관리
• API 연동
• 네비게이션 / 라우팅
• 스타일링 / 디자인 시스템
• 유틸리티 / 훅
• 테스트
• 문서화

세부 내용 작성 팁:

• UI 컴포넌트는 props와 주요 기능 설명
• 상태 관리는 어떤 상태를 관리하는지 명시
• API 연동은 엔드포인트와 용도 설명

백엔드

주요 카테고리:

• API 엔드포인트
• 비즈니스 로직
• 데이터베이스 / 모델
• 인증 / 인가
• 미들웨어
• 설정 및 환경변수
• 테스트
• 문서화

세부 내용 작성 팁:

• API는 메서드, 경로, 파라미터 설명
• DB 변경사항은 마이그레이션 포함 여부 명시
• 성능 관련 변경은 측정 결과 포함

품질 체크리스트

PR 메시지 작성 후 다음 사항을 확인합니다:

• 요약이 변경사항의 핵심을 담고 있는가?
• 주요 변경사항이 우선순위에 따라 정리되었는가?
• 모든 변경 파일이 적절한 카테고리에 포함되었는가?
• 테스트 섹션이 충분한 정보를 담고 있는가?
• 관련 이슈가 올바르게 연결되었는가?
• 완료 체크리스트가 실제 작업 내용과 일치하는가?
• 한글로 작성되었는가?
• 리뷰어가 이해하기 쉬운 구조인가?

주의사항

1. 전체 변경사항 파악: 최신 커밋만 보지 말고 분기 시점부터의 모든 변경사항을 분석합니다.

2. 중복 방지: 같은 내용이 여러 섹션에 중복되지 않도록 합니다.

3. 적절한 분량: 너무 간략하거나 너무 장황하지 않게 균형을 맞춥니다.

4. 리뷰어 관점: 리뷰어가 무엇을 확인해야 하는지 명확히 알 수 있도록 작성합니다.

5. 일관성: 동일한 프로젝트 내에서는 비슷한 형식과 카테고리를 유지합니다.

예시

상세한 예시는 references/pr-examples.md를 참조합니다.