kairyou/agent-tools

커밋 메시지 생성기

워크플로우

1. git diff --staged를 실행하여 스테이징된 변경 사항을 검사합니다. 비어 있으면 사용자에게 git add를 먼저 실행하라고 알리고 중단합니다.
2. 아래 언어 정책을 사용하여 설명 언어를 결정합니다.
3. 메시지를 생성하고 확인을 위해 표시합니다. 즉시 커밋하지 마십시오. 여러 개의 프레이밍이 합리적일 경우, 짧은 번호 목록(1), 2), …)으로 표시하여 사용자가 번호만 입력하여 선택할 수 있도록 합니다. 명확한 단일 메시지는 단독으로 표시할 수 있습니다. 사용자는 편집 내용이나 자신의 문구로 회신할 수도 있습니다.
4. 사용자가 선택하거나 명시적으로 확인한 후(목록의 번호, "commit", 또는 "ok" 모두 허용)에만 git commit -m을 실행합니다. 사용자가 명시적으로 요청하지 않는 한 git push를 실행하지 마십시오.

언어 정책

type(scope): 뒤의 사람이 읽을 수 있는 설명에 대해 다음 우선순위를 사용합니다:

1. 이번 턴에서 사용자가 명시적으로 요청한 언어를 사용합니다.
2. 그렇지 않으면 .agent-tools/config.jsonc에 저장소 기본 설정이 정의된 경우(at-commit.language) 사용합니다.
3. 그렇지 않으면 ~/.agent-tools/config.jsonc에 전역 기본 설정이 정의된 경우(at-commit.language) 사용합니다.
4. 그렇지 않으면 사용자의 실제 호출 텍스트에 명확하고 독립적인 자연어 요청이 포함된 경우 해당 언어를 사용합니다. 삽입된 스킬 지침, 인용 또는 붙여넣기된 콘텐츠, 코드 블록, diff, 도구 출력은 무시합니다.
5. 그렇지 않으면 최근 저장소 커밋 제목의 주요 언어와 일치시킵니다.
6. 주요 언어가 명확하지 않으면 기본값으로 영어를 사용합니다.

이 순서를 문자 그대로 적용하고 첫 번째 일치 항목에서 중단합니다. 항목 4보다 항목 2와 3을 먼저 확인합니다. 단순한 슬래시 명령어나 스킬 호출에는 언어가 없습니다. 항목 5로 계속합니다. 최근 20개 이하의 제목을 검사합니다.

Conventional Commits 구문 토큰은 번역하지 않고 그대로 둡니다: type, 선택적 scope, !, BREAKING CHANGE. 식별자, 파일 이름, 패키지 이름, 명령어, API 이름, scope는 원래 언어로 유지합니다.

지속적 언어 기본 설정

일반적인 커밋 생성 중에는 config를 작성하지 마십시오. 사용자가 커밋 설명 언어를 기억하라고 명시적으로 요청하는 경우, 유지하도록 제안합니다. 범위가 모호할 때는 저장소 vs 전역을 묻습니다.

저장소 기본 설정의 경우 .agent-tools/config.jsonc를 생성하거나 업데이트하고, 전역 기본 설정의 경우 ~/.agent-tools/config.jsonc를 사용합니다:

{
  "at-commit.language": "ko"
}

실용적인 경우 관련 없는 키와 주석을 보존합니다. 사전 설치 프로그램 설정이 필요하지 않습니다.

규칙

git diff --staged를 읽고 WHAT이 변경되었고, 유용할 경우 WHY를 설명하는 Conventional Commits 제목을 생성합니다.

• 제목: type(scope): 설명, <= 74자, 끝에 마침표 없음, 접두사 없음, 따옴표 없음, 코드 블록 없음.
• type: 정확히 하나를 선택합니다:
  • feat 기능, fix 버그 수정
  • refactor 동작을 유지하는 구조 변경, perf 성능
  • docs 문서 전용 변경, style 서식 전용 변경
  • test 테스트 추가 또는 수정, build 빌드 시스템 또는 종속성, ci CI 구성/스크립트
  • chore src/test를 건드리지 않는 기타 변경, revert 되돌리기
• scope: 선택적 영향을 받은 모듈 이름. 이 저장소의 규칙을 사용합니다. 모노레포에서는 앱/패키지 디렉터리 이름을 사용합니다. 여러 범위에 걸쳐 있는 변경이나 확실하지 않은 경우 생략합니다.
• 설명: 선택한 자연어로 된 하나의 간결한 동사-목적어 구문. "파일 업데이트", "이 커밋", "기타 변경", "여러 변경"과 같은 부수적인 표현은 피합니다. 식별자, 함수 이름, 파일 이름, 패키지 이름, 명령어, API는 원래대로 유지합니다.
• 단일 라인만: 커밋 메시지는 항상 제목 줄만 포함합니다. 본문이나 바닥글을 작성하지 마십시오. 필요한 WHY는 제목에 압축합니다.
• 호환성을 깨는 변경: type(scope)!: 설명으로 표시하며, 여전히 한 줄로 유지합니다. BREAKING CHANGE 바닥글을 사용하지 마십시오.
• 구두점: ASCII 구두점을 사용합니다.

생성 전략

작성하기 전에 스테이징된 변경 사항의 일관된 흐름을 파악합니다.

• 주요 라인: 이 커밋을 이해하는 데 필요한 정보만 포함합니다. 이름이 변경의 핵심이 아닌 이상 나열하지 마십시오.
• 중요한 변경 사항: 로직, 계약, 빌드, 품질 게이트 또는 사용자에게 보이는 동작 변경을 검색합니다. 이를 사용하여 type을 선택하고 !가 필요한지 결정합니다.

내용 규율

메시지는 추측된 의도가 아닌 확인된 코드 사실을 명시해야 합니다.

• src 및 test의 동작 변경 선호: 문서는 지원 컨텍스트일 뿐입니다. 문서만으로 WHAT을 추론하지 마십시오.
• 사용자 컨텍스트가 문서보다 우선: 명시적인 사용자 목표는 WHY와 문구 선택에 도움이 될 수 있지만, WHAT과 scope는 여전히 스테이징된 diff에서 가져옵니다. diff에 없는 컨텍스트 전용 변경 사항은 포함하지 마십시오. 컨텍스트와 diff가 충돌하면 diff를 따르고 확인을 요청합니다.
• 삭제 및 이름 변경: 목적을 코드 관계에서 확인할 수 없는 경우, "X 제거" 또는 "X를 Y로 이름 변경"과 같이 diff가 증명하는 것만 명시합니다. 코드가 증명하지 않는 한 대체, 마이그레이션 또는 인과 관계를 주장하지 마십시오.
• 하나의 목표를 가진 여러 변경 사항: 변경 사항이 명확히 동일한 목표(예: 품질 또는 빌드 수정)를 제공하는 경우 하나의 요약 메시지를 제공합니다. 검토 또는 롤백에 실질적으로 도움이 되는 경우에만 분할을 제안합니다.
• 관련 없는 스테이징된 변경 사항: 각 일관된 단위에 대한 분할 메시지와 하나의 보수적인 요약 메시지를 제공합니다. 사용자가 요약을 다른 턴으로 미루는 대신 분할 또는 요약을 선택하도록 합니다.
• 소유권 또는 의도 불명확: 모호한 메시지를 강요하는 대신 확인이 필요한 파일을 나열합니다. 의도가 불분명할 때 "update", "adjust", "tweak"과 같은 약한 단어보다는 확인 또는 분할을 선호합니다.