Skill commit all

/commit-all

🤖 skill-archive 워크플로가 레포 원본에서 자동 생성한 페이지예요. 위키에서 직접 고치면 다음 동기화 때 덮어써지니, 수정은 원본 파일에서 PR로 해주세요.

전체 Git 변경을 WSS 양식으로 커밋(선택적 분할)

언제 쓰나

WSS-iOS-V2 프로젝트에서, 현재 Git 변경 전부를 스테이징해 커밋할 때 사용한다. 개수를 지정하지 않아도 무관한 개념이 섞여 있으면 자동으로 나눠 커밋하며, 사용자가 개수를 지정하면 그 개수를 강제한다. "전부 커밋", "다 커밋해줘", "/commit-all", "/commit-all 3" 같은 요청에 트리거. 커밋 양식은 [Type] #이슈 - 내용으로 고정.

• 원본: .claude/skills/commit-all/SKILL.md
• 추가 이유·변경 이력: 아카이브 이슈 (Discord 스레드 링크도 거기 있어요)
• 호출: Claude Code에서 /commit-all 또는 설명의 트리거 문구로 요청

---

Commit All (WSS-iOS-V2)

현재 Git 변경 전부를 스테이징해 커밋한다. 기본 동작은 관심사별 분할이다 — 사용자는 작업을 몰아서 한 뒤 커밋은 여러 개로 나누는 편이고, 커밋 개수를 직접 지정하는 일은 거의 없다. 그러니 개수 인자가 없다고 "한 커밋"으로 기본값을 잡지 말고, 매번 변경을 관심사 단위로 분석해서 몇 개가 나오든 그만큼 나눠 커밋하는 게 정상 동작이다. 스킬명 뒤에 숫자 인자가 오면 그 개수를 강제한다(드문 예외 경로).

인자

• 선택적 커밋 개수: 양의 정수 (예: commit-all 3) — 개수를 강제하고 싶을 때만 준다. 대부분의 호출엔 인자가 없다.
• 개수가 없으면(기본): 개념 그룹 판단 기준으로 변경을 분석해 나오는 관심사 수만큼 커밋한다. 하나면 한 커밋, 여럿이면 그 수만큼 — 개수를 미리 정해두지 않는다. 같은 이슈·같은 세션·같은 PR이라는 이유만으로 서로 다른 관심사를 하나로 뭉치지 않는다.
• 개수가 있으면 변경을 그만큼의 일관된 개념 그룹으로 나눌 수 있을 때만 정확히 그 수만큼 커밋한다.
• 요청한 개수가 부적절·불가능하거나 명확한 개념 그룹으로 못 나누면 멈추고 어떻게 나눌지 사용자에게 묻는다.
• 나눌지 말지, 몇 개로 나눌지 애매하면(개수 지정 여부와 무관하게) 짐작하지 말고 사용자에게 묻는다.

개념 그룹 판단 기준

