Back to Details

ce-pr-description

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

CE PR Description

CE PR描述

Generate a conventional-commit-style title and a value-first body describing a pull request's work. Returns structured 
{title, body_file}
for the caller to apply — this skill never invokes 
gh pr edit
or 
gh pr create
, and never prompts for interactive confirmation.
Why a separate skill: several callers need the same writing logic without the single-PR interactive scaffolding that lives in 
ce-commit-push-pr
. 
ce-pr-stack
's splitting workflow runs this once per layer as a batch; 
ce-commit-push-pr
runs it inside its full-flow and refresh-mode paths. Extracting keeps one source of truth for the writing principles.
Naming rationale: 
ce-pr-description
, not 
git-pr-description
. Stacking and PR creation are GitHub features; the "PR" in the name refers to the GitHub artifact. Using the 
ce-
prefix matches the plugin naming convention for all skills.
生成符合约定式提交风格的标题和以价值为核心的正文，用于描述拉取请求的工作内容。返回结构化的
{title, body_file}
供调用者应用——此技能从不调用
gh pr edit
或
gh pr create
，也不会提示交互式确认。
为何单独设置此技能：多个调用者需要相同的写作逻辑，但不需要
ce-commit-push-pr
中包含的单PR交互式脚手架。
ce-pr-stack
的拆分工作流会批量为每一层调用一次此技能；
ce-commit-push-pr
会在其完整流程和刷新模式路径中调用它。将写作逻辑抽离出来，确保写作原则的单一数据源。
命名理由：使用
ce-pr-description
而非
git-pr-description
。栈管理和PR创建是GitHub的功能；名称中的“PR”指GitHub的相关工件。使用
ce-
前缀符合所有技能的插件命名规范。

Inputs

输入

Input is a free-form prompt. Parse it into two parts:
  • A PR reference, if present. Any of these patterns counts: a full GitHub PR URL (
    https://github.com/owner/repo/pull/NN
    ), 
    pr:<number>
    or 
    pr:<URL>
    , a bare hashmark form (
    #NN
    ), or the argument being just a number (
    561
    ). Extract the PR reference and treat the rest of the argument as steering text.
  • Everything else is steering text (a "focus" hint like "emphasize the benchmarks" or "do a good job with the perf story"). It may be combined with a PR reference or stand alone.
No specific grammar is required — read the argument as natural language and identify whichever PR reference is present. If no PR reference is present, default to describing the current branch.
输入为自由格式的提示语，解析为两部分：
  • PR引用（若存在）：以下任意格式均有效：完整GitHub PR URL（
    https://github.com/owner/repo/pull/NN
    ）、
    pr:<number>
    或
    pr:<URL>
    、纯井号格式（
    #NN
    ），或参数仅为数字（
    561
    ）。提取PR引用后，将参数的剩余部分视为指导文本。
  • 其余内容为指导文本（如“强调基准测试”或“完善性能相关内容”这类“聚焦”提示）。它可与PR引用结合使用，也可单独存在。
无需遵循特定语法——将参数视为自然语言，识别其中存在的PR引用。若未找到PR引用，则默认描述当前分支。

Mode selection

模式选择

What the caller passesMode
No PR reference (empty argument or steering text only)Current-branch mode — describe the commits on HEAD vs the repo's default base
A PR reference (URL, 
pr:
, 
#NN
, or bare number)		PR mode — describe the specified PR
Steering text is always optional. If present, incorporate it alongside the diff-derived narrative; do not let it override the value-first principles or fabricate content unsupported by the diff.
Optional 
base:<ref>
override (current-branch mode only). When a caller already knows the intended base branch (e.g., 
ce-commit-push-pr
has detected 
origin/develop
or 
origin/release/2026-04
as the target), it can pass 
base:<ref>
to pin the base explicitly. The ref must resolve locally. This overrides auto-detection for current-branch mode; PR mode ignores it (PRs already define their own base via 
baseRefName
). Most invocations don't need this — auto-detection (existing PR's 
baseRefName
→ 
origin/HEAD
) covers the common case.
Examples:
  • ce-pr-description
    → current-branch, no focus, auto-detect base
  • ce-pr-description emphasize the benchmarks
    → current-branch, focus = "emphasize the benchmarks"
  • ce-pr-description base:origin/develop
    → current-branch, base pinned to 
    origin/develop
  • ce-pr-description base:origin/develop emphasize perf
    → same + focus
  • ce-pr-description pr:561
    → PR #561, no focus
  • ce-pr-description #561 do a good job with the perf story
    → PR #561, focus = "do a good job with the perf story"
  • ce-pr-description https://github.com/foo/bar/pull/561 emphasize safety
    → PR #561 in foo/bar, focus = "emphasize safety"
调用者传入内容模式
无PR引用（空参数或仅含指导文本）当前分支模式——描述HEAD与仓库默认基准分支之间的提交
含PR引用（URL、
pr:
、
#NN
或纯数字）		PR模式——描述指定的PR
指导文本始终为可选内容。若存在，则将其与基于差异生成的叙述内容结合；但不得让它覆盖以价值为核心的原则，或编造差异不支持的内容。
可选的
base:<ref>
覆盖（仅适用于当前分支模式）。当调用者已明确目标基准分支（例如
ce-commit-push-pr
检测到
origin/develop
或
origin/release/2026-04
为目标分支），可传入
base:<ref>
来明确固定基准分支。该引用必须能在本地解析。此设置会覆盖当前分支模式下的自动检测；PR模式会忽略此设置（PR已通过
baseRefName
定义自身的基准分支）。大多数调用无需此设置——自动检测（现有PR的
baseRefName
→ 
origin/HEAD
）可覆盖常见场景。
示例：
  • ce-pr-description
    → 当前分支模式，无聚焦，自动检测基准分支
  • ce-pr-description emphasize the benchmarks
    → 当前分支模式，聚焦为“emphasize the benchmarks”
  • ce-pr-description base:origin/develop
    → 当前分支模式，基准分支固定为
    origin/develop
  • ce-pr-description base:origin/develop emphasize perf
    → 同上，增加聚焦内容
  • ce-pr-description pr:561
    → PR #561，无聚焦
  • ce-pr-description #561 do a good job with the perf story
    → PR #561，聚焦为“do a good job with the perf story”
  • ce-pr-description https://github.com/foo/bar/pull/561 emphasize safety
    → foo/bar仓库的PR #561，聚焦为“emphasize safety”

Output

输出

