옵션

명확하고 가치 전달이 명확한 메시지로 git 커밋을 생성하세요. 사용자가 저장소와 적절한, 가치 전달이 명확한 메시지로 스테이지된 또는 스테이지되지 않은 변경사항을 커밋/저장하도록 요청할 때 사용하세요.

...모든 것을 확장하십시오
15
업데이트 된 시간 2026년 8월 26일

ce-commit 소개

현재 작업 트리를 사용하여 단일하고 정교한 git 커밋을 생성하고, 저장소 관례가 존재할 경우 이를 따르며 그렇지 않을 경우 관례적 커밋 형식을 따르는 가치를 전달하는 메시지를 생성하는 워크플로우입니다. 사용자가 커밋, 변경 사항 저장 또는 스테이징된 또는 스테이징되지 않은 작업에서 커밋 생성을 요청할 때 활성화됩니다. Claude Code에서는 사전에 채워진 git 상태, 작업 트리 diff, 현재 브랜치, 최근 커밋 및 원격 기본 브랜치 섹션을 직접 소비하며, 다른 플랫폼에서는 동일한 컨텍스트를 수집하기 위해 단일 대체 명령을 실행합니다.

이 워크플로우는 다섯 단계로 실행됩니다. 1단계는 컨텍스트를 수집하고 가장자리 사례를 처리합니다: 깨끗한 트리는 커밋할 것이 없음을 의미하며, 분리된 HEAD는 플랫폼의 차단 질문 도구를 통해 기능 브랜치 생성에 대해 사용자에게 묻습니다. 2단계는 우선순위에 따라 메시지 관례를 결정합니다: 문서화된 저장소 관례를 선호한 다음, 최근 10개 커밋에서 추론된 패턴을 따르고, 그렇지 않을 경우 feat, fix, docs, refactor, test, chore, perf, ci, style, build와 같은 유형의 type scope description 형식의 관례적 커밋을 따릅니다. fix와 feat이 모두 적합한 경우 fix를 기본값으로 사용합니다. 3단계는 명확히 구분된 관심사를 별도의 커밋으로 나누는 것을 가볍게 고려하며, 파일 수준에서만 그룹화하고 두세 개의 논리적 커밋을 최적의 범위로 간주합니다.

4단계는 스테이징하고 커밋하며, 현재 브랜치가 main, master 또는 해결된 기본 브랜치인 경우 기본 브랜치에 커밋하기 전에 먼저 기능 브랜치를 자동으로 생성합니다. 메시지는 무엇을보다 왜에 초점을 맞춘 간결한 명령형 주제를 사용하며, 비사소한 변경 사항에 대한 선택적 본문이 포함될 수 있습니다. 스테이징은 민감한 파일을 무작위로 포함하지 않도록 git add all 대신 특정 파일 이름을 명명하는 것을 선호합니다. 커밋은 형식을 보존하기 위해 heredoc으로 작성됩니다. 5단계는 git status를 실행하고 결과 커밋 해시와 주제 줄을 보고하여 성공을 확인합니다.

FAQ

기본 커밋 메시지 형식은 무엇입니까?

문서화된 저장소 관례를 선호한 다음, 최근 10개 커밋에서 추론된 패턴을 따르고, 그렇지 않을 경우 type scope colon description 형식의 관례적 커밋으로 대체합니다.

main 브랜치에 직접 커밋합니까?

아니요. 현재 브랜치가 main, master 또는 해결된 기본 브랜치인 경우, 커밋하기 전에 먼저 기능 브랜치를 자동으로 생성합니다.

fix와 feat 중 언제 선택합니까?

둘 다 적합한 경우 fix를 기본값으로 처리하며, 손상되거나 누락된 동작을 수정하는 변경은 fix로 간주하고 진정으로 새로운 기능에는 feat을 예약합니다.

변경 사항을 여러 커밋으로 나누습니까?

명확히 구분된 관심사를 가볍게 스캔하며, 파일 수준에서만 그룹화된 별도의 커밋을 생성할 수 있으며, 두세 개의 논리적 커밋을 최적의 범위로 간주합니다.

민감한 파일 커밋을 어떻게 피합니까?

git add -A 또는 git add .을 사용하는 대신 이름으로 특정 파일을 스테이징하는 것을 선호하여 .env 또는 자격 증명과 같은 파일을 실수로 포함하지 않도록 합니다.