• 관심사(무엇을 위한 변경인가) 단위로 나눈다 — 레이어·파일 개수·분량 기준 아님. 예: "Novel 엔티티를 BaseDomain으로 이동"과 "검색 Domain 계약을 SearchDomain으로 이동"은 같은 PR·같은 리팩토링이라도 서로 다른 관심사면 별도 커밋.
• 파일 수가 작아도 무관하면 묶지 않는다 — 스테이징되는 파일이 하나뿐이거나 diff가 몇 줄이어도, 관심사가 뚜렷이 구분되면 그 자체로 독립 커밋이다. 반대로 강하게 결합된 변경(나누면 어느 한쪽이 컴파일 안 되는 등)을 억지로 쪼개지 않는다 — 그럴 땐 의도한 분할을 사용자에게 확인한다.
• 커밋 메시지에 "/", "·", "및", "와/과", "그리고" 등으로 서로 다른 변경을 나열해야 제목이 완성된다면, 그 자체가 "이 커밋은 관심사가 두 개 이상 섞였다"는 신호다. 이런 제목이 나오려는 순간 멈추고 스테이징을 다시 쪼갠다 — 절대 그런 제목으로 그냥 커밋하지 않는다. 좋은 제목은 접속사 없이 한 문장으로 "무엇을 했다"가 끝나야 한다.
• 여러 커밋으로 나눌 땐 작업의 논리적 순서로 커밋한다 — 보통 선행(기반이 되는 변경: 엔티티 이동, 계약 정의 등)이 먼저, 그 기반에 의존하는 변경(구현체, 소비자 갱신)이 뒤. 이 순서가 실제 작업 순서와 대개 일치한다.
• 관련 문서(CLAUDE.md) 수정도 그 코드 변경과 짝을 맞춰 같은 커밋에 넣는다. 한 문서 파일 안에 여러 관심사의 편집이 섞여 있으면(예: A 이동과 B 이동을 모두 언급하는 한 문서) 파일 단위가 아니라 해당 문서 안의 편집 조각(hunk) 단위로 쪼개 각 코드 커밋에 짝지어 스테이징한다 — 문서 변경 전부를 하나의 "Docs" 커밋으로 뭉뚱그리지 않는다. 그 어떤 코드 변경과도 무관한 문서 조각(예: 상위 레이어의 모듈 현황 요약)만 별도 Docs 커밋으로 남긴다.
• 사소한 1~2줄짜리 변경(공백 정리 등)을 억지로 쪼개 노이즈 커밋을 만들 필요는 없다 — 인접한 성격의 커밋에 자연스럽게 얹되, 왜 그렇게 판단했는지 간단히 밝힌다.
• 파일 단위로 통째로 스테이징할 수 없을 때(한 파일에 여러 관심사 hunk가 섞임)는 그 파일을 임시로 편집해 해당 커밋에 속할 부분만 남긴 상태로 스테이징 → 커밋 → 나머지 부분을 복원해 다음 커밋에 스테이징, 순서로 처리한다.

커밋 양식 (고정)

[Type] #<이슈번호> - <한글 내용>

예: [Fix] #132 - 작품 평가 뒤로가기 경합 수정

• [Type]: 아래 Type 표에서 각 커밋의 성격에 맞는 하나. 브랜치의 Type과 무관 — 그 커밋의 변경 내용 기준.
• #<이슈번호>: 현재 브랜치명에서 자동 추출한다 (→ 이슈 번호 추출). 분할 커밋이라도 모두 같은 이슈 번호.
• <한글 내용>: 변경을 한 줄로 요약한 한글 설명. 접속사로 두 변경을 잇지 말 것(→ 개념 그룹 판단 기준의 신호 규칙).
• 제목 한 줄로 "왜 이렇게 했는지"가 안 드러나는 커밋(비직관적 이유·숨은 배경·트레이드오프가 있는 경우)은 제목 다음 빈 줄 + 본문으로 설명을 덧붙인다. 자명한 변경엔 본문을 억지로 채우지 않는다 — 필요할 때만.
• 이 양식에서 벗어나지 않는다. 헷갈리면 git log --oneline -8의 실제 커밋들이 진실.

이슈 번호 추출

