옵션
집 Skill Git 및 버전 관리 ce-commit-push-pr

커밋, 푸시, PR 생성. PR을 배포하거나 생성하라는 요청을 받았을 때, 또는 PR 본문을 작성·수정·설명하는 등 PR 설명에만 국한된 작업 흐름에서 사용합니다.

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

소개 ce-commit-push-pr

커밋, 푸시 및 풀 리퀘스트를 생성할 때, 변경 사항의 규모에 따라 설명의 깊이를 자동으로 조절하는 유연하고 가치 중심의 설명을 제공합니다. 이 기능은 '커밋 및 PR', '이것 배포', 'PR 생성' 또는 '풀 리퀘스트 열기'와 같은 요청에 의해 트리거되며, 커밋이나 푸시 없이 'PR 설명 작성'이나 'PR 본문 재작성'과 같은 설명 전용 워크플로우도 처리합니다. 이 기능은 세 가지 모드를 정의합니다: 설명 전용(설명 단계만 실행하고 결과를 출력), 설명 업데이트(기존에 열린 PR의 본문을 새로 고치고 gh pr edit를 통해 적용), 전체 워크플로(모든 단계를 순서대로 실행). 사용자에게 무언가를 물어봐야 할 때는 플랫폼의 차단형 질문 도구를 사용하며, 채팅으로 대체할 수 있습니다.

이 워크플로는 Claude Code에 미리 채워진 섹션이나 다른 곳에서 제공된 컨텍스트 대체 명령어를 사용하여 git 컨텍스트(상태, 작업 트리 diff, 현재 브랜치, 최근 커밋, 원격 기본 브랜치 및 기존 PR)를 수집합니다. 1단계에서는 브랜치와 PR 상태를 파악하고 상황에 따라 경로를 결정합니다. 분리된 HEAD인 경우 기능 브랜치 생성을 요청하고, 작업이 포함된 상태로 기본 브랜치에 있는 경우(기본 브랜치를 직접 푸시하는 것은 지원되지 않으므로) 자동으로 기능 브랜치를 생성하며, 작업이 없는 상태로 기본 브랜치에 있는 경우 중단하고, 기능 브랜치에 있는 경우 계속 진행합니다. 2단계에서는 규칙을 결정합니다. 리포지토리 스타일에 맞춰 컨벤셔널 커밋을 기본값으로 설정하며, 모호한 경우 'feat:'보다 'fix:'를 우선적으로 사용하고, 'feat:'는 진정으로 새로운 기능에만 사용합니다.

3단계에서는 커밋 및 푸시를 수행합니다: 기본 브랜치에 있을 때는 브랜치 생성 가이드를 참조하고, 변경된 파일을 파일 수준에서 최대 두세 개의 논리적 커밋으로 그룹화하며( .env 파일이나 빌드 아티팩트가 포함될 수 있는 git add -p, git add -A 또는 git add . 명령은 피함), git push -u origin HEAD 명령으로 푸시합니다. 4단계: 제목과 본문을 작성합니다. PR 설명 작성에 필요한 참고 자료를 전체적으로 읽고, 증거 여부를 결정합니다. 사용자가 제공한 아티팩트는 ‘Demo’ 항목에 포함시키고, 'Demo', 'Screenshots' 또는 'Evidence' 항목 하에 사용자가 제공한 아티팩트를 포함시키고, 사용자가 증거를 원하지만 제공하지 않은 경우 이를 요청하며, 관찰할 수 없는 변경 사항에 대해서는 증거를 생략하되 관찰 가능한 동작에 대해서는 간결한 검증 메모를 포함시킵니다. 5단계에서는 적용 및 보고를 수행합니다. `gh pr create`를 사용하여 새로운 PR을 생성하거나 `gh pr edit`를 사용하여 기존 PR을 업데이트하며, 업데이트를 적용하기 전에 제목과 본문을 미리 보고, 본문을 임시 파일에 기록합니다.

자주 묻는 질문

이 스킬은 어떤 모드를 지원하나요?

세 가지입니다: 설명 전용(PR 설명만 작성하고 출력), 설명 업데이트(기존의 열린 PR 본문을 재작성하여 적용), 그리고 커밋, 푸시, PR 생성 또는 업데이트를 수행하는 전체 워크플로입니다.