Return a structured result with two fields:
  • title
     -- conventional-commit format: 
    type: description
    or 
    type(scope): description
    . Under 72 characters. Choose 
    type
    based on intent (feat/fix/refactor/docs/chore/perf/test), not file type. Pick the narrowest useful 
    scope
    (skill or agent name, CLI area, or shared label); omit when no single label adds clarity.
  • body_file
     -- absolute path to an OS temp file (created via 
    mktemp
    ) containing the body markdown that follows the writing principles below. Do not emit the body inline in the return.
The caller decides whether to apply via 
gh pr edit
, 
gh pr create
, or discard, reading the body from 
body_file
(e.g., 
--body "$(cat "$BODY_FILE")"
). This skill does NOT call those commands itself. No cleanup is required — 
mktemp
files live in OS temp storage, which the OS reaps on its own schedule.
返回包含两个字段的结构化结果：
  • title
    ——约定式提交格式：
    type: description
    或
    type(scope): description
    。长度不超过72字符。根据意图选择
    type
    （feat/fix/refactor/docs/chore/perf/test），而非文件类型。选择最窄的有用
    scope
    （技能或Agent名称、CLI领域或共享标签）；若没有单一标签能增加清晰度，则省略。
  • body_file
    ——操作系统临时文件的绝对路径（通过
    mktemp
    创建），文件内容为遵循以下写作原则的正文Markdown。不要在返回结果中直接内联正文。
调用者可决定是否通过
gh pr edit
、
gh pr create
应用该结果，或直接丢弃，只需从
body_file
读取正文（例如
--body "$(cat "$BODY_FILE")"
）。此技能不会自行调用这些命令。无需清理临时文件——
mktemp
创建的文件存储在操作系统临时目录中，操作系统会按自身计划自动清理。

What this skill does not do

此技能不执行的操作

  • No interactive confirmation prompts. If the diff is ambiguous about something important (e.g., the focus hint conflicts with the actual changes), surface the ambiguity in the returned output or raise it to the caller — do not prompt the user directly.
  • No branch checkout. Current-branch mode describes the HEAD in the user's current checkout; PR mode describes the specified PR. Neither mode checks out a different branch.
  • No compare-and-confirm narrative ("here's what changed since the last version"). The description describes the end state; the caller owns any compare-and-confirm framing.
  • No auto-apply via 
    gh pr edit
    or 
    gh pr create
    . Return the output and stop.
Interactive scaffolding (confirmation prompts, compare-and-confirm, apply step) is the caller's responsibility.
  • 无交互式确认提示。若差异中存在重要的模糊点（例如聚焦提示与实际变更冲突），需在返回结果中指出该模糊点，或告知调用者——不得直接提示用户。
  • 无分支检出操作。当前分支模式描述用户当前检出状态中的HEAD；PR模式描述指定的PR。两种模式均不会检出其他分支。
  • 无对比确认叙述（“以下是与上一版本相比的变更内容”）。描述仅针对最终状态；对比确认的框架由调用者负责。
  • 无通过
    gh pr edit
    或
    gh pr create
    自动应用的操作。返回输出后即停止。
交互式脚手架（确认提示、对比确认、应用步骤）由调用者负责。

Step 1: Resolve the diff and commit list

步骤1：解析差异和提交列表

Parse the input (see Inputs above) and branch on which mode it selects.
解析输入（参见上述输入部分），根据选择的模式分支处理。

Current-branch mode (default when no PR reference was given)

当前分支模式（未指定PR引用时默认启用）

Determine the base against which to compare, in this priority order:
  1. Caller-supplied 
    base:<ref>
     — if present, use it verbatim. The caller is asserting the correct base. The ref must resolve locally.
  2. Existing PR's 
    baseRefName
     — if the current branch already has an open PR on this repo, use that PR's base. Handles feature branches targeting non-default bases (e.g., 
    develop
    ) when the PR is already open.
  3. Repo default (
    origin/HEAD
    )     — fall back for branches with no PR yet and no caller-supplied base.
bash
undefined
按以下优先级确定对比基准：
  1. 调用者提供的
    base:<ref>
    ——若存在，直接使用。调用者需确保该基准正确。该引用必须能在本地解析。
  2. 现有PR的
    baseRefName
    ——若当前分支已在该仓库打开PR，则使用该PR的基准分支。适用于针对非默认基准分支（如
    develop
    ）的特性分支，且PR已打开的场景。
  3. 仓库默认分支（
    origin/HEAD
    ）    ——针对尚未创建PR且无调用者提供基准分支的分支，使用此回退方案。
bash
undefined

Detect current branch (fail if detached HEAD)

检测当前分支（若为分离HEAD状态则失败）

CURRENT_BRANCH=$(git branch --show-current) if [ -z "$CURRENT_BRANCH" ]; then echo "Detached HEAD — current-branch mode requires a branch. Pass a PR reference instead." exit 1 fi
CURRENT_BRANCH=$(git branch --show-current) if [ -z "$CURRENT_BRANCH" ]; then echo "Detached HEAD — current-branch mode requires a branch. Pass a PR reference instead." exit 1 fi

Priority: caller-supplied base: > existing PR's baseRefName > origin/HEAD > origin/main

优先级：调用者提供的base: > 现有PR的baseRefName > origin/HEAD > origin/main

if [ -n "$CALLER_BASE" ]; then BASE_REF="$CALLER_BASE" elif EXISTING_PR_BASE=$(gh pr view --json baseRefName --jq '.baseRefName'); then BASE_REF="origin/$EXISTING_PR_BASE" elif DEFAULT_HEAD=$(git rev-parse --abbrev-ref origin/HEAD); then BASE_REF="$DEFAULT_HEAD" else BASE_REF="origin/main" fi

Both `gh pr view` and `git rev-parse --abbrev-ref origin/HEAD` exit non-zero on the "not configured" paths; the elif chain drives off exit code rather than suppressed stderr. Stderr from a missing PR or unresolved `origin/HEAD` is informational and acceptable.

If `$BASE_REF` does not resolve locally (`git rev-parse --verify "$BASE_REF"` fails), the caller (or the user) needs to fetch it first. Exit gracefully with `"Base ref $BASE_REF does not resolve locally. Fetch it before invoking the skill."` — do not attempt recovery.

Gather merge base, commit list, and full diff:

