ce-commit-push-pr

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Git Commit, Push, and PR

Git Commit、Push 与 PR 创建

Go from working changes to an open pull request, or rewrite an existing PR description.

Asking the user: When this skill says "ask the user", use the platform's blocking question tool:

AskUserQuestion

in Claude Code (call

ToolSearch

with

select:AskUserQuestion

first if its schema isn't loaded),

request_user_input

in Codex,

ask_user

in Gemini,

ask_user

in Pi (requires the

pi-ask-user

extension). Fall back to presenting the question in chat only when no blocking tool exists in the harness or the call errors (e.g., Codex edit modes) — not because a schema load is required. Never silently skip the question.

从已完成的变更直接创建一个开放的PR，或重写现有PR的描述。

询问用户： 当本技能提示“询问用户”时，请使用平台的阻塞式提问工具：Claude Code中使用

AskUserQuestion

（若未加载其 schema，先调用

ToolSearch

并指定

select:AskUserQuestion

），Codex中使用

request_user_input

，Gemini中使用

ask_user

，Pi中使用

ask_user

（需

pi-ask-user

扩展）。仅当工具集中无阻塞式工具或调用出错时（如Codex编辑模式），才退回到在聊天中展示问题——不要因需要加载schema就跳过。绝对不能静默跳过问题。

Mode detection

模式检测

If the user is asking to update, refresh, or rewrite an existing PR description (with no mention of committing or pushing), this is a description-only update. The user may also provide a focus (e.g., "update the PR description and add the benchmarking results"). Note any focus for DU-3.

For description-only updates, follow the Description Update workflow below. Otherwise, follow the full workflow.

如果用户要求更新、刷新或重写现有PR描述（未提及提交或推送），则属于仅更新描述模式。用户可能还会指定重点（例如：“更新PR描述并添加基准测试结果”）。记录该重点以便在DU-3步骤中使用。

对于仅更新描述的场景，遵循下方的“描述更新工作流”；否则，遵循完整工作流。

Context

上下文信息

On platforms other than Claude Code, skip to the "Context fallback" section below and run the command there to gather context.

In Claude Code, the six labeled sections below contain pre-populated data. Use them directly -- do not re-run these commands.

Git status: !

git status

Working tree diff: !

git diff HEAD

Current branch: !

git branch --show-current

Recent commits: !

git log --oneline -10

Remote default branch: !

git rev-parse --abbrev-ref origin/HEAD 2>/dev/null || echo 'DEFAULT_BRANCH_UNRESOLVED'

Existing PR check: !

gh pr view --json url,title,state 2>/dev/null || echo 'NO_OPEN_PR'

在Claude Code以外的平台，直接跳至下方“上下文备选方案”部分，运行其中的命令来收集上下文信息。

在Claude Code中，下方六个标记好的部分已预填数据，请直接使用——无需重新运行这些命令。

Git状态： !

git status

工作区差异： !

git diff HEAD

当前分支： !

git branch --show-current

最近提交记录： !

git log --oneline -10

远程默认分支： !

git rev-parse --abbrev-ref origin/HEAD 2>/dev/null || echo 'DEFAULT_BRANCH_UNRESOLVED'

现有PR检查： !

gh pr view --json url,title,state 2>/dev/null || echo 'NO_OPEN_PR'

Context fallback

上下文备选方案

In Claude Code, skip this section — the data above is already available.

Run this single command to gather all context:

bash

printf '=== STATUS ===\n'; git status; printf '\n=== DIFF ===\n'; git diff HEAD; printf '\n=== BRANCH ===\n'; git branch --show-current; printf '\n=== LOG ===\n'; git log --oneline -10; printf '\n=== DEFAULT_BRANCH ===\n'; git rev-parse --abbrev-ref origin/HEAD 2>/dev/null || echo 'DEFAULT_BRANCH_UNRESOLVED'; printf '\n=== PR_CHECK ===\n'; gh pr view --json url,title,state 2>/dev/null || echo 'NO_OPEN_PR'

在Claude Code中请跳过此部分——上述数据已可用。

运行以下单个命令来收集所有上下文信息：

bash

printf '=== STATUS ===\n'; git status; printf '\n=== DIFF ===\n'; git diff HEAD; printf '\n=== BRANCH ===\n'; git branch --show-current; printf '\n=== LOG ===\n'; git log --oneline -10; printf '\n=== DEFAULT_BRANCH ===\n'; git rev-parse --abbrev-ref origin/HEAD 2>/dev/null || echo 'DEFAULT_BRANCH_UNRESOLVED'; printf '\n=== PR_CHECK ===\n'; gh pr view --json url,title,state 2>/dev/null || echo 'NO_OPEN_PR'

Description Update workflow

描述更新工作流

DU-1: Confirm intent

DU-1：确认意图

Ask the user: "Update the PR description for this branch?" If declined, stop.

询问用户：“是否更新此分支的PR描述？”若用户拒绝，则停止操作。

DU-2: Find the PR

DU-2：查找PR

Use the current branch and existing PR check from context. If the current branch is empty (detached HEAD), report no branch and stop. If the PR check returned

state: OPEN

, note the PR

url

from the context block — this is the unambiguous reference to pass downstream — and proceed to DU-3. Otherwise, report no open PR and stop.

使用上下文信息中的当前分支和现有PR检查结果。如果当前分支为空（分离HEAD状态），则报告无分支并停止操作。如果PR检查返回

state: OPEN

，记录上下文块中的PR

url

——这是传递给下游步骤的明确引用——然后进入DU-3步骤。否则，报告无开放PR并停止操作。

DU-3: Write and apply the updated description

DU-3：编写并应用更新后的描述

Read the current PR description to drive the compare-and-confirm step later:

bash

gh pr view --json body --jq '.body'

Generate the updated title and body — load the

ce-pr-description

skill with the PR URL from DU-2 (e.g.,

https://github.com/owner/repo/pull/123

). The URL preserves repo/PR identity even when invoked from a worktree or subdirectory where the current repo is ambiguous. If the user provided a focus (e.g., "include the benchmarking results"), append it as free-text steering after the URL. The skill returns a

{title, body_file}

block (body in an OS temp file) without applying or prompting.

ce-pr-description

returns a "not open" or other graceful-exit message instead of a

{title, body_file}

pair, report that message and stop.

Evidence decision:

ce-pr-description

preserves any existing

## Demo

## Screenshots

block from the current body by default. If the user's focus asks to refresh or remove evidence, pass that intent as steering text — the skill will honor it. If no evidence block exists and one would benefit the reader, invoke

ce-demo-reel

separately to capture, then re-invoke

ce-pr-description

with updated steering that references the captured evidence.

Compare and confirm — briefly explain what the new description covers differently from the old one. This helps the user decide whether to apply; the description itself does not narrate these differences. Summarize from the body already in context (from the bash call that wrote

body_file

); do not

cat

the temp file, which would re-emit the body.

If the user provided a focus, confirm it was addressed.
Ask the user to confirm before applying.

If confirmed, perform these two actions in order. They are separate steps with a hand-off boundary between them — do not stop after action 1.

```
ce-pr-description
```
has already returned its
```
=== TITLE ===
```
/
```
=== BODY_FILE ===
```
block and stopped; it does not apply on its own.
Apply the returned title and body file yourself. This is this skill's responsibility, not the delegated skill's. Substitute
```
<TITLE>
```
and
```
<BODY_FILE>
```
verbatim from the return block; if
```
<TITLE>
```
contains
```
"
```
,
```
`
```
,
```
$
```
, or
```
\
```
, escape them or switch to single quotes:
bash
```
gh pr edit --title "<TITLE>" --body "$(cat "<BODY_FILE>")"
```

Report the PR URL.

先读取当前PR描述，以便后续进行对比确认：

bash

gh pr view --json body --jq '.body'

生成更新后的标题和正文——加载

ce-pr-description

技能并传入DU-2步骤中获取的PR URL（例如：

https://github.com/owner/repo/pull/123

）。即使在工作树或子目录中调用（当前仓库可能不明确），URL也能保留仓库/PR的身份信息。如果用户指定了重点（例如：“包含基准测试结果”），在URL后附加该自由文本作为指导。该技能会返回一个

{title, body_file}

块（正文存储在系统临时文件中），不会自动应用或提示。

如果

ce-pr-description

返回“未开放”或其他优雅退出消息而非

{title, body_file}

对，则报告该消息并停止操作。

证据决策：

ce-pr-description

默认会保留当前正文中已有的

## Demo

或

## Screenshots

块。如果用户的重点要求刷新或移除证据，将该意图作为指导文本传递——技能会遵循该要求。如果没有证据块且添加证据块对读者有益，则单独调用

ce-demo-reel

技能来捕获证据，然后重新调用

ce-pr-description

并传入包含捕获证据的更新指导文本。

对比与确认——简要说明新描述与旧描述的不同之处。这有助于用户决定是否应用；描述本身无需说明这些差异。根据上下文已有的正文（来自写入

body_file

的bash命令）进行总结；不要使用

cat

命令读取临时文件，以免重复输出正文。

如果用户指定了重点，确认该重点已被覆盖。
在应用前询问用户确认。

若用户确认，请按顺序执行以下两个操作。这是两个独立步骤，中间有交接边界——完成操作1后不要停止。

```
ce-pr-description
```
已返回
```
=== TITLE ===
```
/
```
=== BODY_FILE ===
```
块并停止；它不会自动应用。
自行应用返回的标题和正文文件。这是本技能的职责，而非委托技能的职责。直接替换返回块中的
```
<TITLE>
```
和
```
<BODY_FILE>
```
；如果
```
<TITLE>
```
包含
```
"
```
,
```
`
```
,
```
$
```
, 或
```
\
```
，请转义这些字符或改用单引号：
bash
```
gh pr edit --title "<TITLE>" --body "$(cat "<BODY_FILE>")"
```

报告PR的URL。

Full workflow

完整工作流

Step 1: Gather context

步骤1：收集上下文信息

Use the context above. All data needed for this step and Step 3 is already available -- do not re-run those commands.

The remote default branch value returns something like

origin/main

. Strip the

origin/

prefix. If it returned

DEFAULT_BRANCH_UNRESOLVED

or a bare

HEAD

, try:

bash

gh repo view --json defaultBranchRef --jq '.defaultBranchRef.name'

If both fail, fall back to

main

If the current branch is empty (detached HEAD), explain that a branch is required. Ask whether to create a feature branch now.

If yes, derive a branch name from the change content, create with
```
git checkout -b <branch-name>
```
, and use that for the rest of the workflow.
If no, stop.

If the working tree is clean (no staged, modified, or untracked files), determine the next action:

Run

git rev-parse --abbrev-ref --symbolic-full-name @{u}

to check upstream.

If upstream exists, run
```
git log <upstream>..HEAD --oneline
```
for unpushed commits.

Decision tree:

On default branch, unpushed commits or no upstream -- ask whether to create a feature branch (pushing default directly is not supported). If yes, create and continue from Step 5. If no, stop.
On default branch, all pushed, no open PR -- report no feature branch work. Stop.
Feature branch, no upstream -- skip Step 4, continue from Step 5.
Feature branch, unpushed commits -- skip Step 4, continue from Step 5.
Feature branch, all pushed, no open PR -- skip Steps 4-5, continue from Step 6.
Feature branch, all pushed, open PR -- report up to date. Stop.

使用上述上下文信息。本步骤和步骤3所需的所有数据已可用——无需重新运行这些命令。

远程默认分支的返回值类似

origin/main

。去除

origin/

前缀。如果返回

DEFAULT_BRANCH_UNRESOLVED

或仅

HEAD

，尝试运行：

bash

gh repo view --json defaultBranchRef --jq '.defaultBranchRef.name'

如果两者都失败，默认使用

main

。

如果当前分支为空（分离HEAD状态），说明需要分支。询问用户是否立即创建功能分支。

如果是，根据变更内容生成分支名称，使用
```
git checkout -b <branch-name>
```
创建分支，并在后续工作流中使用该分支。
如果否，停止操作。

如果工作区干净（无暂存、修改或未跟踪文件），确定下一步操作：

运行

git rev-parse --abbrev-ref --symbolic-full-name @{u}

检查上游分支。

如果上游分支存在，运行
```
git log <upstream>..HEAD --oneline
```
查看未推送的提交。

决策树：

在默认分支上，存在未推送提交或无上游分支——询问用户是否创建功能分支（不支持直接推送到默认分支）。如果是，创建分支并从步骤5继续。如果否，停止操作。
在默认分支上，所有提交已推送，无开放PR——报告无功能分支工作内容。停止操作。
功能分支，无上游分支——跳过步骤4，从步骤5继续。
功能分支，存在未推送提交——跳过步骤4，从步骤5继续。
功能分支，所有提交已推送，无开放PR——跳过步骤4-5，从步骤6继续。
功能分支，所有提交已推送，存在开放PR——报告已同步最新内容。停止操作。

Step 2: Determine conventions

步骤2：确定规范

Priority order for commit messages and PR titles:

Repo conventions in context -- follow project instructions if they specify conventions. Do not re-read; they load at session start.
Recent commit history -- match the pattern in the last 10 commits.
Default --
```
type(scope): description
```
(conventional commits).

When using conventional commits, choose the type that most precisely describes the change. Where

fix:

and

feat:

both seem to fit, default to

fix:

: a change that remedies broken or missing behavior is

fix:

even when implemented by adding code. Reserve

feat:

for capabilities the user could not previously accomplish. Other types (

chore:

refactor:

docs:

perf:

test:

ci:

build:

style:

) remain primary when they fit better. The user may override for a specific change.

提交消息和PR标题的优先级顺序：

上下文仓库的规范——如果项目说明中指定了规范，请遵循。无需重新读取；规范会在会话开始时加载。
最近提交历史——匹配最近10次提交的格式。
默认规范——
```
type(scope): description
```
（约定式提交）。

使用约定式提交时，选择最能准确描述变更的类型。当

fix:

和

feat:

都适用时，默认使用

fix:

：修复损坏或缺失行为的变更即使是通过添加代码实现，也属于

fix:

。

feat:

仅用于用户之前无法实现的功能。其他类型（

chore:

、

refactor:

、

docs:

、

perf:

、

test:

、

ci:

、

build:

、

style:

）在更合适时优先使用。用户可针对特定变更覆盖默认类型。

Step 3: Check for existing PR

步骤3：检查现有PR

Use the current branch and existing PR check from context. If the branch is empty, report detached HEAD and stop.

If the PR check returned

state: OPEN

, note the URL -- this is the existing-PR flow. Continue to Step 4 and 5 (commit any pending work and push), then go to Step 7 to ask whether to rewrite the description. Only run Step 6 (which generates a new description via

ce-pr-description

) if the user confirms the rewrite; Step 7's existing-PR sub-path consumes the

{title, body_file}

that Step 6 produces. Otherwise (no open PR), continue through Steps 6, 7, and 8 in order.

使用上下文信息中的当前分支和现有PR检查结果。如果分支为空，报告分离HEAD状态并停止操作。

如果PR检查返回

state: OPEN

，记录URL——这属于现有PR流程。继续执行步骤4和5（提交所有未完成工作并推送），然后进入步骤7询问是否重写描述。仅当用户确认重写时才运行步骤6（通过

ce-pr-description

生成新描述）；步骤7的现有PR子流程会使用步骤6生成的

{title, body_file}

。否则（无开放PR），依次执行步骤6、7、8。

Step 4: Branch, stage, and commit

步骤4：分支、暂存与提交

If on the default branch, create a feature branch first with
```
git checkout -b <branch-name>
```
.
Scan changed files for naturally distinct concerns. If files clearly group into separate logical changes, create separate commits (2-3 max). Group at the file level only (no
```
git add -p
```
). When ambiguous, one commit is fine.

Stage and commit each group in a single call. Avoid

git add -A

git add .

. Follow conventions from Step 2:

bash

git add file1 file2 file3 && git commit -m "$(cat <<'EOF'
commit message here
EOF
)"

