ce-commit-push-pr

从工作变更转变为开放 PR，并提供适应性强、价值优先的描述，随着变更的深入进行扩展。或者重写现有的 PR 描述。或者在不接触 git 的情况下生成描述。

ce-commit-push-pr 是 运输 技能。三种模式——完整的工作流程、现有 PR 的描述更新、仅描述生成——可以处理“我想发货”的常见形状，而无需强迫您执行不必要的步骤。 PR 描述适应更改的复杂性（而不是千篇一律的模板）并涵盖完整的 PR 提交范围，而不仅仅是调用时的工作树差异。

该技能对一些已经烧毁过去贡献者的具体事情有自己的看法：它从不 git add -A，它在存在时将自然不同的关注点分割成单独的提交，并且它通过临时文件写入 PR 主体（从不通过标准输入管道，它可以默默地生成空的 PR 主体，而 gh 仍然存在 0）。

复合工程构思链是/ce-ideate → /ce-brainstorm → /ce-plan → /ce-work。 ce-commit-push-pr 是 /ce-work 的第 4 阶段移交目标 — 它生成带有摘要、测试说明、证据（当行为可观察时）和操作验证部分的 PR。当您已经编写了代码并想要发布时，通常也会直接调用它。

TL;DR

＃＃ 问题

从“编写代码”到“公关公开”应该是一步之遥，但它往往会以可预见的方式失败：

• 千篇一律的 PR 描述，不会随着复杂性而扩展 - 一行错误修复和 2,000 行重构获得相同的摘要/测试计划/注释形状
• git add -A 清除非预期文件（.env、构建工件、生成的文件）
• 描述仅涵盖调用时的工作树差异，缺少已推送的提交
• 通过标准输入管道清空 PR 主体 — --body-file -、heredoc-to-stdin 或 --body "$(cat ...)" 可以默默地生成一个空 PR 主体，而 gh 仍然存在 0 并返回 URL
• 约定检测错误 - 即使存储库有自己明确建立的风格，也会回到默认约定
• 分支状态惊喜 - 在默认分支上提交，在分离的 HEAD 上创建提交，推送到陈旧的基础

解决方案

ce-commit-push-pr 显式处理每一个：

• 三种模式调度 — 完整工作流程/描述更新/仅描述生成
• 自适应 PR 描述 — 随变化而变化的深度尺度；一行修复得到了严格的描述，大型重构得到了他们所保证的结构
• 文件级别的智能提交拆分 - 自然不同的关注点成为单独的提交（最多 2-3 个），没有 git add -p
• 分支状态决策树 - 显式处理分离的 HEAD、默认分支、未推送的提交、无上游和现有的 PR 案例
• 主体文件安全 — 每个 PR 描述都写入临时文件并通过 --body-file <path> 传递，而不是通过 stdin 传递
• 约定检测 - 上下文中的回购约定 > 最近提交历史记录 > 常规提交默认值
• 完整 PR 提交范围解析 — 描述涵盖 PR 中的所有提交，而不仅仅是工作树差异

是什么让它如此新颖

1.三种模式调度——根据实际需求选择合适的形状

该技能预先检测意图并遵循匹配路径：

• 完整工作流程 — 提交任何待处理的工作、推送并打开 PR。默认为“发送此”/“创建 PR”/“提交推送 PR”。
• 现有 PR 的描述更新 — 刷新、重写或重新聚焦现有 PR 的描述，而无需触及 git 状态。
• 仅生成描述 — 生成 PR 描述并将其打印回来，无需提交、推送或应用。由“起草 PR 描述”、“描述此 PR”或单独粘贴 PR URL 触发。

当不需要时跳过提交/推送/编辑步骤符合人们询问时的实际意思，而不是每次都强制执行完整的工作流程。

2. 适应性公关描述——随着变化而扩展

PR 描述不是从固定模板呈现的。合成步骤根据变化选择结构和深度：

• 一个简单的拼写错误修复得到了一行摘要，没有测试计划，没有注释部分
• 中等功能获得摘要+测试计划+相关背景
• 大型重构包含总结、动机、关键决策、测试计划、证据、操作说明和风险
• 组合读取完整的 PR 提交范围（不仅仅是调用时的工作树差异），因此多提交 PR 的描述反映了将落地的每个提交

