---
description: 현재 변경사항을 백엔드 커밋 컨벤션에 맞는 메시지로 정리한다.
---

현재 변경사항을 분석하고 백엔드 개발 맥락에 맞는 한 줄 커밋 메시지를 작성한다.

## 작업 절차

1. 프롬프트에 제공된 변경 파일 목록과 diff 참조를 확인한다.
2. 신규 파일이 있으면 파일 내용을 열어 변경 목적과 도메인을 파악한다.
3. 백엔드 모듈, API, 배치, 인프라, 공통 라이브러리 중 어디에 속하는 변경인지 먼저 판단한다.
4. 아래 컨벤션에 맞는 커밋 메시지를 작성한다.
5. 스테이징과 커밋 실행은 `/commit` 명령 실행 흐름에 맡긴다.

## 커밋 컨벤션

```
<타입>[범위(선택)]: <설명> [(SR 번호, 선택)]
```

### 타입

| 타입 | 설명 |
|------|------|
| `feat` | 새 기능 추가 |
| `fix` | 버그 수정 |
| `refactor` | 기능 변경 없는 구조 개선 |
| `chore` | 빌드, 설정, 의존성, 스크립트 변경 |
| `docs` | 문서 수정 |
| `perf` | 성능 개선 |
| `test` | 테스트 추가 또는 수정 |
| `style` | 포맷, 공백 등 비기능 스타일 변경 |

### 예시

```bash
git commit -m "feat(contract-api): 계약 상세 조회 API 추가"
git commit -m "fix(batch): 만기 안내 배치 중복 발송 방지"
git commit -m "refactor(common): 예외 변환 로직 분리"
```

## 규칙

- 설명은 한국어로 작성한다.
- 설명은 명령형이 아니라 작업 결과 중심의 짧은 구문으로 작성한다. (예: `예외 처리 보강`, `조회 조건 검증 추가`)
- 범위는 백엔드 도메인 또는 모듈명을 간결하게 작성한다. (예: `contract-api`, `batch`, `common`, `auth`)
- 기술명보다 업무 도메인 범위가 더 명확하면 도메인을 우선한다.
- breaking change는 타입 뒤에 `!` 를 붙인다.
- SR 번호가 있으면 설명 앞에 `(SR-XXXXX)` 를 붙인다.
- 커밋 메시지에 AI 사용 흔적, 리뷰 흔적, 불필요한 부연 설명을 넣지 않는다.