如果当前在默认分支上，先使用
```
git checkout -b <branch-name>
```
创建功能分支。
扫描变更文件，找出自然区分的关注点。如果文件可清晰分组为不同的逻辑变更，创建多个提交（最多2-3个）。仅按文件分组（不使用
```
git add -p
```
）。若难以区分，创建单个提交即可。

单次调用完成每组文件的暂存与提交。避免使用

git add -A

或

git add .

。遵循步骤2确定的规范：

bash

git add file1 file2 file3 && git commit -m "$(cat <<'EOF'
提交消息内容
EOF
)"

Step 5: Push

步骤5：推送

bash

git push -u origin HEAD

bash

git push -u origin HEAD

Step 6: Generate the PR title and body

步骤6：生成PR标题和正文

The working-tree diff from Step 1 only shows uncommitted changes at invocation time. The PR description must cover all commits in the PR.

Detect the base branch and remote. Resolve both the base branch and the remote (fork-based PRs may use a remote other than

origin

). Stop at the first that succeeds:

PR metadata (if existing PR found in Step 3):
bash
```
gh pr view --json baseRefName,url
```
Extract
```
baseRefName
```
. Match
```
owner/repo
```
from the PR URL against
```
git remote -v
```
fetch URLs to find the base remote. Fall back to
```
origin
```
.
Remote default branch from context -- if resolved, strip
```
origin/
```
prefix. Use
```
origin
```
.

