auto-commitlisted

# Auto Commit 사용자의 지시를 실행한 후 변경사항을 검증하고, 변경 성격별로 커밋을 나눈 뒤 나중에 읽어도 의도와 안전성이 보이는 메시지로 커밋한다. push는 사용자가 같은 요청에서 명시적으로 지시한 경우에만 수행한다. ## 목적 작업 → 검증 → 커밋 단위 설계 → 좋은 커밋 메시지 작성 → 커밋까지를 하나의 흐름으로 자동화한다. 커밋 메시지는 단순 로그가 아니라 미래의 나와 동료가 변경 의도, 판단 근거, 검증 범위를 이해하는 감사 기록이다. ## 실행 절차 ### 1단계: 작업 실행 사용자가 지시한 작업을 수행한다. 작업 내용은 이 스킬 호출 시 함께 전달된다. ### 2단계: 변경사항 확인 ```bash git status git diff git diff --stat ``` 변경사항이 없으면 "변경사항 없음"을 알리고 종료한다. 다음은 커밋 전에 반드시 확인한다. - 변경 파일이 사용자가 요청한 범위 안에 있는가? - `.env`, credentials, token, secret, private key, 브라우저/커넥터 인증 파일이 포함되지 않았는가? - 이미 있던 사용자 변경과 이번 작업 변경이 섞였는가? - unrelated 변경이 섞였으면 커밋 전에 범위 분리를 제안한다. ### 3단계: 커밋 단위 설계 변경사항을 하나로 뭉치기 전에 먼저 diff를 분류하고, 실제 커밋 계획을 세운다. ```bash git diff --name-status git diff --stat git diff git diff --cached --stat ``` 다음 기준으로 모든 파일과 주요 hunk를 분류한다. - 코드 성격: 기능, 버그 수정, 리팩터링, 테스트, 문서, 설정, 생성물/동기화 산출물 - 변경 의도: 사용자가 요청한 행동을 가능하게 하는 핵심 변경인지, 그 변경을 검증/문서화/정리하는 보조 ��경인지 - 연관 경계: domain/model/schema, API/contract, UI/surface, policy/transaction, test/verification, docs/harness - 실행 순서: 앞 커밋이 뒤 커밋 없이도 의미 있고, 가능하면 빌드/테스트가 깨지지 않는지 커밋 계획은 커밋하기 전에 내부적으로 다음 형태로 만든다. ```text Commit 1: {의도} - 포함: {파일/hunk} - 제외: {다음 커밋으로 넘길 파일/hunk} - 필요 확인: {이 커밋 또는 최종 상태에서 필요한 확인} Commit 2: {의도} - 포함: ... ``` **분할 원칙**: - 변경이 둘 이상의 독립 의도를 가지면 여러 커밋으로 나눈다. - 큰 작업에서 단일 커밋은 예외다. 전체 diff가 하나의 atomic 변경이라고 설명할 수 있을 때만 한 커밋으로 둔다. - 서로 다른 runtime boundary를 건드리면 기본적으로 분리한다. 예: domain/model, API surface, UI, DB migration, test/verification, docs/harn