```bash
MERGE_BASE=$(git merge-base "$BASE_REF" HEAD) && echo "MERGE_BASE=$MERGE_BASE" && echo '=== COMMITS ===' && git log --oneline $MERGE_BASE..HEAD && echo '=== DIFF ===' && git diff $MERGE_BASE...HEAD
If the commit list is empty, report 
"No commits between $BASE_REF and HEAD"
and exit gracefully — there is nothing to describe.
If an existing PR was found in step 1, also capture its body for evidence preservation in Step 3.
if [ -n "$CALLER_BASE" ]; then BASE_REF="$CALLER_BASE" elif EXISTING_PR_BASE=$(gh pr view --json baseRefName --jq '.baseRefName'); then BASE_REF="origin/$EXISTING_PR_BASE" elif DEFAULT_HEAD=$(git rev-parse --abbrev-ref origin/HEAD); then BASE_REF="$DEFAULT_HEAD" else BASE_REF="origin/main" fi

`gh pr view`和`git rev-parse --abbrev-ref origin/HEAD`在“未配置”路径下会返回非零退出码；elif链根据退出码而非抑制的stderr进行判断。缺少PR或无法解析`origin/HEAD`时的stderr为信息性内容，可接受。

若`$BASE_REF`无法在本地解析（`git rev-parse --verify "$BASE_REF"`失败），则调用者（或用户）需先拉取该引用。优雅退出并提示`"Base ref $BASE_REF does not resolve locally. Fetch it before invoking the skill."`——不得尝试恢复。

收集合并基准、提交列表和完整差异：

```bash
MERGE_BASE=$(git merge-base "$BASE_REF" HEAD) && echo "MERGE_BASE=$MERGE_BASE" && echo '=== COMMITS ===' && git log --oneline $MERGE_BASE..HEAD && echo '=== DIFF ===' && git diff $MERGE_BASE...HEAD
若提交列表为空，报告
"No commits between $BASE_REF and HEAD"
并优雅退出——无可描述内容。
若步骤1中找到现有PR，还需捕获其正文，以便在步骤3中保留证据。

PR mode (when the input contained a PR reference)

PR模式（输入中包含PR引用时启用）

Normalize the reference into a form 
gh pr view
accepts: a bare number (
561
), a full URL (
https://github.com/owner/repo/pull/561
), or the number extracted from 
pr:561
or 
#561
. 
gh pr view
's positional argument accepts bare numbers, URLs, and branch names — not 
owner/repo#NN
shorthand. For a cross-repo number reference without a URL, the caller would use 
-R owner/repo
; this skill accepts a full URL as the simplest cross-repo path, and that's what most callers use.
bash
gh pr view <pr-ref> --json number,state,title,body,baseRefName,baseRefOid,headRefName,headRefOid,headRepository,headRepositoryOwner,isCrossRepository,commits,url
Key JSON fields: 
headRefOid
(PR head SHA — prefer over indexing into 
commits
), 
baseRefOid
(base-branch SHA), 
headRepository
+ 
headRepositoryOwner
(PR source repo), 
isCrossRepository
. There is no 
baseRepository
field — the base repo is the one queried by 
gh pr view
itself.
If the returned 
state
is not 
OPEN
, report 
"PR <number> is <state> (not open); cannot regenerate description"
and exit gracefully without output. Callers expecting 
{title, body_file}
must handle this empty case.
Determine whether the PR lives in the current working directory's repo by parsing the URL's 
<owner>/<repo>
path segments and comparing against 
git remote get-url origin
(strip 
.git
suffix; handle both 
git@github.com:owner/repo
and 
https://github.com/owner/repo
forms). If the URL repo matches 
origin
's repo, route to the local-git path (Case A). Otherwise route to the API-only path (Case B). Bare numbers and 
#NN
forms implicitly target the current repo → Case A.
Case A → Case B fallback: Even when the URL repo matches 
origin
, the local clone may not be usable for this PR's refs — shallow clone, detached state missing the base branch, offline, auth issues, GHES quirks. If Case A's fetch or 
git merge-base
fails, fall back to Case B rather than failing the skill. Note the fallback in the caller-facing output.
Case A — PR is in the current repo:
Read the PR head SHA directly from 
headRefOid
in the JSON response above. Fetch the base ref and the head SHA in one call (the fetch is idempotent when refs are already local):
bash
PR_HEAD_SHA=<headRefOid from JSON>
git fetch --no-tags origin <baseRefName> $PR_HEAD_SHA
Using the explicit 
$PR_HEAD_SHA
in downstream commands avoids 
FETCH_HEAD
's multi-ref ordering problem (
git rev-parse FETCH_HEAD
returns only the first fetched ref's SHA, which silently breaks a multi-ref fetch).
bash
MERGE_BASE=$(git merge-base origin/<baseRefName> $PR_HEAD_SHA) && echo "MERGE_BASE=$MERGE_BASE" && echo '=== COMMITS ===' && git log --oneline $MERGE_BASE..$PR_HEAD_SHA && echo '=== DIFF ===' && git diff $MERGE_BASE...$PR_HEAD_SHA
If the explicit-SHA fetch is rejected (rare on GitHub, possible on some GHES configurations that disallow fetching non-tip SHAs), fall back to fetching 
refs/pull/<number>/head
and reading the PR head SHA from 
.git/FETCH_HEAD
by pull-ref pattern:
bash
git fetch --no-tags origin "refs/pull/<number>/head"
PR_HEAD_SHA=$(awk '/refs\/pull\/[0-9]+\/head/ {print $1; exit}' "$(git rev-parse --git-dir)/FETCH_HEAD")
Case B — PR is in a different repo:
Skip local git entirely. Read the diff and commit list from the API:
bash
gh pr diff <pr-ref>
gh pr view <pr-ref> --json commits --jq '.commits[] | [.oid[0:7], .messageHeadline] | @tsv'
Same classification/framing/writing pipeline. Note in the caller-facing output that the API fallback was used.
Also capture the existing PR body for evidence preservation in Step 3 (both cases).
将引用标准化为
gh pr view
可接受的格式：纯数字（
561
）、完整URL（
https://github.com/owner/repo/pull/561
），或从
pr:561
或
#561
中提取的数字。
gh pr view
的位置参数接受纯数字、URL和分支名称——但不接受
owner/repo#NN
简写形式。对于跨仓库的数字引用且无URL的情况，调用者需使用
-R owner/repo
；此技能接受完整URL作为最简单的跨仓库路径，这也是大多数调用者的选择。
bash
gh pr view <pr-ref> --json number,state,title,body,baseRefName,baseRefOid,headRefName,headRefOid,headRepository,headRepositoryOwner,isCrossRepository,commits,url
关键JSON字段：
headRefOid
（PR头部SHA——优先于从
commits
中索引）、
baseRefOid
（基准分支SHA）、
headRepository
+ 
headRepositoryOwner
（PR源仓库）、
isCrossRepository
。不存在
baseRepository
字段——基准仓库是
gh pr view
查询的仓库本身。
若返回的
state
不是
OPEN
，报告
"PR <number> is <state> (not open); cannot regenerate description"
并优雅退出，不输出内容。期望
{title, body_file}
的调用者需处理此空场景。
判断PR是否位于当前工作目录的仓库中：解析URL的
<owner>/<repo>
路径段，并与
git remote get-url origin
比较（去除
.git
后缀；处理
git@github.com:owner/repo
和
https://github.com/owner/repo
两种格式）。若URL仓库与
origin
仓库匹配，则走本地Git路径（案例A）；否则走仅API路径（案例B）。纯数字和
#NN
形式默认指向当前仓库→案例A。
案例A→案例B回退：即使URL仓库与
origin
匹配，本地克隆也可能无法用于此PR的引用——浅克隆、缺少基准分支的分离状态、离线、认证问题、GHES特性差异。若案例A的拉取或
git merge-base
失败，则回退到案例B，而非让技能失败。在面向调用者的输出中注明回退情况。
案例A——PR位于当前仓库：
直接从上述JSON响应的
headRefOid
读取PR头部SHA。一次调用拉取基准引用和头部SHA（当引用已在本地时，拉取操作是幂等的）：
bash
PR_HEAD_SHA=<headRefOid from JSON>
git fetch --no-tags origin <baseRefName> $PR_HEAD_SHA
在下游命令中使用显式的
$PR_HEAD_SHA
可避免
FETCH_HEAD
的多引用排序问题（
git rev-parse FETCH_HEAD
仅返回第一个拉取引用的SHA，这会导致多引用拉取静默失败）。
bash
MERGE_BASE=$(git merge-base origin/<baseRefName> $PR_HEAD_SHA) && echo "MERGE_BASE=$MERGE_BASE" && echo '=== COMMITS ===' && git log --oneline $MERGE_BASE..$PR_HEAD_SHA && echo '=== DIFF ===' && git diff $MERGE_BASE...$PR_HEAD_SHA
若显式SHA拉取被拒绝（GitHub上罕见，但在某些不允许拉取非尖端SHA的GHES配置中可能发生），则回退到拉取
refs/pull/<number>/head
并通过拉取引用模式从
.git/FETCH_HEAD
读取PR头部SHA：
bash
git fetch --no-tags origin "refs/pull/<number>/head"
PR_HEAD_SHA=$(awk '/refs\/pull\/[0-9]+\/head/ {print $1; exit}' "$(git rev-parse --git-dir)/FETCH_HEAD")
案例B——PR位于其他仓库：
完全跳过本地Git操作。从API读取差异和提交列表：
bash
gh pr diff <pr-ref>
gh pr view <pr-ref> --json commits --jq '.commits[] | [.oid[0:7], .messageHeadline] | @tsv'
使用相同的分类/框架/写作流程。在面向调用者的输出中注明使用了API回退。
同样需捕获现有PR正文，以便在步骤3中保留证据（两种案例均需）。

