| name | commit |
| description | Use when composing a git commit in this project — 커밋 메시지 작성·커밋 구성 시점. 커밋 분할은 이미 결정돼 있다는 전제로 메시지 작성에 집중하고, 미정일 때만 분할 판단 지침을 제공한다. 미푸시 커밋 수정·리뷰 반영의 fixup 흡수 절차 포함. Triggers on "커밋하자", "커밋해줘", "커밋 정리해". Does NOT trigger on PR 본문 작성(pr 스킬), 이슈 작성(issue 스킬), docs/ 문서 작성. |
Commit — 커밋 메시지·구성
일반 글쓰기 원칙(두괄식·간결)은 CLAUDE.md 소관이다. 커밋의 목적은 작업의 맥락 전달 — diff가 보여주는 "무엇"이 아니라 "왜·어디서 동작이 달라졌는가".
메시지 — 주 임무
커밋 분할은 대개 이미 결정돼 있다 (플랜의 커밋 시퀀스, 유저 지시). 이 스킬의 기본 임무는 결정된 단위에 맞는 메시지 작성이다.
- 첫 줄
[#이슈번호] 동작 변화 요약 — 파일/클래스 목록 ❌, 동작이 어떻게 달라졌나 ✅ (예시는 CLAUDE.md §5)
- 본문은 앵커 단위 불릿: 변경된 코드 심볼(
ClassName.methodName)을 앵커로, 한 불릿 = 한 앵커 + 그 변화
- 배경이 상위 PR/이슈에 있으면 커밋에 반복하지 않는다. 단독 커밋(cherry-pick·핫픽스)일 때만 배경 서술
분할이 미정일 때만 — 단위 판단
- 한 커밋 = 한 논리 단위 (한 레이어·한 서사). 중·소 feature는 3~5 커밋 권장 — 과도한 원자화도, 뭉텅이 커밋도 지양.
- TDD 중간 상태(RED/GREEN 과정)는 싣지 않는다 — 리팩터까지 반영된 결과를 묶는다.
공통 절차
- 스테이징(
git add)은 직접 수행한다 — 유저에게 미루지 않는다. 논리 단위에 맞춰 파일을 나눠 담는다.
- 커밋 전 완료 판정(impact-check → 테스트 → 짝 경고 해소)은 implement 스킬이 규정한다.
미푸시 커밋 수정 — 흡수
푸시 전 커밋에 대한 셀프 리뷰·에이전트 리뷰 반영이나 방향 수정은 follow-up 커밋 금지 — 원본 커밋에 흡수한다 (최종 결과물에 수정 노이즈를 남기지 않는다):
- 직전 커밋이면
git commit --amend
- 그 이전 커밋이면:
git add <해당 파일>
git commit --fixup <원본 커밋 sha>
GIT_SEQUENCE_EDITOR=true git rebase -i --autosquash <base>
푸시·PR 공개 이후의 반영(review 스킬 리뷰 반영 포함)은 반대로 별도 커밋 — 리뷰어가 반영분을 추적할 수 있어야 한다.