GitHub metadata:

bash

gh repo view --json defaultBranchRef --jq '.defaultBranchRef.name'

Use

origin

Common names -- check

main

master

develop

trunk

in order:

bash

git rev-parse --verify origin/<candidate>

Use

origin

If none resolve, ask the user to specify the target branch.

Gather the full branch diff (before evidence decision). The working-tree diff from Step 1 only reflects uncommitted changes at invocation time — on the common "feature branch, all pushed, open PR" path, Step 1 skips the commit/push steps and the working-tree diff is empty. The evidence decision below needs the real branch diff to judge whether behavior is observable, so compute it explicitly against the base resolved above. Only fetch when the local ref isn't available — if

<base-remote>/<base-branch>

already resolves locally, run the diff from local state so offline / restricted-network / expired-auth environments don't hard-fail:

bash

git rev-parse --verify <base-remote>/<base-branch> >/dev/null 2>&1 \
  || git fetch --no-tags <base-remote> <base-branch>
git diff <base-remote>/<base-branch>...HEAD

Use this branch diff (not the working-tree diff) for the evidence decision. If the branch diff is empty (e.g., HEAD is already merged into the base or the branch has no unique commits), skip the evidence prompt and continue to delegation.

Evidence decision (before delegation). Before running the full decision, two short-circuits:

