create-pr

此技能会修改远程协作状态，必须明确执行。

不可妥协的规则：

1. 起草 PR 前，先阅读与真实基准分支的完整差异。
2. 遇到使用受保护分支、分支状态为空或冲突标记时，必须阻止操作。
3. 如果存在未提交的更改，先调用 commit，而不是创建误导性的 PR。
4. 创建 PR 前，先推送分支。
5. PR 的创建必须由用户主动决定。如果标题、范围、基准分支或审阅者意图不明确，先询问。

创建 PR

输入

• $request：可选的 PR 指引，例如草稿意图、审阅者提示、基准分支、标签或标题方向

目标

创建一个符合分支实际更改的 PR，并确保用户获得：

• 正确的基准分支
• 准确的标题
• 实用的正文
• 已推送的分支
• 已验证的 PR URL 和状态

步骤 0：确认这是明确的 PR 请求

此技能仅供用户主动请求时使用。

只有在用户明确要求创建或打开 PR 时，才使用此技能。

如果请求实际是：

• 仅进行代码审查，则转到审查技能
• 仅创建提交，则转到 commit
• 仅制定计划，则转到规划器

如果审阅者分配、标签、里程碑或基准分支不明确且会影响请求，请使用 AskUserQuestion。

成功标准：用户明确请求创建 PR，且预期的 PR 形式足够清晰，可以继续。

步骤 1：收集真实的分支上下文

起草任何内容前，先检查当前分支：

• 当前分支名称
• 分支跟踪状态
• 未提交的更改
• 基准分支候选项
• 超前于基准分支的提交
• 与基准分支的完整差异

规则：

• 阅读实际差异，而不只是提交消息
• 在对 PR 分类前，确定真实的基准分支
• 如果差异摘要不足以理解更改，请使用 Read 阅读已更改的文件

必要时，加载 references/pr-conventions.md，了解基准分支选择和 PR 分类启发式规则。

成功标准：你了解分支、基准分支、差异内容，以及该分支是否已准备好创建 PR。

步骤 2：验证分支是否就绪

阻止条件：

• 当前分支为 main、master 或 develop
• 相对于基准分支没有提交
• 已更改文件中存在冲突标记

如果存在未提交的更改：

• 调用 commit 技能
• 然后重新收集分支上下文，再继续

警告：

• 类型检查或 lint 失败属于警告，除非用户希望先停止并修复
• 破坏性更改不是阻止条件，但必须记录

成功标准：分支状态允许如实创建 PR。

步骤 3：根据实际差异对 PR 分类

确定：

• 类型
• 范围
• 大小
• 风险
• 是否存在破坏性更改

使用：

• 分支名称作为参考，而非事实
• 已更改的路径和模块
• 仅将提交消息作为辅助上下文
• 以完整差异作为事实依据

如果存在以下任一情况，请记录破坏性更改：

• 删除或重命名公共导出
• 路由或 API 契约更改
• 架构或迁移更改
• 环境变量更改
• 主要依赖项更改

加载 references/pr-conventions.md，了解：

• 分类启发式规则
• 标题规则
• 选项标志映射
• 阻止与警告行为

成功标准：根据实际代码更改对 PR 进行分类，而不只是依据分支命名。

步骤 4：运行范围最小且相关的质量检查

运行与已更改部分和项目工具相匹配的检查。

常见检查：

• 类型检查
• lint
• 冲突标记扫描

规则：

• 冲突标记始终是阻止条件
• 如实向用户说明其他检查失败
• 不要在 PR 正文中伪造通过状态
• 如果用户要求在已知的非阻止问题仍存在时继续，请在最终报告中明确说明

成功标准：PR 如实反映分支的实际就绪状态。

第 5 步：起草 PR 标题和正文

创建：

• 符合 Conventional Commits 风格的 PR 标题
• 说明变更内容及审核方式的正文

正文应涵盖：

• 摘要
• 分组的变更范围
• 如有重大变更，说明相关内容
• 具体的测试计划
• 可选的部署、配置或依赖变更说明

使用：

• references/pr-conventions.md，了解标题和就绪规则
• 仅在需要正文格式示例时使用 references/pr-body-examples.md

如果用户明确提供了标题要求，且仍符合实际差异，则按要求使用。

成功标准：标题和正文准确描述整个分支的变更，且便于审核。

第 6 步：推送分支并创建 PR

创建前：

• 确保分支已推送
• 如有需要，确保已设置上游分支

然后使用 gh pr create 创建 PR。

支持由请求指定的选项，例如：

• 草稿
• 审核人
• 负责人
• 标签
• 里程碑

规则：

• 分支尚未存在于远程时，不要创建 PR
• 优先使用 gh，而不是手动调用 API
• 如果 gh 不可用，则停止操作，并向用户提供准备好的标题、正文和比较 URL

成功标准：PR 已在远程创建，或用户已获得手动创建 PR 所需的准确备用材料。

第 7 步：验证并报告

创建后，验证：

• PR 编号
• URL
• 标题
• 状态
• 草稿状态
• 基础分支

还需报告：

• 是否仍有未提交的变更
• 分支是否领先于远程
• PR 流程中是否保留了任何警告

成功标准：用户清楚了解创建的 PR 详情，以及分支遗留的注意事项。

护栏

• 不要主动创建 PR。
• 不要让模型通过 SkillTool 调用此技能；此工作流仅供用户使用。
• 不要添加 paths:。这是通用工作流技能。
• 不要添加 context: fork。PR 状态必须保留在当前工作区。
• 不要在 SKILL.md 中内嵌冗长的就绪检查清单、评分卡或故障目录。
• 不要捏造测试状态、分支状态或不存在重大变更的结论。

何时加载参考资料

• references/pr-conventions.md 用于选择基础分支、分类判断、解析选项及阻断规则。
• references/pr-body-examples.md 仅在类似请求需要 PR 正文格式示例时使用。

输出要求

报告：

1. PR 编号、URL、标题、基础分支和状态
2. 是否必须先调用 commit
3. 运行过的检查及仍存在的警告
4. 已记录的任何重大变更
5. 工作树或分支的剩余状态