Step 2: Classify commits before writing

步骤2：编写前对提交进行分类

Scan the commit list and classify each commit:
  • Feature commits -- implement the PR's purpose (new functionality, intentional refactors, design changes). These drive the description.
  • Fix-up commits -- iteration work (code review fixes, lint fixes, test fixes, rebase resolutions, style cleanups). Invisible to the reader.
When sizing the description, mentally subtract fix-up commits: a branch with 12 commits but 9 fix-ups is a 3-commit PR.
扫描提交列表，对每个提交进行分类：
  • 特性提交——实现PR的核心目标（新功能、有意重构、设计变更）。这些提交是描述的核心。
  • 修正提交——迭代工作（代码评审修复、lint修复、测试修复、变基解决、样式清理）。对读者不可见。
确定描述篇幅时，需在心理上减去修正提交：一个包含12个提交但其中9个是修正提交的分支，实际上是3个提交的PR。

Step 3: Decide on evidence

步骤3：确定是否保留证据

Decide whether evidence capture is possible from the full branch diff.
Evidence is possible when the diff changes observable behavior demonstrable from the workspace: UI, CLI output, API behavior with runnable code, generated artifacts, or workflow output.
Evidence is not possible for:
  • Docs-only, markdown-only, changelog-only, release metadata, CI/config-only, test-only, or pure internal refactors
  • Behavior requiring unavailable credentials, paid/cloud services, bot tokens, deploy-only infrastructure, or hardware not provided
This skill does NOT prompt the user to capture evidence. The decision logic is:
  1. PR mode invocation (any form: bare number, 
    #NN
    , 
    pr:<N>
    , or a full URL — anything that resolves to an existing PR whose body we fetched) and the existing body contains a 
    ## Demo
    or 
    ## Screenshots
    section with image embeds:     preserve it verbatim unless the steering text asks to refresh or remove it. Include the preserved block in the returned body. This applies regardless of which input shape the caller used; what matters is that a PR exists and its body was read.
  2. Current-branch mode or PR mode without an evidence block: omit the evidence section entirely. If the caller wants to capture evidence, the caller is responsible for invoking 
    ce-demo-reel
    separately and splicing the result in, or for asking this skill to regenerate with updated steering text after capture.
Do not label test output as "Demo" or "Screenshots". Place any preserved evidence block before the Compound Engineering badge.
判断是否可从完整分支差异中捕获证据。
可捕获证据：当差异改变了可从工作区演示的可观察行为时，包括UI、CLI输出、可运行代码的API行为、生成的工件或工作流输出。
不可捕获证据：
  • 仅文档、仅Markdown、仅变更日志、发布元数据、仅CI/配置、仅测试或纯内部重构
  • 需要不可用凭证、付费/云服务、机器人令牌、仅部署基础设施或未提供硬件的行为
此技能不会提示用户捕获证据。决策逻辑如下：
  1. PR模式调用（任意形式：纯数字、
    #NN
    、
    pr:<N>
    或完整URL——任何可解析为现有PR且已获取其正文的调用）且现有正文包含带有图片嵌入的
    ## Demo
    或
    ## Screenshots
    部分    ：除非指导文本要求刷新或移除，否则原样保留。将保留的块包含在返回的正文中。无论调用者使用何种输入格式，只要PR存在且已读取其正文，此规则均适用。
  2. 当前分支模式或无证据块的PR模式：完全省略证据部分。若调用者希望捕获证据，需单独调用
    ce-demo-reel
    并将结果插入，或在捕获后要求此技能使用更新的指导文本重新生成。
