sg-commitlisted

# Git 커밋 메시지 작성 ## 절차 1. Agent 지침, 기여 문서와 README, commit template·commitlint 설정, 최근 커밋 순으로 대상 프로젝트의 규약을 확인한다. 명시된 규칙을 과거 경향보다 우선하고, 충돌하는 규칙을 임의로 혼합하지 않는다. 2. `git status --short`와 staged diff를 확인해 변경 목적과 범위를 파악한다. 필요하면 변경 전 동작, 관련 테스트·문서와 최근 이력을 대조한다. staged 변경이 없으면 사용자가 지정한 diff나 설명을 근거로 삼았음을 밝힌다. 비밀값이나 개인정보를 메시지에 옮기지 않는다. 3. 독립적인 목적이 섞였으면 커밋 분리를 권한다. 하나의 커밋으로 작성할 때는 주된 의도를 기준으로 제목을 정한다. 4. diff로 확인할 수 없는 문제·제약·선택 이유가 메시지 품질을 좌우하는데 근거가 부족하면 추측하지 말고 사용자에게 묻는다. 제목과 본문은 파일 목록보다 변경 이유와 결과를 설명한다. 5. 프로젝트가 정하지 않은 항목에는 [기본 컨벤션](references/convention.md)을 적용한다. 제목만으로 충분한 변경에 본문을 늘리지 않고, 본문이 필요하면 diff의 재서술보다 문제, 달라진 동작과 비자명한 판단을 우선한다. 6. 완성된 메시지가 하나의 변경 목적을 표현하는지, 제목으로 결과를 예측할 수 있는지, 본문이 근거 있는 맥락만 남기는지 확인한다. 7. Agent가 메시지를 생성하거나 실질적으로 초안을 작성했다면 [기본 컨벤션](references/convention.md)에 따라 현재 실행 중인 Agent의 vendor와 model을 판정한다. 두 식별자가 모두 명시적으로 확인될 때만 철자·대소문자·숫자·구두점을 그대로 보존해 마지막 trailer에 기록한다. 제품명, 모델 계열, 사용 가능한 모델 목록, 과거 커밋을 근거로 추측하지 않는다. 식별자가 없거나 명시된 정보가 충돌하면 trailer를 생략한다. 8. 메시지를 제시하거나 커밋하기 직전에 Agent 식별자의 근거와 trailer를 다시 대조한다. 정확히 일치하지 않으면 trailer를 제거하고, 커밋을 실행한 경우에는 결과를 보고할 때 생략 사실을 알린다. 9. 메시지 작성·검토만 요청받았으면 커밋하지 않는다. 커밋 실행까지 명시적으로 요청받은 경우에만 프로젝트의 보안 검사와 staged diff 검토를 마친 뒤 실행한다. ## 출력 - 기본적으로 바로 사용할 수 있는 커밋 메시지만 Markdown 코드 블록으로 제시한다. - 규약 충돌, 분리 필요성, staged 변경 부재는 메시지와 구분해 짧게 알린다.