SKILL.ko.md

name	git-commit
description	사용자가 현재 git 저장소의 변경 사항 전체 또는 지정한 일부를 커밋해 달라고 요청할 때 사용합니다.

변경 범위 결정

1. 진행 중인 merge, rebase, cherry-pick, revert 또는 unmerged 변경이 있으면 중단하고 상태를 보고한다.
2. 사용자가 지정한 범위의 변경을 대상으로 한다. 범위를 지정하지 않으면 commit할 수 있는 모든 변경을 대상으로 한다.
3. references/exclusions.md를 읽는다. 저장소 루트를 기준으로 gitignore 규칙에 따라 패턴을 순서대로 적용한다.
4. 범위 내 staged, unstaged, untracked 변경을 확인한다. 제외된 경로는 staged 상태이거나 사용자가 명시적으로 요청했더라도 commit 대상에 포함하지 않는다.
5. commit할 대상이 없으면 빈 commit을 만들지 않고 중단한 뒤 결과를 보고한다.

commit 생성

1. 프로젝트 규칙에 commit 단위와 메시지에 관한 지침이 각각 있는지 먼저 확인한다. 둘 중 지침이 없는 항목에 대해서만 references/guidelines.md의 해당 부분을 읽고 적용한다.
2. 적용할 commit 단위 지침에 따라 서로 독립적으로 되돌릴 수 있는 변경을 먼저 최대한 atomic하게 구분한다. 각 변경에 필요한 구현, 테스트, 문서를 모아 commit을 구성하고, 다른 변경이 함께 포함되지 않았는지 확인한다.
3. 확정된 모든 commit을 중간 승인이나 계획 확인 없이 생성한다.
4. 각 commit에 포함하기로 정한 변경만 준비하고, worktree나 다른 변경의 staging 상태는 수정하지 않는다. commit 직전에 staged diff에 해당 변경만 포함되어 있고 제외된 경로는 없는지 확인한다.
5. 각 git commit을 별도 명령으로 실행해 종료 상태를 직접 확인하고 hook이 실행되도록 한다. 실패하면 재시도하거나 우회하지 않고 중단하며, 앞서 성공한 commit은 보존한다.
6. commit 후에는 나머지 변경과 staging 상태가 보존됐는지 확인한다.

제한

• commit 생성에 필요한 변경 확인과 git 작업만 수행한다. 테스트, lint, build 등 프로젝트 품질 검사는 직접 실행하지 않는다.
• 절대 --no-verify, --amend를 사용하거나 git 설정을 변경하지 않는다.
• 로컬 commit만 생성하며 push, branch 생성 또는 전환, tag 생성, PR 생성은 하지 않는다.
• API key, token, credential, private key 등의 민감정보는 절대 commit하지 않는다.

결과

• 생성된 각 commit을 - `<짧은 hash>` <subject> 형식으로 한 줄씩 보고한다.
• 제외 규칙, 요청 범위 또는 그 밖의 이유로 commit하지 않고 남겨 둔 변경을 보고한다.
• 실패하면 실패한 단계와 원인을 보고한다.
• 실행한 git 명령과 내부 판단 과정은 생략한다.