不得将测试输出标记为“Demo”或“Screenshots”。将保留的证据块放在Compound Engineering徽章之前。

Step 4: Frame the narrative before sizing

步骤4：编写前构建叙述框架

Articulate the PR's narrative frame:
  1. Before: What was broken, limited, or impossible? (One sentence.)
  2. After: What's now possible or improved? (One sentence.)
  3. Scope rationale (only if 2+ separable-looking concerns): Why do these ship together? (One sentence.)
This frame becomes the opening. For small+simple PRs, the "after" sentence alone may be the entire description.
明确PR的叙述框架：
  1. 之前：存在哪些问题、限制或无法实现的功能？（一句话）
  2. 之后：现在可实现或改进了什么？（一句话）
  3. 范围理由（仅当存在2个及以上可分离的关注点时）：为何这些变更要一起发布？（一句话）
此框架作为描述的开头。对于小型简单PR，仅“之后”一句话即可构成完整描述。

Step 5: Size the change

步骤5：评估变更规模

Assess size (files, diff volume) and complexity (design decisions, trade-offs, cross-cutting concerns) to select description depth:
Change profileDescription approach
Small + simple (typo, config, dep bump)1-2 sentences, no headers. Under ~300 characters.
Small + non-trivial (bugfix, behavioral change)Short narrative, ~3-5 sentences. No headers unless two distinct concerns.
Medium feature or refactorNarrative frame (before/after/scope), then what changed and why. Call out design decisions.
Large or architecturally significantNarrative frame + up to 3-5 design-decision callouts + 1-2 sentence test summary + key docs links. Target ~100 lines, cap ~150. For PRs with many mechanisms, use a Summary-level table to list them; do NOT create an H3 subsection per mechanism. Reviewers scrutinize decisions, not inventories — the diff and spec files carry the detail. If you find yourself writing 10+ subsections, consolidate to a table.
Performance improvementInclude before/after measurements if available. Markdown table works well.
When in doubt, shorter is better. Match description weight to change weight. Large PRs need MORE selectivity, not MORE content.
评估变更规模（文件数量、差异量）和复杂度（设计决策、权衡、跨领域关注点），选择描述深度：
变更类型描述方式
小型且简单（拼写错误、配置、依赖版本升级）1-2句话，无标题。约300字符以内。
小型但非 trivial（ bug修复、行为变更）简短叙述，约3-5句话。除非存在两个不同关注点，否则无标题。
中型特性或重构叙述框架（之前/之后/范围），然后说明变更内容及原因。突出设计决策。
大型或架构级变更叙述框架 + 最多3-5个设计决策要点 + 1-2句话的测试总结 + 关键文档链接。目标约100行，上限约150行。对于包含多种机制的PR，使用摘要级表格列出这些机制；不得为每个机制创建H3子节。评审者关注的是决策，而非清单——差异和规范文件已包含详细信息。若发现自己编写了10+个子节，需合并为一个标题下的表格，每行对应一个机制。
性能优化若有可用数据，包含前后对比测量结果。Markdown表格效果良好。
存疑时，优先选择更简短的描述。描述篇幅需与变更规模匹配。大型PR需要更高的选择性，而非更多内容。

Step 6: Apply writing principles

步骤6：应用写作原则

Writing voice

写作风格

If the repo has documented style preferences in context, follow those. Otherwise:
  • Active voice. No em dashes or 
    --
    substitutes; use periods, commas, colons, or parentheses.
  • Vary sentence length. Never three similar-length sentences in a row.
  • Do not make a claim and immediately explain it. Trust the reader.
  • Plain English. Technical jargon fine; business jargon never.
  • No filler: "it's worth noting", "importantly", "essentially", "in order to", "leverage", "utilize."
  • Digits for numbers ("3 files"), not words ("three files").
若仓库上下文有记录的风格偏好，需遵循这些偏好。否则：
  • 使用主动语态。不要使用破折号或
    --
    替代；使用句号、逗号、冒号或括号。
  • 变换句子长度。不得连续使用三个相似长度的句子。
  • 不要先提出主张再立即解释。信任读者的理解能力。
  • 使用简洁英语。可使用技术术语；禁止使用业务术语。
  • 无冗余内容：“值得注意的是”“重要的是”“本质上”“为了”“利用”“使用”等词汇一律删除。
  • 数字使用阿拉伯数字（“3 files”），而非英文单词（“three files”）。

Writing principles

写作原则

  • Lead with value: Open with what's now possible or fixed, not what was moved around. The subtler failure is leading with the mechanism ("Replace the hardcoded capture block with a tiered skill") instead of the outcome ("Evidence capture now works for CLI tools and libraries, not just web apps").
  • No orphaned opening paragraphs: If the description uses 
    ##
    headings anywhere, the opening must also be under a heading (e.g., 
    ## Summary
    ). For short descriptions with no sections, a bare paragraph is fine.
  • Describe the net result, not the journey: The description covers the end state, not how you got there. No iteration history, debugging steps, intermediate failures, or bugs found and fixed during development. This applies equally when regenerating for an existing PR: rewrite from the current state, not as a log of what changed since the last version. Exception: process details critical to understand a design choice.
  • When commits conflict, trust the final diff: The commit list is supporting context, not the source of truth. If commits describe intermediate steps later revised or reverted, describe the end state from the full branch diff.
  • Explain the non-obvious: If the diff is self-explanatory, don't narrate it. Spend space on things the diff doesn't show: why this approach, what was rejected, what the reviewer should watch.
  • Use structure when it earns its keep: Headers, bullets, and tables aid comprehension, not mandatory template sections.
  • Markdown tables for data: Before/after comparisons, performance numbers, or option trade-offs communicate well as tables.
  • No empty sections: If a section doesn't apply, omit it. No "N/A" or "None."
  • Test plan — only when non-obvious: Include when testing requires edge cases the reviewer wouldn't think of, hard-to-verify behavior, or specific setup. Omit when "run the tests" is the only useful guidance. When the branch adds test files, name them with what they cover.
  • No Commits section: GitHub already shows the commit list in its own tab. A Commits section in the PR body duplicates that without adding context. Omit unless the commits need annotations explaining their ordering or shipping rationale.
  • No Review / process section: Do not include a section describing how the reviewer should review (checklists of things to look at, process bullets). Process doesn't help the reviewer evaluate code. Call out specific non-obvious things to scrutinize inline with the change that warrants it.
  • 以价值为开头：开头说明现在可实现的功能或已修复的问题，而非变更了哪些内容。常见错误是先描述机制（“将硬编码捕获块替换为分层技能”），而非结果（“证据捕获现在适用于CLI工具和库，而非仅Web应用”）。
  • 无孤立开头段落：若描述中使用了
    ##
    标题，则开头也必须放在标题下（例如
    ## Summary
    ）。对于无章节的简短描述，可直接使用段落。
  • 描述最终结果，而非过程：描述针对最终状态，而非实现过程。不得包含迭代历史、调试步骤、中间失败或开发过程中发现并修复的bug。此规则同样适用于为现有PR重新生成描述：基于当前状态重写，而非记录自上一版本以来的变更。例外：对理解设计选择至关重要的过程细节。
  • 提交与差异冲突时，信任最终差异：提交列表是辅助上下文，而非事实来源。若提交描述了后续被修改或回退的中间步骤，需基于完整分支差异描述最终状态。
  • 解释非显而易见的内容：若差异可自行解释，则无需赘述。将篇幅用于差异未体现的内容：为何选择此方案、拒绝了哪些方案、评审者需关注的要点。
  • 仅在必要时使用结构：标题、项目符号和表格有助于理解，但并非强制模板章节。
  • 数据使用Markdown表格：前后对比、性能数据或选项权衡使用表格更清晰。
  • 无空章节：若章节不适用，则省略。不得使用“N/A”或“无”。
  • 测试计划——仅在非显而易见时包含：当测试需要评审者想不到的边缘案例、难以验证的行为或特定设置时，需包含测试计划。若“运行测试”是唯一有用的指导，则省略。当分支添加测试文件时，需注明文件对应的测试内容。
  • 无提交章节：GitHub已在单独的标签页中显示提交列表。PR正文中的提交章节属于重复内容，无额外价值。除非提交需要注释说明其顺序或发布理由，否则省略。
  • 无评审/流程章节：不得包含描述评审者应如何评审的章节（需检查事项清单、流程项目符号）。流程对评审者评估代码无帮助。若有特定非显而易见的要点需评审，需在对应的变更内容附近注明。