3. 文件级别的智能提交拆分

当更改涉及自然不同的关注点（例如，后端模型 + 前端组件 + 文档）时，该技能会创建单独的提交（通常最多 2-3 个），并在文件级别分组。没有 git add -p （交互式块级暂存，可以跨提交分割块并破坏原子性）。当分割不明确时，一次提交就可以了。

4.分支状态决策树

每个奇怪的分支状态在决策树中都有一个明确的分支：

• Detached HEAD → 询问是否创建功能分支
• 在具有未推送提交的默认分支上 → 询问是否创建功能分支
• 在默认分支上，全部推送，无 PR →“无功能分支工作”并停止
• 功能分支，无上游 → 推送并继续
• 功能分支，全部推送，无公开 PR → 跳过提交/推送，生成描述，公开 PR
• 功能分支，全部推送，开放PR→报告最新

没有默认的静默提交，没有意外的重新推送，没有中途丢失上游错误。

5. 正文文件安全 — 避免空 PR 正文陷阱

每个 PR 描述都会写入带有引用的定界符标记的临时文件，并通过 gh ... --body-file "$BODY_FILE" 传递。该技能明确从不使用 --body-file -、stdin 管道、heredoc-to-stdin 或 --body "$(cat ...)" — 这些包装器可以默默地生成一个空的 PR 正文，而 gh 仍然退出 0 并返回 URL。引用的哨兵可防止主体内的 $VAR、反引号和杂散 EOF 标记被扩展。

6. 按优先顺序进行约定检测

对于提交消息和 PR 标题：上下文中的存储库约定优先；最近的提交历史记录是下一个信号；常规提交是后备默认值。当使用传统提交和 fix: 与 feat: 似乎都适合时，该技能默认为 fix: （即使通过添加代码实现，修复损坏或丢失行为的更改也是 fix:；feat: 用于用户以前无法完成的功能）。用户可以覆盖。

7. 证据整合

当更改具有可观察的行为（UI 渲染、CLI 输出、可运行示例的 API 行为、生成的工件）时，该技能会询问是否捕获证据并（如果是）加载 /ce-demo-reel 以捕获 GIF、终端记录或屏幕截图，然后将其作为 ## Demo 部分拼接到正文中。分类无证据情况（仅文档、仅降价、仅更改日志、仅 CI/配置、仅测试或纯内部重构）会跳过提示而不询问。代理判断还可以跳过代理编写的且已知不可观察的更改的提示（内部管道、仅类型更改等）。

8. 重写前确认现有 PR

当该技能在具有开放 PR 的分支上运行并且您希望重写描述时，它会预览 - 新摘要的前两句话加上正文行数 - 并在应用之前要求确认。前两句话吸引了审稿人的大部分注意力。如果被拒绝，您可以将焦点文本传回以进行重新生成，而无需应用任何内容。

简单示例

您在功能分支上完成了通知静音功能。您调用 /ce-commit-push-pr。

该技能检测到您位于一个有意义命名的功能分支上，没有上游，并且有四个未提交的文件，涵盖数据库迁移、模型更改、控制器更新和 UI 组件。它从最近的提交（具有范围的常规提交）中获取存储库的约定，并将工作分成两个提交（数据层；UI），在文件级别分组 - 没有交互式块分段。它使用 -u 进行推送。

它解析 PR 提交范围，读取所有提交的差异（不仅仅是工作树差异），并检测具有可观察 UI 行为的更改。它询问是否采集证据；你说是；它加载 /ce-demo-reel 并获取 GIF。

组合过程会生成一个标题 (feat(notifications): add per-type mute with TTL) 和一个包含摘要、关键决策、测试计划、演示 GIF 和操作验证部分的正文。它将主体写入带有引用的定界符标记的临时文件并运行 gh pr create --title ... --body-file ...。

它返回 PR URL。

何时去实现它

在以下情况下使用 ce-commit-push-pr：