기본 브랜치에 있는 상태에서 실행하면 어떻게 됩니까?

수행할 작업이 있는 경우, 기본 브랜치를 직접 푸시하는 것은 지원되지 않으므로 자동으로 피처 브랜치를 생성합니다. 수행할 작업이 없으면 해당 사실을 알리고 중지합니다.

관례적인 커밋의 경우 ‘fix:’와 ‘feat:’ 중 어떤 것을 사용할지 어떻게 결정하나요?

리포지토리 스타일에 맞춰 결정하며, 기본적으로 컨벤셔널 커밋을 따릅니다. 모호한 경우에는 ‘fix:’를 ‘feat:’보다 우선시하는데, 이는 오류나 누락된 동작을 수정하기 위해 코드를 추가하는 것이 ‘fix’에 해당하기 때문입니다. ‘feat:’는 진정한 새로운 기능에만 사용됩니다.

왜 git add -A와 git add .를 피하나요?

이러한 명령어는 .env, 빌드 아티팩트, 생성된 파일 등을 무차별적으로 포함시키기 때문입니다. 이 도구는 특정 파일을 스테이징하고, 파일 수준에서 변경 사항을 최대 두세 개의 논리적 커밋으로 그룹화합니다.

PR 설명에서 증거는 어떻게 처리되나요?

사용자가 제공한 아티팩트는 ‘데모(Demo)’, ‘스크린샷(Screenshots)’ 또는 ‘증거(Evidence)’ 항목 아래에 포함됩니다. 사용자가 증거를 원하지만 제공하지 않은 경우, 스킬이 이를 요청합니다. 또한 관찰할 수 없는 변경 사항은 증거를 생략하고, 관찰 가능한 동작에 대해서는 검증 메모가 포함됩니다.

모든 파일

3개파일SKILL.md8.6KB보기참조/pr-description-writing.md7.2KB보기참조/branch-creation.md1.8 KB보기
GitHub에서 보기

Asking the user: use the host's blocking question tool — AskUserQuestion in Claude Code (ToolSearch select:AskUserQuestion first if unloaded), request_user_input in Codex, ask_question in Antigravity (agy), ask_user in Pi (needs the pi-ask-user extension). Fall back to the chat surface only when no blocking tool exists or the call errors, never because a schema load is required, and never silently skip the question.

Mode

  • Description-only — the user wants just a description ("write/draft a PR description", "describe this PR", a pasted PR URL or number). Run Step 4 only and print it. Apply it only if asked. Pass any pasted PR ref so Pre-A resolves the range.
  • Description update — refresh or rewrite an existing PR's description, with no commit or push intent. Resolve PR presence by the Context rule below: an exit-0 [] is "no open PR" (report it and stop), and a non-zero exit is unknown (resolve auth or connectivity, then stop until presence is known). With an open PR, run Step 4 in PR mode on that URL, then Step 5 to preview, confirm, and apply via gh pr edit.
  • Full workflow — otherwise: Steps 1-5. Enter Stack mode instead when intent or preference wants a stack.

mode:pipeline modifier, set by orchestrated callers such as lfg. Run the resolved mode non-interactively and suppress every blocking ask; each takes the conservative default: no existing-PR rewrite, the branch kept, an unresolvable base stopping rather than guessed, and a description-update preview applied directly, since that invocation is the apply intent. Pipeline stack mode uses only the intent and scope on the invocation and passes posture into the handoff.

Stack mode (opt-in)

Opt-in only. Enter it when intent or standing preference wants a multi-PR stack. An explicit stack request is required intent — do not re-read it as a single PR with a custom --base. Do not proactively suggest PR stacks. When the user did not ask for one, refuse nonsense stacks (one logical change, artificial slices) and stay single-PR.

In stack mode, load references/stack-submit.md before Step 3 and follow only its probing, topology, and retrospective construction; that layer-by-layer commit flow replaces ordinary Step 3. Do not submit there. Step 5 owns submission, the gh stack CLI dependency and residuals, and the handoff posture: posture:stack-ready by default, posture:stack-land only on explicit land intent, from the bottom open non-draft PR. Do not add posture: to this skill's argument-hint.

