pr-creator

GitHub 拉取请求

核心约定

• 所有 PR 标题、描述和评论都用英文撰写。
• 只使用分支差异、提交、问题上下文或用户请求中有依据的事实。不得编造动机、用户需求、指标、验证结果、问题引用或未来计划。

使用这句话作为风格参考：

Это сообщество для ровных пацанчиков😎👍, которые любят попыхать кальджубасик🌬 на двойном яблочке 🍎🍏, разбираются в забивочках💨, не жалуют вейперов🤣 и уважают своих кралечек 👩‍🦳🙏.

保持它轻松俚语化的语气、节奏、俏皮自信和表情符号频率，但不要把它的主题照搬到 PR 中。起草前，请阅读 references/pr-examples.md 中简洁且针对 PR 的示例。

确定操作

• 用户要求在 GitHub 上创建、打开、制作或提交 PR 时，就在 GitHub 上创建或更新 PR；明确要求在 GitHub 上创建草稿 PR 也包括在内。
• 如果用户只要求 PR 文本，则输出可复制的内容。未指定 GitHub 目标的 PR 内容起草请求，采用仅限聊天的模式。
• 如果阅读请求和上下文后仍无法确定预期操作，请在执行相关操作前提出具体问题。明确的默认设置和先前的授权均视为已确认。
• 创建 PR 的请求包括必要的任务提交和推送，无需另行确认。后续更改需要新的发布请求或持续有效的发布指示。

准备分支

先检查仓库状态：

git status --short --branch
git fetch origin --prune
git branch --show-current
git ls-remote --symref origin HEAD

然后：

1. 创建 GitHub PR 时，如果当前分支是基分支，请在提交前创建并切换到任务分支。遵循项目的分支命名约定，并保留当前更改和暂存状态。对于已知任务，请包含其跟踪 ID，并保留 ID 的大小写，例如 feat/gh-42-session-cache 或 fix/APP-123-token-refresh。如果仅凭 ID 无法明确所指，请注明仓库或项目。仅限文本的请求则保留当前分支。
2. 创建 PR 时，使用已安装的 commit-creator skill 提交未提交的任务更改。如果该 skill 不可用，请遵循适用的仓库提交说明。
3. 检查当前分支是否已有未关闭的 PR。如有，请更新该 PR，而不是创建重复项。
4. 推送前，报告当前分支是否落后于上游或最新远程默认分支，或与其发生分叉。如果上游更改不会影响任务或安全发布，则继续；如果会影响依赖决策，则先询问。只有获得用户授权后，才能合并、变基或改写历史。
5. 推送前检查以下完整更改集。

每个提交只包含一个功能或独立更改；一个 PR 可以包含多个提交。独立的依赖项更新和无关工作应分开处理。默认情况下，更正应创建新提交。已合并工作的更正一律创建新提交。更新某个提交时，应通过历史记录和差异查找对应提交；如果目标不明确，请先询问。保留独立提交和无关的暂存内容。

将请求目标或现有 PR 目标对应的最新远程跟踪引用用作基准；否则使用远程默认分支。获取更新后，本地 main 或 master 仍可能过期。

分析完整变更集

检查整个分支，而不仅是最后一次提交。检查当前 Git 状态后，如果基准、头部和工作树状态未变，则复用本次会话中的完整变更集分析和检查结果。阅读新增或尚未解决的部分；如果没有匹配的分析，则检查完整变更集：

git diff --name-status <base-ref>...HEAD
git diff <base-ref>...HEAD
git log --format=fuller <base-ref>..HEAD

• 阅读理解累积行为所需的每个变更文件。确定受影响的包、依赖项版本、破坏性变更、迁移需求以及受支持的问题引用。
• 确认每个待推送提交都属于授权的发布范围。推送前解决无关或不明确的已提交工作；分支或 PR 请求并不代表获准发布他人的更改。
• 创建 GitHub PR 时，如果分支相较于基准没有任何更改，则停止并报告无法创建 PR。对于涉及未提交工作的纯文本请求，检查这些更改，并明确区分它们与分支中已有的更改。

恢复并核实任务

