Skip to content

SKILL.md

Latest commit

 

History

History
124 lines (101 loc) · 4.82 KB

SKILL.md

File metadata and controls

124 lines (101 loc) · 4.82 KB
name commit
description 프로젝트 커밋 컨벤션에 맞춰 변경사항을 스테이징하고 커밋합니다. 커밋을 요청할 때 사용합니다.
argument-hint
JIRA 티켓 번호 또는 커밋 메시지 (선택)

커밋 스킬

프로젝트의 커밋 메시지 컨벤션에 맞춰 변경사항을 스테이징하고 커밋합니다.

커밋 메시지 컨벤션

커밋 메시지 형식:

type(scope): 요약 - 설명

Type 종류:

Type 용도
feat 새로운 기능 또는 기능 개선
fix 버그 수정
update 설정/환경 변경
qa QA 관련 수정 및 조정
refactor 코드 리팩토링
style 스타일만 변경
chore 빌드, 도구 설정 등

Scope:

  • JIRA 티켓 번호 (예: BEGINS-1628)
  • 또는 짧은 기능 키워드 (예: env, sentry)

설명:

  • 한국어로 작성
  • 간결하고 명확하게 작성

커밋 예시:

feat(BEGINS-1628): 초기 상태 설정 - 메뉴 파라미터에 따른 초기 상태 설정 추가
qa(BEGINS-1630): null 체크 - payBalance null/undefined 체크 로직 추가
qa(BEGINS-1626): 스타일 수정 - 결과 후킹 화면 스타일링 변경
update(env): env 설정 - env 설정 변경
fix(sentry): 이미지 스타일 - 결과 페이지 이미지 contain 방식으로 변경

실행 순서

  1. 현재 상태 확인

    • git status로 변경된 파일 확인
    • git branch --show-current로 현재 브랜치명 확인
    • staged 파일이 없을 경우:
      • unstaged 변경사항(수정/추가된 파일)이 있으면 AskUserQuestion 도구로 물어봄: 
        커밋할 staged 파일이 없습니다. 아래 변경사항을 모두 스테이징할까요?
<변경된 파일 목록>
        • "전체 스테이징" 선택 시 아래 명령어를 보여준 후 실행: 
          git add -A
        • "직접 선택" 선택 시 어떤 파일을 스테이징할지 안내 후 중단
        • "취소" 선택 시 중단
      • unstaged 변경사항도 없으면 즉시 중단하고 안내 메시지 출력
    • staged 파일이 있으면 계속 진행
    • git diff --staged로 스테이징된 변경사항 파악

  2. 변경사항 분석

    • diff를 검토하여 무엇이 왜 변경되었는지 파악
    • 적절한 커밋 타입 결정 (feat, fix, qa 등)
    • scope 결정 우선순위: $ARGUMENTS의 JIRA 티켓 번호 > 브랜치명에서 추출한 키워드

  3. 커밋 메시지 작성

    • $ARGUMENTS 파싱 규칙:
      • JIRA 티켓 번호 패턴(BEGINS-xxxx)이 포함되어 있으면 해당 번호를 scope로 사용
      • JIRA 티켓 번호 외에 추가 텍스트가 있으면 해당 내용을 설명으로 사용
      • JIRA 티켓 번호만 있으면 diff를 분석하여 설명을 자동 생성
    • 예시: /commit BEGINS-1630 → type(BEGINS-1630): 요약 - 자동생성 설명
    • 예시: /commit BEGINS-1630 null 체크 추가 → type(BEGINS-1630): 요약 - null 체크 추가
    • type(scope): 요약 - 설명 형식을 따름
    • 요약: 변경의 핵심을 짧게 (2~5단어)
    • 설명: 구체적인 변경 내용

  4. 사용자 확인 (필수)

    • 작성한 커밋 메시지를 사용자에게 보여주고 AskUserQuestion 도구로 확인을 요청
    • "커밋 진행", "메시지 수정" 선택지를 제공
    • 사용자가 "커밋 진행"을 선택해야만 커밋을 실행
    • "메시지 수정"을 선택하면 사용자가 입력한 내용으로 메시지를 수정 후 다시 확인

  5. 커밋

    • 이미 staged된 파일만 커밋 (직접 git add 하지 않음)
    • 커밋 생성

  6. 확인

    • git status로 커밋 성공 여부 확인
    • 커밋 해시와 메시지 출력

  7. 푸시 여부 확인

    • AskUserQuestion 도구로 푸시 여부를 물어봄: 
      커밋이 완료되었습니다. 현재 브랜치를 원격에 푸시할까요?
    • "푸시" 선택 시 아래 명령어를 보여준 후 실행:
      • 원격 브랜치가 이미 있는 경우: 
        git push
      • 원격 브랜치가 없는 경우: 
        git push -u origin <현재 브랜치명>
    • "나중에" 또는 "취소" 선택 시 푸시하지 않고 종료

주의사항

  • 사용자의 명시적 요청 없이 force push나 amend 하지 않음
  • pre-commit hook을 건너뛰지 않음 (--no-verify 사용 금지)
  • pre-commit hook 실패 시 문제를 수정하고 새 커밋을 생성 (amend 금지)
  • 커밋 메시지는 항상 HEREDOC을 사용하여 포맷 유지
  • Co-Authored-By 트레일러를 커밋 메시지에 절대 추가하지 않음