Prompt file imported from guesung/Web-Memo (.claude/commands/pr.md). Fill in {{arguments}} before use. Copyright stays with the author.

/pr — 현재 작업을 master 대상 Draft PR로 올리기

이 파일은 전역 ~/.claude/commands/pr.md를 오버라이드합니다. 이 레포의 PR base는 develop이 아니라 master입니다. (참고: docs/branch-strategy.md)

동작

1. git branch --show-current로 현재 브랜치를 확인한다.
2. 현재 브랜치가 master이면, 먼저 /branch-new 동작을 수행하여 새 브랜치로 옮긴다.
   • 인자({{arguments}})가 있으면 그 문구를 /branch-new의 브랜치명 힌트로 전달한다.
3. 현재 브랜치가 develop이면 중단한다. develop은 테스트 전용 브랜치이므로 PR의 head가 될 수 없다. 사용자에게 원래 작업 브랜치로 이동하라고 안내한다.
4. master 이후의 커밋과 diff를 확인한다 (병렬 실행):
   • git status
   • git diff
   • git log master..HEAD
   • git diff master...HEAD
   • 원격 추적 상태 확인 후 필요 시 git push -u origin <branch>로 업로드한다.
5. 모든 커밋을 훑어서 PR 제목/본문을 작성한다 (최신 커밋만 보지 말 것).
   • 제목: 70자 이내의 짧고 명확한 한글 문장. 상세는 본문에.
   • 제목 맨 앞에 작업 카드 번호를 [DB-000] 형태로 붙인다. 사용자가 대화 중 DB-843 같은 번호를 언급했다면 그것을 쓴다. 번호를 모르면 PR을 만들기 전에 사용자에게 물어본다. 번호 없이 올리거나 임의로 지어내지 않는다. 사용자가 "없다"고 하면 접두사 없이 진행한다.
   • 본문은 레포의 PULL_REQUEST_TEMPLATE.md를 따르며, HEREDOC으로 전달한다.
6. gh pr create --draft --base master --title "..." --body "$(cat <<'EOF' ... EOF)" 로 Draft PR을 생성한다.
7. 생성된 PR URL을 사용자에게 반환한다. 리뷰 준비가 되면 gh pr ready <번호>로 전환하면 된다는 것도 함께 안내한다.
8. 이어서 /ai-review를 실행한다. 사용자가 따로 요청하지 않아도 기본 동작이다.

/ai-review 자동 실행 (8단계)

master 브랜치 보호가 봇 승인 2개를 요구하고, 봇은 자기가 질문을 던진 PR만 승인한다 (cli.ts approve가 질문 0건이면 승인을 거부한다). 그래서 질문 게시는 선택이 아니라 머지로 가는 경로의 첫 단계다. 여기서 실행하지 않으면 나중에 머지하려는 시점에 막힌다.

지금 실행해야 하는 이유는 타이밍에도 있다. /ai-review는 headRefOid와 로컬 HEAD가 같아야 하는데(다르면 라인 번호가 어긋나 코멘트가 전부 422로 죽는다), PR을 막 만든 직후가 그 조건이 자연히 성립하는 시점이다. 미루면 그 사이 커밋이 쌓여 다시 push해야 한다.

• 사용자가 "리뷰는 나중에"라고 명시하면 건너뛴다. 이때는 머지하려면 /ai-review부터 다시 시작해야 한다는 것을 함께 알린다.
• Draft 상태여도 리뷰 코멘트는 정상적으로 달린다. Ready 전환을 기다릴 필요가 없다.

주의

• **base 브랜치는 항상 master**다. --base develop은 이 레포에서 금지다.
• PR은 항상 Draft로 생성한다(--draft). 사용자가 명시적으로 "바로 리뷰 요청"이나 "ready로 올려줘"라고 하지 않는 한 예외 없다. Ready 전환은 사용자가 직접 판단한다.
• 작업 카드 번호 접두사: PR 제목은 [DB-843] <제목> 형태로 만든다. 사용자가 번호를 말하지 않았다면 PR 생성 전에 반드시 물어본다. 추측하거나 생략하고 올리지 않는다. 이후 대화에서도 같은 작업 맥락이면 같은 번호를 계속 쓴다.
• 머지는 머지 커밋 방식(gh pr merge --merge)이다. Squash & Merge와 Rebase & Merge는 금지 — 개별 커밋 히스토리를 master에 보존한다.
• develop에 이미 머지해서 테스트 서버에서 확인했더라도, 작업은 끝난 게 아니다. 반드시 별도로 master 대상 PR을 올려야 한다.
• co-author, 생성 표식, 🤖 같은 메타 표기 추가 금지.
• --force 푸시 금지 (사용자가 명시 요청하지 않은 이상).
• 커밋되지 않은 변경사항이 있다면 먼저 /commit을 제안하고, 사용자가 확인한 후 진행한다.

인자

{{arguments}} — PR 제목/본문에 대한 추가 지시, 또는 master에서 파생 시 새 브랜치명 힌트 (선택).