Visual communication

视觉传达

Include a visual aid only when the change is structurally complex enough that a reviewer would struggle to reconstruct the mental model from prose alone.
The core distinction — structure vs. parallel variation:
  • Use a Mermaid diagram when the change has topology — components with directed relationships (calls, flows, dependencies, state transitions, data paths). Diagrams express "A talks to B, B talks to C, C does not talk back to A" in a way tables cannot.
  • Use a markdown table when the change has parallel variation of a single shape — N things that share the same attributes but differ in their values. Tables express "option 1 costs X, option 2 costs Y, option 3 costs Z" cleanly.
Architecture changes are almost always topology (components + edges), so Mermaid is usually the right call — a table of "components that interact" loses the edges and becomes a flat list. Reserve tables for genuinely parallel data: before/after measurements, option trade-offs, flag matrices, config enumerations.
When to include (prefer Mermaid, not a table, for architecture/flow):
PR changes...Visual aid
Architecture touching 3+ interacting components (the components have directed relationships — who calls whom, who owns what, which skill delegates to which)Mermaid component or interaction diagram. Do not substitute a table — tables cannot show edges.
Multi-step workflow or data flow with non-obvious sequencingMermaid flow diagram
State machine with 3+ states and non-trivial transitionsMermaid state diagram
Data model changes with 3+ related entitiesMermaid ERD
Before/after performance or behavioral measurements (same metric, different values)Markdown table
Option or flag trade-offs (same attributes evaluated across variants)Markdown table
Feature matrix / compatibility gridMarkdown table
When in doubt, ask: "Does the information have edges (A → B) or does it have rows (attribute × variant)?" Edges → Mermaid. Rows → table. Architecture has edges almost by definition.
When to skip any visual:
  • Sizing routes to "1-2 sentences"
  • Prose already communicates clearly
  • The diagram would just restate the diff visually
  • Mechanical changes (renames, dep bumps, config, formatting)
Format details:
  • Mermaid (default for topology). 5-10 nodes typical, up to 15 for genuinely complex changes. Use 
    TB
    direction. Source should be readable as fallback.
  • ASCII diagrams for annotated flows needing rich in-box content. 80-column max.
  • Markdown tables for parallel-variation data only.
  • Place inline at point of relevance, not in a separate section.
  • Prose is authoritative when it conflicts with a visual.
Verify generated diagrams against the change before including.
仅当变更结构足够复杂，导致评审者难以仅通过文字构建心智模型时，才包含视觉辅助内容。
核心区别——结构与并行变体：
  • 当变更具有拓扑结构（组件间存在定向关系：调用关系、流程、依赖、状态转换、数据路径）时，使用Mermaid图。图可清晰表达“A调用B，B调用C，C不回调A”，而表格无法做到这一点。
  • 当变更具有单一形态的并行变体（N个事物具有相同属性但值不同）时，使用Markdown表格。表格可清晰表达“选项1成本为X，选项2为Y，选项3为Z”。
架构变更几乎总是拓扑结构（组件+关联），因此Mermaid通常是正确选择——“交互组件”表格会丢失关联关系，变成扁平列表。表格仅适用于真正的并行数据：前后测量结果、选项权衡、标志矩阵、配置枚举。
何时包含（架构/流程优先选择Mermaid，而非表格）：
PR变更内容...视觉辅助
涉及3个及以上交互组件的架构变更（组件间存在定向关系——谁调用谁、谁拥有什么、哪个技能委托给哪个）Mermaid组件或交互图。不得用表格替代——表格无法显示关联关系。
多步骤工作流或数据流程，且顺序非显而易见Mermaid流程图
包含3个及以上状态和复杂转换的状态机Mermaid状态图
涉及3个及以上相关实体的数据模型变更Mermaid实体关系图（ERD）
前后性能或行为测量结果（同一指标，不同值）Markdown表格
选项或标志权衡（同一属性在不同变体中的评估）Markdown表格
特性矩阵/兼容性网格Markdown表格
存疑时，问自己：“信息是否有关联关系（A → B），还是有行（属性 × 变体）？” 关联关系→Mermaid。行→表格。架构变更几乎必然有关联关系。
何时跳过视觉辅助：
  • 规模评估为“1-2句话”
  • 文字已清晰传达内容
  • 图仅为差异的视觉重复
  • 机械变更（重命名、依赖升级、配置、格式调整）
格式细节：
  • Mermaid（拓扑结构默认选择）。典型为5-10个节点，复杂变更最多15个节点。使用
    TB
    方向。源代码需可读，作为 fallback。
  • ASCII图用于需要丰富内置内容的带注释流程。最大80列。
  • Markdown表格仅用于并行变体数据。
  • 内联在相关位置，而非单独章节。
  • 当文字与视觉内容冲突时，以文字为准。