Context

Read references/context.md before Step 1. It owns the command table, the exit-code meanings, the fork and detached-HEAD traps, and the branch and PR resolution Steps 1-2 use. Two of its rules belong here too. Never ask whether to branch: a detached HEAD, or the default branch with work on it, creates one, and the default branch with no work reports and stops. And with conventional commits, default to fix: over feat: when ambiguous, unless the user overrides.

Three rules govern the run.

Every git and gh probe is its own argv-form call, gathering and re-verification alike, and its exit status is control flow. The reference gives the reason and names the two compound recipes this skill pins.

Probe output is a snapshot. Re-verify branch, remote, and PR state right before each consequential action: Step 3's push, Step 5's create.

Only an exit-0 [] from a query against the base repo means "no open PR." A non-zero exit is unknown, never "none". On a fork checkout, target the base with -R and pass the branch name only, since --head <owner>:<branch> silently returns []. With results, do not blindly take index 0: match head owner and branch, and stop on an ambiguous match. Note the URL and body from that entry — Step 5 routes on the URL, Step 4 rewrites the existing body.

Artifact Root

Resolve <root> once when archival is on: it writes an explainer under <root>/explainers/.

Resolve the CE artifact root <root> before composing any artifact path.

  • Read docs_root from <repo-root>/.compound-engineering/config.yaml only (<repo-root> = git rev-parse --show-toplevel). Do not read it from config.local.yaml. Unset -> <root> is docs, exactly as before.
  • Validate a set value: a repo-relative directory whose real, symlink-resolved path stays inside the repo and is neither the repo root nor under .git/. Otherwise stop with an error naming docs_root and the value -- never fall back to docs.
  • Use <root> as the sole artifact location: create it if absent, compose each path as <root>/<subdir> with this skill's own subdirectory, and never also read docs.

Step 3: Commit and push

Read references/commit-and-push.md for branch creation, commit grouping, the message and staging shapes, and the push. Branching off the default branch is the fragile case — stale local base, unpushed commits on it, colliding uncommitted changes — and references/branch-creation.md owns that flow. If the stack reference already committed retrospective layers, skip to Step 4; gh stack submit pushes in Step 5.

Two rules bound this step. Never git add -A or git add . — name the files, so .env, build, and generated files cannot ride along, and pass that same path list to git commit, so nothing staged earlier is swept in. Honor exclude:<paths>: those files stay uncommitted and the report says so.

Step 4: Compose the PR title and body

You MUST read references/pr-description-writing.md in full — it owns the title and body content rules, including the rule to preserve an existing Related: / Fixes on rewrite. Then read references/compose.md for the gates before composition: the evidence decision; the teaching gate, where pr_teaching_section defaults on, pr_teaching_archive defaults off, and only an active (non-commented) key changes either; and the branding gate, where branding is off unless this invocation carries branding:on or the user asks for Compound Engineering branding in this prompt.

If Step 1 found an existing PR, pass its URL to Step 4 so PR mode fetches the existing body.

Step 5: Apply and report

Read references/apply-and-handoff.md for the apply routes, preview-before-edit, archival, and handoff. Two rules bound the external writes. Re-run the existing-PR check right before gh pr create and route on it: a matching PR takes the existing-PR path, exit-0 [] creates, non-zero blocks. And pass the body via --body-file <path>, never stdin — gh exits 0 with an empty body.

The completion gate is here. In an interactive full workflow, or in mode:pipeline when this run submitted a stack, a reported PR URL, a stack submit, or new commits on an open PR leave this run not done until ce-babysit-pr owns follow-on for that PR. Reporting the PR URL alone is not success.

The only skips are babysit:off, a standing auto_babysit: false in CE config, and that reference's do-not-fire cases, drafts among them. No other watch substitutes: not ci-watcher, not gh pr checks --watch, not a hand-rolled poll, not "later". If ce-babysit-pr cannot be loaded or started, stop and report it blocked.

모든 파일

0개 파일

ce-commit-push-pr 설치

스킬 파일을 다운로드하여 .claude/skills/ 디렉터리에 압축을 풀어주세요.

ZIP 다운로드

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

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

복사 복사
빠른 설정: skill 폴더를 .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