create-pr

현재 브랜치와 base 브랜치 간의 커밋 변경사항을 분석하고, .github/pull_request_template.md 템플릿을 참고하여 Pull Request를 작성합니다.

Base 브랜치 확인 방법 (중요!)

다음 순서대로 base 브랜치를 확인하세요:

1단계: first-parent merge 커밋에서 대상 브랜치 추출

git --no-pager log --first-parent --oneline -10 HEAD | grep -m1 "Merge branch" | sed -n "s/.*into \([^']*\)$/origin\/\1/p"

• 이 명령은 merge 커밋 메시지의 into <branch> 부분에서 현재 브랜치가 분기된 부모 브랜치를 찾습니다
• 예: Merge branch 'feat/daou-integration-4' into feat/daou-integration-5 → origin/feat/daou-integration-5가 base
• 결과가 있으면 해당 브랜치를 base로 사용하세요

2단계: merge 커밋이 없는 경우 - reflog에서 브랜치 생성 시점 찾기

1단계에서 결과가 없으면, reflog에서 브랜치가 생성된 커밋을 찾고 해당 커밋이 속한 브랜치를 확인하세요:

# 현재 브랜치 이름
CURRENT_BRANCH=$(git --no-pager rev-parse --abbrev-ref HEAD)

# 브랜치 생성 시점의 커밋 해시
CREATION_COMMIT=$(git reflog show $CURRENT_BRANCH | tail -1 | awk '{print $1}')

# 해당 커밋이 속한 remote 브랜치 중 현재 브랜치가 아닌 것
git --no-pager branch -r --contains $CREATION_COMMIT | grep -v $CURRENT_BRANCH | head -1

• 결과가 있으면 해당 브랜치를 base로 사용하세요

3단계: 위 방법들로 찾을 수 없는 경우

2단계에서도 결과가 없으면 origin/master (또는 origin/main)를 기본값으로 사용하세요.

주의: master를 무조건 기본값으로 가정하지 마세요. 반드시 위 명령어들로 먼저 확인하세요.

변경사항 확인

• git diff를 수행할 때는 git --no-pager 옵션을 꼭 사용해주세요.
• 변경사항 확인 시 위에서 확인한 base 브랜치를 사용하세요. 예: git --no-pager diff <base-branch>...HEAD
• 커맨드 실행하고 3초 이상 결과를 기다리면 커맨드를 다시 실행해주세요.

작성 가이드라인

1. 현재 브랜치의 모든 변경사항을 분석하여 PR 내용을 작성
2. .github/pull_request_template.md 파일의 구조와 형식을 반드시 따라야 함
3. 배경 섹션은 간결하게 작성하되, 코드 변경사항이 아닌 비즈니스 맥락을 포함해야 함
4. 설명은 간결해야 함. 코드 스니펫을 붙여넣지 말 것 — 리뷰어는 diff를 직접 읽을 수 있으므로 본문에 코드 블록, 함수 시그니처, 파일 경로 나열을 넣지 않음
5. 디자인 의도(design intent)와 동작 변경(behavior changes)에 집중 — "어떻게 구현했는지"가 아니라 "왜 했고 무엇이 달라지는지"를 서술
6. "작업 내용" 섹션은 최대 3-5개의 불릿으로 제한 — 변경이 많으면 관련 항목끼리 묶어서 요약. 각 불릿은 한 줄로 핵심만
7. 비즈니스 맥락에 대한 정보가 필요한 경우 사용자에게 질문하여 확인
8. 테스트 방법이나 체크리스트가 템플릿에 있다면 해당 항목도 작성

실행 절차

1. PR 템플릿(.github/pull_request_template.md)을 먼저 확인
2. Base 브랜치를 위의 방법으로 확인
3. git --no-pager diff <base-branch>...HEAD로 변경사항 분석
4. 필요한 비즈니스 맥락이 있다면 사용자에게 질문
5. 완성도 높은 PR 설명 작성
6. gh pr create --title "<제목>" --base <base-branch> --body "<본문>"으로 PR 생성

예시

## 배경
> Linear: [TICKET-123](https://linear.app/team/issue/TICKET-123)

<비즈니스 맥락: 왜 이 변경이 필요한지 1-2문장>

## 작업 내용
- <사용자 관점의 동작 변경 또는 디자인 의도 1>
- <사용자 관점의 동작 변경 또는 디자인 의도 2>
- <사용자 관점의 동작 변경 또는 디자인 의도 3>

## 참고사항
- <관련 문서, 주의사항 등>

주의: 불릿에 코드 스니펫, 함수 시그니처, 파일 경로 나열을 포함하지 말 것. 구현 세부는 diff가 말해주므로 "왜 / 어떤 효과" 관점으로만 요약.