包含前需验证生成的图是否与变更一致。

Numbering and references

编号与引用

Never prefix list items with 
#
in PR descriptions — GitHub interprets 
#1
, 
#2
as issue references and auto-links them.
When referencing actual GitHub issues or PRs, use 
org/repo#123
or the full URL. Never use bare 
#123
unless verified.
PR描述中不得使用
#
作为列表项前缀——GitHub会将
#1
、
#2
解析为问题引用并自动链接。
引用实际GitHub问题或PR时，使用
org/repo#123
或完整URL。除非已验证，否则不得使用纯
#123
。

Applying the focus hint

应用聚焦提示

If a 
focus:
hint was provided, incorporate it alongside the diff-derived narrative. Treat focus as steering, not override: do not invent content the diff does not support, and do not suppress important content the diff demands simply because focus did not mention it. When focus and diff materially disagree (e.g., focus says "include benchmarking" but the diff has no benchmarks), note the conflict in a way the caller can see (leave a brief inline note or raise to the caller) rather than fabricating content.
若提供了
focus:
提示，需将其与基于差异生成的叙述内容结合。将聚焦视为指导，而非强制覆盖：不得编造差异不支持的内容，也不得因聚焦未提及而压制差异要求的重要内容。当聚焦与差异存在实质性冲突（例如聚焦要求“包含基准测试”但差异中无基准测试），需以调用者可见的方式指出冲突（留下简短内联注释或告知调用者），而非编造内容。

Step 7: Compose the title

步骤7：撰写标题

Title format: 
type: description
or 
type(scope): description
.
  • Type is chosen by intent, not file extension or diff shape. 
    feat
    for new functionality, 
    fix
    for a bug fix, 
    refactor
    for a behavior-preserving change, 
    docs
    for doc-only, 
    chore
    for tooling/maintenance, 
    perf
    for performance, 
    test
    for test-only. Where 
    fix
    and 
    feat
    could 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. The user may override.
  • Scope (optional) is the narrowest useful label: a skill/agent name, CLI area, or shared area. Omit when no single label adds clarity.
  • Description is imperative, lowercase, under 72 characters total. No trailing period.
  • If the repo has commit-title conventions visible in recent commits, match them.
Breaking changes use 
!
(e.g., 
feat!: ...
) or document in the body with a 
BREAKING CHANGE:
footer.
标题格式：
type: description
或
type(scope): description
。
  • Type根据意图选择，而非文件扩展名或差异形态。
    feat
    用于新功能，
    fix
    用于bug修复，
    refactor
    用于不改变行为的变更，
    docs
    用于仅文档变更，
    chore
    用于工具/维护，
    perf
    用于性能优化，
    test
    用于仅测试变更。当
    fix
    和
    feat
    均适用时，默认选择
    fix
    ：修复损坏或缺失行为的变更，即使通过添加代码实现，也属于
    fix
    。
    feat
    仅用于用户之前无法实现的功能。用户可覆盖此选择。
  • Scope（可选）是最窄的有用标签：技能/Agent名称、CLI领域或共享领域。若没有单一标签能增加清晰度，则省略。
  • Description为祈使语气、小写，总长度不超过72字符。无结尾句号。
  • 若仓库近期提交有可见的标题规范，需匹配该规范。
破坏性变更使用
!
（例如
feat!: ...
），或在正文中用
BREAKING CHANGE:
脚注说明。

Step 8: Compose the body

步骤8：撰写正文

Assemble the body in this order:
  1. Opening -- the narrative frame from Step 4, at the depth chosen in Step 5. Under a heading (e.g., 
    ## Summary
    ) if the description uses any 
    ##
    headings elsewhere; a bare paragraph otherwise.
  2. Body sections -- only the sections that earn their keep for this change: what changed and why, design decisions, tables for data, visual aids when complexity warrants. Skip empty sections entirely.
  3. Test plan -- only when non-obvious per the writing principles. Omit otherwise.
  4. Evidence block -- only the preserved block from Step 3, if one exists. Do not fabricate or placeholder.
  5. Compound Engineering badge -- append a badge footer separated by a 
    ---
    rule. Skip if the existing body (for 
    pr:
    input) already contains the badge.
Badge:
markdown
---

