Commit & PR 자동화

작업 트리의 변경사항(diff)을 깔끔한 커밋으로, 필요하면 바로 리뷰 가능한 GitHub Pull Request로 변환합니다 — 매번 사용자가 커밋 메시지 문구나 PR 상투문을 직접 불러줄 필요가 없습니다.

이 스킬을 언제 쓰는가

• 사용자가 변경사항 커밋을 요청할 때 ("커밋해줘", "commit this", "얘 커밋 좀")
• 사용자가 커밋 메시지만 요청할 때 ("커밋 메시지 뭐라고 쓸까")
• 사용자가 PR 오픈을 요청할 때 ("PR 만들어줘", "pull request 올려줘", "ship this")
• 사용자가 커밋과 PR을 한 번에 요청할 때 ("커밋하고 PR까지 올려줘")

git commit이 무엇을 하는지 설명하기 위해서나, 읽기 전용 히스토리 질문(git log, git blame)에는 이 스킬을 사용하지 않습니다 — 자동화가 필요 없는 경우입니다.

전제 조건 — 작업 전에 반드시 확인

1. git 저장소인지 확인: git rev-parse --is-inside-work-tree. 아니라면 멈추고 사용자에게 알립니다.
2. PR이 요청된 경우 gh가 설치되어 있고 인증되어 있는지 확인: gh auth status. 인증되어 있지 않다면 멈추고 사용자에게 gh auth login을 실행하라고 안내합니다 — 대신 로그인을 시도하지 않습니다.
3. git status --porcelain과 git branch --show-current를 실행합니다.
   • 커밋할 것이 없다면 그렇게 알리고 멈춥니다.
   • 현재 브랜치가 저장소의 기본 브랜치(main/master, 또는 git symbolic-ref refs/remotes/origin/HEAD가 가리키는 브랜치)라면 그 브랜치에 직접 커밋하지 않습니다. 사용자가 명시적으로 기본 브랜치에 커밋하라고 하지 않는 한, 먼저 새 브랜치를 만듭니다 (git checkout -b <type>/<short-slug>).

1단계 — Diff 파악하기

git status
git diff            # 비스테이징
git diff --staged   # 스테이징

• 스테이징된 것이 없고 사용자가 어떤 파일인지 지정하지 않았다면, 전체를 스테이징할지(git add -A) 특정 파일만 할지 물어봅니다 — 관련 없는 변경사항이 섞여 있는 저장소에서는 임의로 판단하지 않습니다.
• 변경사항이 무엇을 바꿨는지뿐 아니라 왜 바뀌었는지 설명할 수 있을 만큼 diff를 읽습니다. diff만으로 의도가 명확하지 않다면(예: 한 줄짜리 설정값 변경) 근거를 지어내지 말고 사용자에게 물어봅니다.

2단계 — 커밋 메시지 작성

Conventional Commits 형식을 사용합니다:

<type>(<scope>): <72자 이내의 짧은 명령형 요약>

<본문: 이 변경이 왜 필요한지 — diff를 다시 설명하는 게 아니라. 약 72열에서 줄바꿈>

<선택적 푸터: BREAKING CHANGE:, Fixes #123, refs>

타입 참고표:

규칙:

• 요약 줄: 명령형("add", "added"/"adds"가 아님)으로 쓰고, 마침표를 붙이지 않습니다.
• 저장소의 기존 git log 히스토리가 Conventional Commits를 명백히 쓰지 않는 경우에만 타입 접두사를 생략합니다 — 새 규칙을 강요하지 말고 저장소의 실제 관례를 따릅니다.
• diff에 명백히 무관한 변경사항이 섞여 있다면, 하나의 메시지로 둘 다 아우르려 하지 말고 사용자에게 알려 커밋을 분리하도록 제안합니다.
• 티켓/이슈 번호를 지어내지 않습니다 — 사용자가 직접 알려준 경우에만 Fixes #N을 추가합니다.
• 이 세션 자체의 지침이 지정한 커밋 메시지 어트리뷰션 푸터를 그대로 덧붙입니다(Claude Code는 Co-Authored-By: / 세션 링크 푸터를 자동으로 덧붙입니다) — 위 템플릿에 나와 있지 않다고 해서 빼지 않습니다.

3단계 — 커밋

git add -A            # 또는 1단계에서 합의한 특정 파일들
git commit -m "$(cat <<'EOF'
<type>(<scope>): <summary>

<body>
EOF
)"

• 사용자가 명시적으로 요청하지 않는 한 --no-verify로 훅을 건너뛰지 않습니다.
• pre-commit 훅이 실패하면 근본 원인을 고치거나(혹은 보고하거나) 합니다 — 우회하지 않습니다.
• 이미 푸시/공유된 커밋에는 사용자가 명시적으로 요청하지 않는 한 git commit --amend를 사용하지 않습니다.

4단계 — 푸시

git push -u origin <branch-name>

• 사용자가 명시적으로 요청하지 않는 한, 그리고 다른 사람의 작업을 덮어쓰지 않는다는 것을 확인하지 않는 한 --force(또는 --force-with-lease)를 사용하지 않습니다.

5단계 — PR 열기 (사용자가 PR을 요청한 경우만)

gh pr create --title "<커밋과 동일하거나 조금 더 풍부한 제목>" --body "$(cat <<'EOF'
## Summary
- <리뷰어가 훑어볼 수 있는 1~3개 불릿: 무엇이, 왜 바뀌었는지>

## Changes
- <논리적으로 묶은, 주목할 만한 변경 파일/영역>

## Test Plan
- <어떻게 검증했는지: 실행한 테스트, 수동 확인 절차, 또는 이유를 밝힌 "N/A">
EOF
)"

• 베이스 브랜치: 사용자가 다른 대상을 지정하지 않는 한 저장소의 기본 브랜치를 기본값으로 합니다.
• 해당 브랜치에 이미 열린 PR이 있다면, 중복 생성 대신 업데이트합니다 (gh pr edit) — 먼저 gh pr list --head <branch>로 확인합니다.
• Draft PR: 작업이 미완성/리뷰 준비가 안 됐다고 사용자가 말하면 --draft를 붙입니다.
• 생성 후에는 gh pr create의 출력에서 PR URL을 그대로 전달합니다 — 직접 조립하지 않습니다.
• 사용자가 명시적으로 요청하지 않는 한 PR을 직접 머지(gh pr merge)하지 않습니다.
• 이 세션 자체의 지침이 지정한 PR 본문 어트리뷰션 푸터를 그대로 덧붙입니다(Claude Code는 "Generated with Claude Code" 푸터를 자동으로 덧붙입니다).

안전장치

• 위험하거나 되돌리기 어려운 작업(force-push, 이미 푸시된 커밋의 amend, 머지, 기본 브랜치에 직접 커밋) 전에는, 이번 세션에서 사용자가 이미 승인한 경우가 아니라면 반드시 먼저 물어봅니다.
• git diff에 시크릿/자격증명이 추가되는 것이 보이면, 커밋 대신 멈추고 이를 알립니다.
• 커밋 메시지와 PR 설명은 실제로 무엇을 테스트했는지 정직하게 기록합니다 — 실행하지 않은 테스트 계획을 있는 것처럼 주장하지 않습니다.