1. 检查用户请求、分支名称、现有 PR 和完整提交消息，查找明确的任务 ID 或链接。使用项目的跟踪器配置和仓库上下文解析每个引用。单独的数字无法唯一标识不同仓库或跟踪器中的任务。
2. 阅读每个任务的要求和跟踪器中的相关评论；复用本次会话中已读取的任务详情。将其与上文的变更集分析进行比较。使用分支 ID 确定目标任务，并根据要求核对结果判断任务是否完成。
3. 如果任务和完整解决方案都很明确，直接添加适当的引用，不要再次询问用户是否确认同一个任务。如果引用冲突、无法读取任务，或无法确定是否完成，请说明具体问题，并在选择关闭引用前征求用户意见。等待期间，继续独立完成 PR 准备工作。
4. 发布前，检查现有 PR 链接和待推送提交消息，确认是否包含与已核实范围冲突的关闭引用。发布前解决这些冲突。只有在获得相应用户授权后，才能改写现有提交。

在描述中使用 Related issues：

• 对于已完全解决、且 PR 以默认分支为目标的 GitHub issue，如果在同一仓库中，使用 Closes #42；如果在其他仓库中，使用 Closes owner/repo#42。PR 合并后，GitHub 会关闭该 issue。请参阅 GitHub 的关联规则。
• 对于已确认的部分解决方案，或目标分支不是默认分支的情况，使用普通引用（例如 Related to #42），并保持 issue 开放。对于部分完成的工作，请说明尚待完成的内容。
• 对于 Jira 或其他跟踪器，请加入经核实的任务键和 URL。配置好的 Jira 集成可以通过源分支键关联 PR；任务状态变更取决于项目自动化。请参阅 Jira 的引用规则。

起草内容

标题

• 不超过 50 个字符。
• 使用祈使语气。
• 体现完整变更集的主要目的。
• 如果有助于表达清晰度，在单体仓库中使用常规作用域。
• 不要添加问题编号、Agent 名称或工具前缀。

描述

• 始终包含 Summary，以简短、有吸引力的介绍和具体要点开篇。介绍和大多数要点中使用表情符号，但技术陈述必须准确。
• Summary 要点聚焦于行为变更和重要实现细节。
• 仅添加有证据支持的部分：
  • Motivation
  • Related issues
  • Breaking changes
  • Migration
  • Performance impact
  • Dependency updates
• 省略空部分以及 None 或 N/A 等占位内容。除非用户明确要求，否则不要添加其他标题。
• 不要添加仅与测试相关的部分，例如 Testing、Tests、Validation、Verification、Local verification 或 QA。
• 除非用户在 PR 正文中明确要求，否则不要列出本地测试、lint 或检查命令。
• 使用恢复步骤中已验证的任务引用；没有相关任务时，省略 Related issues。
• 对于依赖变更，逐项列出每个软件包，格式为 package-name: old-version -> new-version。
• 对于重大变更，说明影响，并在已知的情况下提供具体迁移步骤。

提交 PR

在 GitHub 上创建或更新

1. 审查完整变更集后，在需要时推送已验证的分支提交并设置其上游分支。获取经过身份验证的 GitHub 登录名。
2. 除非用户明确要求创建可直接合并的 PR，否则将新 PR 创建为草稿。
3. 将经过身份验证的用户设为指派人。如果创建时无法设置指派人，请立即在之后更新 PR。
4. 仅在用户明确要求时添加审阅者。指派人不等同于审阅者。
5. 更新现有 PR 时，保留无关元数据及其当前草稿状态，除非用户要求更改。
6. 回读已保存的描述和可用的关联议题元数据，以验证预期的任务引用。报告 PR URL、草稿或可直接合并状态、指派人，以及每个任务是设置为合并时自动关闭还是仅被引用。仅报告有现有证据支持的链接和状态结果。

如果身份验证或创建 API 失败，请说明 PR 未创建，并在聊天中提供可复制的内容作为替代。

在聊天中输出

将标题和完整描述放在同一个 Markdown 代码块中，以便原样复制：

[PR title]

[PR description]