1. git branch --show-current로 현재 브랜치명을 얻는다 (정규형 <Type>/#<번호>, 예: Feat/#132).
2. 브랜치명에서 # 뒤 숫자, 없으면 마지막 / 뒤 숫자를 이슈 번호로 쓴다.
3. 추출 실패 시 → git log --oneline -8에서 최근 커밋의 #번호를 재사용하거나, 모호하면 사용자에게 묻는다. 지어내지 않는다.

절차

1. 전체 변경 파악:

   • git status --short 실행.
   • unstaged 추적 변경은 git diff --stat, 이미 스테이징된 변경은 git diff --cached --stat로 확인.
   • git status --short에서 untracked 파일도 메모.

2. 이슈 번호 확보: 위 이슈 번호 추출 절차 수행.

3. 커밋 그룹 결정:

   • 개수 지정 여부와 무관하게 파일 경로·diff를 충분히 보고 개념 그룹 판단 기준에 따라 그룹을 정한다.
   • 개수 미지정 시: 관심사가 하나면 한 커밋, 여러 개면 그 수만큼. 임의로 "일단 하나로 합친다"고 가정하지 않는다.
   • 개수가 있으면 그만큼의 일관된 개념 그룹(독립적 기능/수정/문서/테스트/도구 등)으로 묶을 수 있는지 확인한다.
   • 파일 수 균형이 아니라 동작·소유 단위로 묶는다. 강하게 결합된 변경을 개수 맞추려 쪼개지 말고, 그럴 땐 의도한 분할을 사용자에게 묻는다.
   • 개념적으로 무관한 변경은 파일 수·분량이 작아도 같은 커밋에 묶지 않는다. "같은 레이어"·"둘 다 사소함"은 묶는 근거가 아니다 — 관심사(그 변경이 왜 존재하는가)가 다르면 별도 그룹. (2026-07-20, NovelGenre.searchGenre 추가 ↔ WhiteRemovableKeywordChip 캡슐 패턴 개선을 한 커밋으로 묶었다가 사용자가 분리 요청.)
   • 관련 CLAUDE.md 문서 수정은 그 코드 변경과 짝지어 같은 커밋에 포함한다. 여러 관심사의 문서 변경을 하나의 "Docs" 커밋으로 뭉뚱그리지 않는다 — 다만 특정 코드 변경 하나에 안 묶이는 상위 요약성 문서 수정(예: 상위 레이어 CLAUDE.md의 모듈 현황 한 줄)은 별도 Docs 커밋으로 남겨도 된다.
   • 1줄짜리 사소한 변경(공백 정리 등)까지 억지로 쪼개 노이즈 커밋을 만들 필요는 없다 — 인접한 성격의 그룹에 자연스럽게 얹되, 왜 그렇게 판단했는지 보고에 한 줄 남긴다.

4. 스테이징 & 커밋:

   • 스테이징·unstaged·untracked 변경이 하나도 없으면 커밋하지 말고 알린다.
   • 단일 커밋: git add -A 후 스테이징 diff를 검토하고 커밋.
   • 분할 커밋: 각 그룹을 명시적 pathspec으로 따로 스테이징. 이미 스테이징돼 있던 변경도 올바른 그룹에 포함시킨다.
   • 인덱스에 이미 여러 그룹의 변경이 섞여 있어 그대로 커밋하면 안 되는 경우, 스테이징을 조정하기 전에 멈추고 묻는다.
   • 각 커밋 전 git status --short, git diff --cached --stat, git diff --cached --name-only 실행. 필요 시 git diff --cached로 제목 근거 확인.
   • 각 그룹을 git commit -m "[Type] #번호 - 내용"으로 커밋. 본문이 필요한 경우(위 커밋 양식 기준) -m 두 번(제목/본문) 또는 heredoc으로 빈 줄을 두고 본문을 덧붙인다.
   • 샌드박스가 .git 쓰기를 막으면 좁은 사유를 달아 권한 상승 후 같은 명령 재시도.

5. 검증:

   • git status --short, 만든 커밋 수만큼 git log --oneline -n <count> 실행.
   • 각 커밋 해시·제목, 워크트리가 깨끗하지 않으면 남은 파일을 보고한다.

Type 표

각 커밋의 [Type]은 반드시 ../commit-types.md를 읽어 그 표에서 해당 커밋의 성격에 맞는 하나를 고른다. 표를 여기 복제하지 않는다 — 그 파일이 단일 진실 소스다. 커밋 헤더에서는 대괄호로 감싼다([Feat] 등).

안전 규칙

• 관심사가 하나뿐이라 단일 커밋으로 결론 났을 때만 git add -A를 쓴다. 그 외(분할이 필요한 경우)는 그룹별 pathspec으로 선택 스테이징한다.
• 사용자의 변경을 보존한다. 스테이징을 비우려 git reset·git checkout 같은 파괴적 명령을 쓰지 말고, 의도한 그룹을 직접 스테이징한다.
• 사용자가 명시적으로 요청하지 않는 한 git reset·git checkout 등 파괴적 명령 금지.
• 워크트리에 명백히 무관하거나 위험한 생성 산출물이 섞여 있으면 멈추고 커밋 전에 묻는다.