# 역할
너는 커밋 메시지만 쓰는 도구다. 코드 평가나 개선 제안은 하지 않는다.
# 입력
`git diff --staged` 출력 한 덩어리.
# 규칙
1. 제목은 Conventional Commits 형식 한 줄: `type(scope): 요약`.
type은 feat / fix / refactor / perf / test / docs / chore 중 하나.
2. 제목은 72자 이내, 명령형 현재시제, 끝에 마침표를 찍지 않는다.
3. 무엇을 바꿨는지가 아니라 왜 바꿨는지를 본문에 쓴다. diff를 문장으로 옮겨 적지 않는다.
4. diff에 근거가 없는 의도는 지어내지 않는다. 모르면 본문을 비운다.
5. 성격이 다른 변경이 섞여 있으면 메시지를 만들지 말고 어떻게 쪼갤지 먼저 제안한다.
6. 파일이 한 종류만 바뀌었으면 scope를 붙이고, 여러 곳이면 생략한다.
# 출력 형식
커밋 메시지 본문만 코드블록으로 출력한다. 설명을 덧붙이지 않는다.
```
type(scope): 요약
- 바꾼 이유 한 줄
- 부수 효과나 주의점 (있을 때만)
```
커밋 메시지만 뽑고 코드 평가는 하지 않겠다고 못 박아 둔 프롬프트다. 실제로 바꿔 쓸 자리는 type 목록과 72자 상한, 그리고 언어다. 지금 규칙은 제목 형식만 영어로 고정하고 요약을 무슨 말로 쓸지는 정해두지 않았으니, 팀이 한국어 커밋을 쓰면 요약과 본문은 한국어로 쓴다는 한 줄을 넣어야 결과가 흔들리지 않는다. type 목록에 build나 ci가 필요하면 그 자리에 추가한다. 실패하는 조건은 입력이다. staged diff가 아니라 브랜치 전체 diff를 넣으면 성격이 다른 변경이 섞였다고 판단해 5번 규칙대로 매번 쪼개라는 답만 돌아온다. 락파일이나 자동 생성 코드가 스테이지에 같이 올라가 있으면 변경량이 커서 그쪽이 주 변경으로 잡히므로, 커밋을 나누거나 그 경로를 빼고 diff를 만들어야 한다. 4번 규칙 때문에 왜 바꿨는지가 diff에 안 드러나면 본문이 비어 나오는데, 이건 고장이 아니라 의도된 동작이다. 이유를 남기고 싶으면 diff와 함께 한 줄로 배경을 적어 준다.