GitHub에서 보기

Create well-crafted local commit(s) from the current working tree. No push, no PR — use ce-commit-push-pr for the full ship flow.

Done when: each logical change is committed with an explicit file list and a message that states the outcome, and git status is clean of those changes. Stop when: the tree is clean (nothing to commit).

Context

Gather context with each command as its own shell tool call (program + args only). Do not join with ;, &&, ||, pipes, $(...), or redirects — that syntax fails under Windows PowerShell. A non-zero exit is a normal state to interpret, not a failure to suppress.

CommandPurposeNon-zero / empty means
git statusWorking-tree stateNot a git repo — stop
git diff HEADUncommitted changesUnborn repo / no commits yet
git branch --show-currentCurrent branchEmpty = detached HEAD
git log --oneline -10Recent message styleUnborn repo — no history
git rev-parse --abbrev-ref origin/HEADRemote default branchNo origin/HEAD / bare HEAD — try gh repo view --json defaultBranchRef --jq '.defaultBranchRef.name', else main

Treat this as a snapshot. Re-read branch and staged set immediately before committing if anything may have changed.

Default branch name: strip a leading origin/ from origin/HEAD (so origin/trunktrunk). Use that bare name for all “on the default branch?” checks — never compare against origin/<name>.

Workflow

  1. Gather — run every Context command above (own shell call each), then continue.

  2. Nothing to commit — if git status shows no staged, modified, or untracked files, report that and stop. Do not use git diff HEAD alone as cleanliness (it misses untracked files).

  3. Branch first — if detached HEAD, or on the default branch (main / master / the bare default name above), create a feature branch from the change content (git checkout -b <name>), then re-read git branch --show-current. Do not ask — commit-only still must not leave work only on a detached HEAD or the default branch. If the derived name exists, pick a non-conflicting suffix.

  4. Convention — match project commit conventions already in context; else match the recent log pattern; else conventional commits (type(scope): description). When using conventional commits and fix/feat both fit, default to fix: (remedying broken or missing behavior); reserve feat: for new capabilities. User override wins.

  5. Logical commits — if changed files clearly split into distinct concerns, make separate commits (file level only, 2–3 max, no git add -p). If ambiguous, one commit.

  6. Message — subject is imperative and names the outcome (what is now possible or fixed), not the file list. Body only when motivation or trade-offs are not obvious from the subject. When a plan Implementation Unit ID is already in hand for this commit (conversation, caller, or the files belong to one unit), append that unit's U-ID in parentheses — (U3) means unit 3. Do not hunt for a plan. Omit when the commit spans units, the unit is unclear, or no plan is in hand.

    • Bad: Update checkout.rb / Add tests and fix stuff
    • Good: Fix double-submit on checkout
    • Good: Add per-subscription mute (U3)
  7. Stage and commit — stage named files only (never git add -A or git add .). Honor exclude:<paths> when the invocation carries it: those files stay uncommitted no matter what else changed; say in the report that they were left out. Prefer one shell call per commit group:

git add file1 file2 file3 && git commit -m "$(cat <<'EOF'type(scope): subject line hereOptional body when the why is not obvious from the subject.EOF)" -- file1 file2 file3

The trailing path list on git commit is load-bearing: a bare git commit takes the whole index, so anything already staged before this run (a caller's exclude: paths, or work the user staged and did not name) would ride into the commit. Naming the paths commits exactly the group and leaves other index entries alone.

  1. Confirm — git status; report hash(es) and subject(s).

모든 파일

0개 파일

ce-commit 설치

스킬 파일을 다운로드하여 .claude/skills/ 디렉토리에 추출하세요.

ZIP 다운로드

저장소를 클론하고 스킬 파일을 프로젝트에 복사하세요.

git clone https://github.com/EveryInc/compound-engineering-plugin/blob/main/skills/ce-commit/SKILL.md # Copy SKILL.md to your .claude/skills/ directory

복사 복사
빠른 설정: 스킬 폴더를 .claude/skills/에 복사하세요. Claude가 자동으로 감지하고 사용합니다.

관련 스킬

github-project-management
업데이트 된 시간 2026년 6월 29일
using-git-worktrees
업데이트 된 시간 2026년 6월 29일
readme-blueprint-generator
업데이트 된 시간 2026년 7월 5일
finishing-a-development-branch
업데이트 된 시간 2026년 6월 29일
OR