[![Compound Engineering](https://img.shields.io/badge/Built_with-Compound_Engineering-6366f1)](https://github.com/EveryInc/compound-engineering-plugin)
![HARNESS](https://img.shields.io/badge/MODEL_SLUG-COLOR?logo=LOGO&logoColor=white)
Harness lookup:
Harness
LOGO
COLOR
Claude Code
claude
D97757
Codex(omit logo param)
000000
Gemini CLI
googlegemini
4285F4
Model slug: Replace spaces with underscores. Append context window and thinking level in parentheses if known. Examples: 
Opus_4.6_(1M,_Extended_Thinking)
, 
Sonnet_4.6_(200K)
, 
Gemini_3.1_Pro
.
按以下顺序组装正文：
  1. 开头——步骤4中的叙述框架，深度由步骤5确定。若描述中使用了任何
    ##
    标题，则开头需放在标题下（例如
    ## Summary
    ）；否则直接使用段落。
  2. 正文章节——仅包含对当前变更有必要的章节：变更内容及原因、设计决策、数据表格、复杂度需要时的视觉辅助。完全省略空章节。
  3. 测试计划——仅在写作原则要求的非显而易见场景下包含。否则省略。
  4. 证据块——仅包含步骤3中保留的块（若存在）。不得编造或占位。
  5. Compound Engineering徽章——添加由
    ---
    分隔的徽章页脚。若（针对
    pr:
    输入的）现有正文已包含徽章，则跳过。
徽章：
markdown
---

[![Compound Engineering](https://img.shields.io/badge/Built_with-Compound_Engineering-6366f1)](https://github.com/EveryInc/compound-engineering-plugin)
![HARNESS](https://img.shields.io/badge/MODEL_SLUG-COLOR?logo=LOGO&logoColor=white)
Harness查找：
Harness
LOGO
COLOR
Claude Code
claude
D97757
Codex(省略logo参数)
000000
Gemini CLI
googlegemini
4285F4
Model slug： 将空格替换为下划线。若已知上下文窗口和思考级别，需在括号中添加。示例：
Opus_4.6_(1M,_Extended_Thinking)
、
Sonnet_4.6_(200K)
、
Gemini_3.1_Pro
。

Step 8b: Compression pass

步骤8b：压缩优化

Before writing the body to the temp file, re-read the composed body and apply these cuts:
  • If any body section restates content already in the 
    ## Summary
    , remove it. The Summary plus the diff should carry the reader.
  • If "Testing" or "Test plan" has more than 2 paragraphs, compress to bullets.
  • If a "Commits" section enumerates the commit log, remove it — GitHub shows it in its own tab.
  • If a "Review" or process-oriented section lists how to review, remove it. Move any truly non-obvious review hints inline with the relevant change.
  • If the body has 5+ H3 subsections that each describe one mechanism, consolidate them into a single table row per mechanism under one header. Reserve prose H3 callouts for 2-3 genuine design decisions.
  • If the body exceeds the sizing-table target by more than 30%, compress the longest non-Summary section by half.
Value-lead check. Re-read the first sentence of the Summary. If it describes what was moved around, renamed, or added ("This PR introduces three-tier autofix..."), rewrite to lead with what's now possible or what was broken and is now fixed ("Document reviews previously produced 14+ findings requiring user judgment; this PR cuts that to 4-6.").
Large PRs benefit from selectivity, not comprehensiveness.
将正文写入临时文件前，重新阅读已撰写的正文并进行以下删减：
  • 若任何正文章节重复了
    ## Summary
    中的内容，删除该章节。摘要加差异应足以让读者理解。
  • 若“Testing”或“Test plan”超过2段，压缩为项目符号。
  • 若“Commits”章节枚举了提交日志，删除该章节——GitHub已在单独标签页中显示。
  • 若“Review”或面向流程的章节列出了评审方式，删除该章节。将真正非显而易见的评审提示移至对应变更内容附近。
  • 若正文有5个及以上H3子节，每个子节描述一个机制，需将它们合并为一个标题下的表格，每行对应一个机制。仅为2-3个真正的设计决策保留H3节。
  • 若正文超出规模表目标30%以上，将最长的非摘要章节压缩一半。
价值开头检查。重新阅读摘要的第一句话。若它描述了变更的内容（“此PR引入三层自动修复...”），需重写为以价值开头（“文档评审之前会产生14+项需要用户判断的结果；此PR将其减少至4-6项。”）。
大型PR受益于选择性，而非全面性。

Step 9: Return 
{title, body_file}

步骤9：返回
{title, body_file}

Write the composed body to an OS temp file, then return the title and the file path. Do not call 
gh pr edit
, 
gh pr create
, or any other mutating command. Do not ask the user to confirm — the caller owns apply.
bash
BODY_FILE=$(mktemp "${TMPDIR:-/tmp}/ce-pr-body.XXXXXX") && cat > "$BODY_FILE" <<'__CE_PR_BODY_END__' && echo "$BODY_FILE"
<the composed body markdown goes here, verbatim>
__CE_PR_BODY_END__
The quoted sentinel 
'__CE_PR_BODY_END__'
keeps 
$VAR
, backticks, 
${...}
, and any literal 
EOF
inside the body from being expanded or clashing with the terminator. Keep 
echo "$BODY_FILE"
chained with 
&&
so a failed 
mktemp
or write never yields a success exit status with a path to a missing file.
Format the return as a clearly labeled block the caller can extract cleanly:
=== TITLE ===
<title line>

=== BODY_FILE ===
<absolute path to the mktemp body file>
Do not emit the body markdown in the return block — the caller reads it from 
BODY_FILE
.
If Step 1 exited gracefully (closed/merged PR, invalid range, empty commit list), do not create a body file — just return the reason string.
The return block is a hand-off, not task completion. When invoked by a parent skill (e.g., 
ce-commit-push-pr
), emit the return block and then continue executing the parent's remaining steps (typically 
gh pr create
or 
gh pr edit
with the returned title and body file). Do not stop after the return block unless invoked directly by the user with no parent workflow.
将撰写好的正文写入操作系统临时文件，然后返回标题和文件路径。不得调用
gh pr edit
、
gh pr create
或任何其他变更命令。不得要求用户确认——应用操作由调用者负责。
bash
BODY_FILE=$(mktemp "${TMPDIR:-/tmp}/ce-pr-body.XXXXXX") && cat > "$BODY_FILE" <<'__CE_PR_BODY_END__' && echo "$BODY_FILE"
<the composed body markdown goes here, verbatim>
__CE_PR_BODY_END__
带引号的标记
'__CE_PR_BODY_END__'
可防止正文中的
$VAR
、反引号、
${...}
和任何字面
EOF
被展开或与终止符冲突。将
echo "$BODY_FILE"
与
&&
链式调用，确保
mktemp
或写入失败时不会返回成功状态和指向不存在文件的路径。
将返回结果格式化为调用者可清晰提取的块：
=== TITLE ===
<title line>

=== BODY_FILE ===
<absolute path to the mktemp body file>
不得在返回块中输出正文Markdown——调用者从
BODY_FILE
读取。
若步骤1优雅退出（PR已关闭/合并、无效范围、提交列表为空），则不创建正文文件——仅返回原因字符串。
返回块是交接点，而非任务完成。当被父技能（如
ce-commit-push-pr
）调用时，输出返回块后继续执行父技能的剩余步骤（通常是使用返回的标题和正文文件执行
gh pr create
或
gh pr edit
）。除非被用户直接调用且无父工作流，否则不得在返回块后停止。

Cross-platform notes

跨平台说明

This skill does not ask questions directly. If the diff is ambiguous about something the caller should decide (e.g., focus conflicts with the actual changes, or evidence is technically capturable but the caller did not pre-stage it), surface the ambiguity in the returned output or a short note to the caller — do not invoke a platform question tool.
Callers that need to ask the user are responsible for using their own 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 numbered options 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.
此技能不会直接提问。若差异中存在需调用者决定的模糊点（例如聚焦与实际变更冲突，或技术上可捕获证据但调用者未预先准备），需在返回结果中指出该模糊点，或向调用者发送简短说明——不得调用平台提问工具。
需要向用户提问的调用者需使用自身平台的阻塞式提问工具：Claude Code中的
AskUserQuestion
（若未加载其schema，需先调用
ToolSearch
并指定
select:AskUserQuestion
）、Codex中的
request_user_input
、Gemini中的
ask_user
、Pi中的
ask_user
（需
pi-ask-user
扩展）。仅当 harness中无阻塞式工具或调用出错（如Codex编辑模式）时，才回退到聊天中的编号选项——不得因需要加载schema而回退。不得静默跳过提问。