• 你的代码已经写好了，你想要提交 + PR
• 您想要重写现有 PR 的描述（例如，合并到 main 后，原始描述已过时）
• 您需要一份 PR 描述草稿，但尚未提交或推送
• 您需要自适应描述大小而不是千篇一律的模板
• 当您的更改涉及不同的问题时，您需要智能提交拆分

在以下情况下跳过 ce-commit-push-pr：

• 您只想提交而不推送或 PR → /ce-commit
• 您位于默认分支上，并且想要实际提交 → 手动处理（如果没有显式功能分支创建，此技能不会推送到默认分支）
• PR 的形状很不寻常，需要手工制作 git 工作（交互式 rebase、复杂的历史重写）

用作工作流程的一部分

ce-commit-push-pr 是多种技能的标准运输交接：

• /ce-work 第 4 阶段 — 通过计划摘要、关键决策、测试说明、证据背景、操作验证和任何接受的已知残留
• /ce-debug 第 4 阶段（技能所属分支）— 默认为提交和 PR，成功修复后不提示；包括问题跟踪器的自动关闭语法（例如，GitHub 的 Fixes #N，Linear 的 Closes ABC-123）
• /ce-compound — 编写学习文档后，可以提交 + 推送以使用新提交更新开放的 PR

使用独立版

该技能被直接调用的次数多于作为链的一部分调用的次数：

• 全面交付 — /ce-commit-push-pr 来自具有未提交或未推送工作的功能分支
• 刷新现有 PR 的描述 — /ce-commit-push-pr "update the PR description" 或 /ce-commit-push-pr "include the benchmarking results" （尊重焦点）
• 起草描述而不应用 — /ce-commit-push-pr "draft a PR description for this branch" 打印描述供您手动复制或应用
• 描述不同的 PR — /ce-commit-push-pr <PR URL> 解析该 PR 的提交范围

当技能的模式检测选择错误的路径时，您可以使用与目标模式匹配的措辞明确提示（例如，“只写描述，不要应用它”）。

＃＃ 参考

＃＃ 常问问题

为什么采用自适应描述而不是固定模板？ 千篇一律的模板让琐碎的 PR 感觉很仪式化，而大型 PR 感觉描述不足。自适应构图根据变化选择结构和深度——一行修复得到严格的描述；大规模的重构得到了它所保证的结构。当描述与更改匹配时，审阅者的工作会更容易。

为什么使用 body-file 而不是 --body 内联？ 包装器和标准输入处理可以默默地生成一个空的 PR 正文，而 gh 仍然退出 0 并返回 URL。该技能将每个主体写入带有引用的定界符标记的临时文件，并通过 --body-file <path> 传递。引用的哨兵可防止主体内的 $VAR、反引号和文字 EOF 标记被扩展。

仅描述和描述更新之间有什么区别？ 仅描述生成描述并将其打印回来而不触及任何内容（无 gh pr edit，无提交，无推送）。描述更新查找当前分支的现有开放 PR，生成新描述，预览它，要求确认，然后通过 gh pr edit 进行应用。

它是否支持不同的提交消息约定？ 是的。 AGENTS.md/CLAUDE.md 中的回购协议优先；最近的提交历史记录是下一个信号；常规提交是后备默认值。使用常规提交时，如果不明确，fix: 与 feat: 默认为 fix:。

提交签名或挂钩怎么样？ 该技能尊重您的 git 配置和预提交挂钩。它永远不会通过 --no-verify、--no-gpg-sign 或类似标志来跳过它们。如果挂钩失败，该技能会调查并揭示根本问题。

我可以获得 PR 草稿吗？ 使用仅描述模式生成正文，然后使用 gh pr create --draft --title "..." --body-file "..." 进行应用。该技能当前不会在完整工作流程中公开草稿标志。

另请参阅

• ce-work — 第 4 阶段切换目标；标准上游调用者
• ce-debug — 在技能拥有的分支上成功修复后调用此技能
• ce-commit — 仅本地提交同级；当您不想推送或打开 PR 时使用
• ce-demo-reel — 当行为可观察时调用以捕获证据
• ce-compound — 捕获可重用的学习；可以链接回该技能来推送学习文档