選項
首頁首頁 Skill Git 和版本控制 ce-commit-push-pr

提交、推送並開啟拉取請求。適用於被要求發佈/開啟拉取請求時,或僅涉及拉取請求描述的流程,例如撰寫、重寫或說明拉取請求正文。

...展開全部
14
更新時間 2026-08-26

關於ce-commit-push-pr

在提交、推送及開啟拉取請求時,會根據變更規模動態調整說明的深度,並採用「價值優先」的描述方式。 該工具會由「提交並建立拉取請求」、「發布此內容」、「建立拉取請求」或「開啟拉取請求」等指令觸發,同時也能處理僅涉及說明的流程,例如「撰寫拉取請求說明」或「重寫拉取請求正文」,而無需進行提交或推送。 它定義了三種模式:僅描述模式(僅執行描述步驟並輸出結果)、描述更新模式(刷新現有已開啟拉取請求的內容,並透過 `gh pr edit` 套用)以及完整工作流程模式(依序執行所有步驟)。 當需要向使用者提問時,它會使用平台的阻塞式提問工具,並備有聊天備用方案。

此工作流程會透過 Claude Code 中的預填區段,或透過其他處提供的上下文備用指令,收集 Git 上下文資訊——包括狀態、工作樹差異、當前分支、近期提交、遠端預設分支,以及任何現有的 PR。 步驟 1 會解析分支與 PR 狀態,並根據情況進行路由:若為分離 HEAD,則提示建立功能分支;若位於預設分支且有工作內容,則自動建立功能分支(因為不支援直接推送預設分支);若位於預設分支且無工作內容,則停止流程;若位於功能分支,則繼續執行。 步驟 2 確定編碼規範,匹配儲存庫風格並預設採用慣例提交;當名稱含糊不清時,優先採用「fix:」而非「feat:」,並將「feat:」保留給真正的新功能。

步驟 3 進行提交與推送: 若位於預設分支,則參照分支建立指南;將變更過的檔案在檔案層級分組為最多兩至三個邏輯提交(避免使用 `git add -p`、`git add -A` 或 `git add .`,以免一併納入 `.env` 及建置產出物);並透過 `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:」,因為新增程式碼來修復損壞或缺失的功能屬於修正。「feat:」則保留給真正的新功能。

為什麼要避免使用 `git add -A` 和 `git add .`?

因為這些指令會將 .env、建置產出及生成檔案等檔案一併納入。它會將特定檔案加入暫存區,並在檔案層級將變更分組為至多兩到三個邏輯提交。

在 PR 描述中如何處理證據?

使用者提供的輔助資料會歸類於「示範」、「螢幕截圖」或「證據」標題下;若使用者希望提供證據但尚未提供,系統會主動詢問;至於無法觀察到的變更則跳過證據部分,並針對可觀察的行為附上驗證說明。

所有檔案

3個檔案SKILL.md 8.6KB 檢視 references/pr-description-writing.md 7.2KB 檢視 references/branch-creation.md 1.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

複製 複製
快速設定: 將技能資料夾複製到 .claude/skills/,Claude 會自動偵測並使用該技能

相關技能

github-project-management
更新時間 2026-06-29
using-git-worktrees
更新時間 2026-06-29
readme-blueprint-generator
更新時間 2026-07-05
finishing-a-development-branch
更新時間 2026-06-29
OR