User explicitly asked for evidence. If the user's invocation requested it ("ship with a demo", "include a screenshot"), proceed directly to capture. If capture turns out to be not possible (no runnable surface, missing credentials, docs-only diff) or clearly not useful, note that briefly and proceed without evidence — do not force capture for its own sake.
Agent judgment on authored changes. If you authored the commits in this session and know the change is clearly non-observable (internal plumbing, backend refactor without user-facing effect, type-level changes, etc.), skip the prompt without asking. The categorical skip list below is not exhaustive — trust judgment about the change you just wrote.

Otherwise, run the full decision: if the branch diff changes observable behavior (UI, CLI output, API behavior with runnable code, generated artifacts, workflow output) and evidence is not otherwise blocked (unavailable credentials, paid services, deploy-only infrastructure, hardware), ask: "This PR has observable behavior. Capture evidence for the PR description?"

Capture now -- load the
```
ce-demo-reel
```
skill with a target description inferred from the branch diff. ce-demo-reel returns
```
Tier
```
,
```
Description
```
,
```
URL
```
, and
```
Path
```
. Exactly one of
```
URL
```
or
```
Path
```
contains a real value; the other is
```
"none"
```
. If capture returns a public URL, pass it as steering to
```
ce-pr-description
```
(e.g., "include the captured demo: <URL> as a
```
## Demo
```
section") or splice into the returned body before apply. If capture returns a local
```
Path
```
instead (user chose local save), pass steering that notes evidence was captured but is local-only (e.g., "evidence was captured locally — note in the PR that a demo was recorded but is not embedded because the user chose local save"). If capture returns
```
Tier: skipped
```
or both
```
URL
```
and
```
Path
```
are
```
"none"
```
, proceed with no evidence.
Use existing evidence -- ask for the URL or markdown embed, then pass it as free-text steering to
```
ce-pr-description
```
or splice in before apply.
Skip -- proceed with no evidence section.

When evidence is not possible (docs-only, markdown-only, changelog-only, release metadata, CI/config-only, test-only, or pure internal refactors), skip without asking.

Delegate title and body generation to
ce-pr-description
. Load the

ce-pr-description

skill:

For a new PR (no existing PR found in Step 3): invoke with
```
base:<base-remote>/<base-branch>
```
using the already-resolved base from earlier in this step, so
```
ce-pr-description
```
describes the correct commit range even when the branch targets a non-default base (e.g.,
```
develop
```
,
```
release/*
```
). Append any captured-evidence context or user focus as free-text steering (e.g., "include the captured demo: <URL> as a
```
## Demo
```
section", or "evidence captured locally — not embedded" for local saves).
For an existing PR (found in Step 3): invoke with the full PR URL from the Step 3 context (e.g.,
```
https://github.com/owner/repo/pull/123
```
). The URL preserves repo/PR identity even when invoked from a worktree or subdirectory; the skill reads the PR's own
```
baseRefName
```
so no
```
base:
```
override is needed. Append any focus steering as free text after the URL.

Steering discipline. Pass only what the diff cannot reveal: a user focus ("emphasize the performance win"), a specific framing concern ("this needs to read as a migration not a feature"), or a pointer to institutional knowledge. Do NOT dump an exhaustive scope summary or a numbered list of every change —

ce-pr-description

reads the diff itself. Over-specified steering encourages the downstream skill to cover everything passed in, producing verbose output. Cap steering at roughly 100 words; if a longer framing feels necessary, trust the diff and cut.

ce-pr-description

returns a

{title, body_file}

block (body in an OS temp file). It applies the value-first writing principles, commit classification, sizing, narrative framing, writing voice, visual communication, numbering rules, and the Compound Engineering badge footer internally. Use the returned values verbatim in Step 7; do not layer manual edits onto them unless a focused adjustment is required (e.g., splicing an evidence block captured in this step that was not passed as steering text — in that case, edit the body file directly before applying).

ce-pr-description

returns a graceful-exit message instead of

{title, body_file}

(e.g., closed PR, no commits to describe, base ref unresolved), report the message and stop — do not create or edit the PR.

步骤1中的工作区差异仅显示调用时的未提交变更。PR描述必须覆盖PR中的所有提交。

检测基准分支和远程仓库。解析基准分支和远程仓库（基于fork的PR可能使用

origin

以外的远程仓库）。按以下顺序尝试，直到成功：

PR元数据（如果步骤3中发现现有PR）：
bash
```
gh pr view --json baseRefName,url
```
提取
```
baseRefName
```
。将PR URL中的
```
owner/repo
```
与
```
git remote -v
```
的fetch URL匹配，找到基准远程仓库。默认使用
```
origin
```
。
上下文信息中的远程默认分支——如果已解析，去除
```
origin/
```
前缀。使用
```
origin
```
。

GitHub元数据：

bash

gh repo view --json defaultBranchRef --jq '.defaultBranchRef.name'

使用

origin

。

常见名称——依次检查

main

、

master

、

develop

、

trunk

：

bash

git rev-parse --verify origin/<candidate>

使用

origin

。

如果均无法解析，请询问用户指定目标分支。

收集完整分支差异（证据决策前）。步骤1中的工作区差异仅反映调用时的未提交变更——在常见的“功能分支，所有提交已推送，存在开放PR”流程中，步骤1会跳过提交/推送步骤，工作区差异为空。下方的证据决策需要真实的分支差异来判断行为是否可观察，因此需针对上述解析出的基准分支明确计算差异。仅当本地引用不可用时才执行fetch——如果

<base-remote>/<base-branch>

已在本地解析，从本地状态运行diff，避免离线/受限网络/过期认证环境下出现硬失败：

bash

git rev-parse --verify <base-remote>/<base-branch> >/dev/null 2>&1 \
  || git fetch --no-tags <base-remote> <base-branch>
git diff <base-remote>/<base-branch>...HEAD

使用此分支差异（而非工作区差异）进行证据决策。如果分支差异为空（例如：HEAD已合并到基准分支，或分支无唯一提交），跳过证据提示并继续委托步骤。

证据决策（委托前）。在运行完整决策前，有两个短路条件：

用户明确要求提供证据。如果用户调用时要求（“附带demo发布”“包含截图”），直接进行捕获。如果捕获不可行（无运行界面、缺少凭证、仅文档差异）或明显无用，简要说明后继续，不强制捕获。
Agent对已编写变更的判断。如果本会话中是你编写的提交，且明确知道变更不可观察（内部管道、无用户可见影响的后端重构、类型级别变更等），无需询问直接跳过。以下分类跳过列表并不详尽——相信你对刚编写的变更的判断。

否则，运行完整决策：如果分支差异变更了可观察行为（UI、CLI输出、可运行代码的API行为、生成的工件、工作流输出），且证据未被阻止（无可用凭证、付费服务、仅部署基础设施、硬件限制），询问：“此PR包含可观察行为。是否为PR描述捕获证据？”

立即捕获——加载
```
ce-demo-reel
```
技能，并传入从分支差异推断出的目标描述。ce-demo-reel会返回
```
Tier
```
、
```
Description
```
、
```
URL
```
和
```
Path
```
。
```
URL
```
或
```
Path
```
中仅有一个为真实值，另一个为
```
"none"
```
。如果捕获返回公共URL，将其作为指导传递给
```
ce-pr-description
```
（例如：“将捕获的demo：<URL>作为
```
## Demo
```
部分包含在内”），或在应用前插入返回的正文。如果捕获返回本地
```
Path
```
（用户选择本地保存），传递指导文本说明证据已捕获但仅本地可用（例如：“证据已本地捕获——在PR中注明已录制demo但未嵌入，因用户选择本地保存”）。如果捕获返回
```
Tier: skipped
```
或
```
URL
```
和
```
Path
```
均为
```
"none"
```
，则不添加证据继续。
使用现有证据——询问用户获取URL或markdown嵌入代码，然后将其作为自由文本指导传递给
```
ce-pr-description
```
，或在应用前插入。
跳过——不添加证据部分继续。

当无法提供证据时（仅文档、仅markdown、仅变更日志、仅发布元数据、仅CI/配置、仅测试、纯内部重构），无需询问直接跳过。

委托标题和正文生成给
ce-pr-description
。加载

ce-pr-description

技能：

新PR（步骤3中未发现现有PR）：使用之前解析出的基准分支，以
```
base:<base-remote>/<base-branch>
```
的形式调用，这样即使分支目标是非默认基准分支（如
```
develop
```
、
```
release/*
```
），
```
ce-pr-description
```
也能描述正确的提交范围。附加任何捕获的证据上下文或用户重点作为自由文本指导（例如：“将捕获的demo：<URL>作为
```
## Demo
```
部分包含在内”，或“证据已本地捕获——未嵌入”）。
现有PR（步骤3中发现）：使用步骤3上下文中的完整PR URL调用（例如：
```
https://github.com/owner/repo/pull/123
```
）。即使在工作树或子目录中调用，URL也能保留仓库/PR的身份信息；技能会读取PR自身的
```
baseRefName
```
，无需
```
base:
```
覆盖。在URL后附加任何重点指导作为自由文本。

指导原则。仅传递差异无法揭示的信息：用户重点（“强调性能提升”）、特定框架关注点（“需将其描述为迁移而非功能”）或机构知识指针。不要传入详尽的范围摘要或每个变更的编号列表——

ce-pr-description

会自行读取差异。过度指定的指导会导致下游技能覆盖所有传入内容，产生冗长输出。指导文本控制在约100词以内；如果需要更长的框架说明，相信差异本身并精简内容。

ce-pr-description

会返回一个

{title, body_file}

块（正文存储在系统临时文件中）。它会在内部应用价值优先写作原则、提交分类、大小评估、叙事框架、写作语气、视觉传达、编号规则和Compound Engineering徽章页脚。在步骤7中直接使用返回的值；除非需要针对性调整（例如：插入本步骤中捕获但未作为指导传递的证据块——此时需在应用前直接编辑正文文件），否则不要手动编辑。

如果

ce-pr-description

返回优雅退出消息而非

{title, body_file}

（例如：PR已关闭、无提交可描述、基准引用未解析），报告该消息并停止操作——不要创建或编辑PR。

Step 7: Create or update the PR

步骤7：创建或更新PR

New PR (no existing PR from Step 3)

新PR（步骤3中未发现现有PR）

Using the

=== TITLE ===

=== BODY_FILE ===

block returned by

ce-pr-description

, substitute

<TITLE>

and

<BODY_FILE>

verbatim. If

<TITLE>

contains

, or

, escape them or switch to single quotes:

bash

gh pr create --title "<TITLE>" --body "$(cat "<BODY_FILE>")"

Keep the title under 72 characters;

ce-pr-description

already emits a conventional-commit title in that range.

使用

ce-pr-description

返回的

=== TITLE ===

=== BODY_FILE ===

块，直接替换

<TITLE>

和

<BODY_FILE>

。如果

<TITLE>

包含

, 或

，请转义这些字符或改用单引号：

bash

gh pr create --title "<TITLE>" --body "$(cat "<BODY_FILE>")"

标题长度保持在72字符以内；

ce-pr-description

已生成符合该长度的约定式提交标题。

Existing PR (found in Step 3)

现有PR（步骤3中发现）

The new commits are already on the PR from Step 5. Report the PR URL, then ask whether to rewrite the description.

If no -- skip Step 6 entirely and finish. Do not run delegation or evidence capture when the user declined the rewrite.
If yes, perform these three actions in order. They are separate steps with a hand-off boundary between them -- do not stop between actions.
1. Run Step 6 to generate via
```
ce-pr-description
```
  (passing the existing PR URL as
```
pr:
```
  ).
```
ce-pr-description
```
  explicitly does not apply on its own; it returns its
```
=== TITLE ===
```
  /
```
=== BODY_FILE ===
```
  block and stops.
2. Preview and confirm. Read the first two sentences of the Summary from the body file, plus the total line count. Ask the user (per the "Asking the user" convention at the top of this skill): "New title:
```
<title>
```
  (
```
<N>
```
  chars). Summary leads with:
```
<first two sentences>
```
  . Total body:
```
<L>
```
  lines. Apply?" The first two sentences of the Summary carry most of the reviewer's attention; they are the single highest-leverage text in the description, so they are what the preview spotlights. If the user declines, they may pass steering text back for a regenerate; do not apply.
3. If confirmed, apply the returned title and body file yourself. This is this skill's responsibility, not the delegated skill's. Substitute
```
<TITLE>
```
  and
```
<BODY_FILE>
```
  verbatim from the return block; if
```
<TITLE>
```
  contains
```
"
```
  ,
```
`
```
  ,
```
$
```
  , or
```
\
```
  , escape them or switch to single quotes:
  bash
```
gh pr edit --title "<TITLE>" --body "$(cat "<BODY_FILE>")"
```
Then report the PR URL (Step 8).

新提交已通过步骤5推送到PR。报告PR URL，然后询问用户是否重写描述。

如果否——完全跳过步骤6并结束。当用户拒绝重写时，不要运行委托或证据捕获。
如果是，按顺序执行以下三个操作。这是三个独立步骤，中间有交接边界——步骤间不要停止。
1. 运行步骤6，通过
```
ce-pr-description
```
  生成描述（传入现有PR URL作为
```
pr:
```
  参数）。
```
ce-pr-description
```
  明确不会自动应用；它会返回
```
=== TITLE ===
```
  /
```
=== BODY_FILE ===
```
  块并停止。
2. 预览与确认。读取正文文件中Summary的前两句，以及总行数。按照本技能顶部“询问用户”的约定询问用户：“新标题：
```
<title>
```
  （
```
<N>
```
  字符）。摘要开头：
```
<前两句>
```
  。正文总长度：
```
<L>
```
  行。是否应用？”摘要的前两句是评审者最关注的内容；它们是描述中影响力最高的文本，因此预览重点展示这部分。如果用户拒绝，他们可能会返回指导文本要求重新生成；不要应用。
3. 如果用户确认，自行应用返回的标题和正文文件。这是本技能的职责，而非委托技能的职责。直接替换返回块中的
```
<TITLE>
```
  和
```
<BODY_FILE>
```
  ；如果
```
<TITLE>
```
  包含
```
"
```
  ,
```
`
```
  ,
```
$
```
  , 或
```
\
```
  ，请转义这些字符或改用单引号：
  bash
```
gh pr edit --title "<TITLE>" --body "$(cat "<BODY_FILE>")"
```
然后报告PR URL（步骤8）。

Step 8: Report

步骤8：报告结果

Output the PR URL.

输出PR的URL。