create-pr

创建 GitHub 拉取请求

执行自动化 PR 创建工作流，并进行全面的质量验证和安全扫描。

上下文

• 当前 Git 状态：!git status
• 当前分支：!git branch --show-current
• 尚未推送的提交：!git log --oneline -5
• GitHub 身份验证：!gh auth status
• 仓库更改：!git diff --stat HEAD~1..HEAD

需求概要

确保仓库状态干净且已完成身份验证。在创建 PR 前完成所有质量检查（lint、测试、构建、安全）。使用自动关闭关键字关联相关议题，并应用准确的标签。完整检查清单请参阅 references/requirements.md。

阶段 1：验证与分析

目标：验证仓库状态、分析更改、检测模板并找出阻碍项。

操作：

1. 确认上下文中的 GitHub 身份验证状态
2. 检查分支状态和未推送的提交
3. 分析提交历史，检查是否符合约定式提交规范
4. 找出已更改的文件并确定 PR 范围
5. 检查贡献指南（CONTRIBUTING.md）并遵循其中的要求
6. 检测 PR 模板（.github/PULL_REQUEST_TEMPLATE.md 或根目录／docs 位置）
7. 检测潜在阻碍项（合并冲突、缺少测试等）

有关模板检测和合规要求的详情，请参阅 references/repository-templates.md。

阶段 2：质量与安全检查

目标：执行全面的质量验证和安全扫描。

操作：

1. 运行项目专用的质量检查（命令请参阅 references/quality-validation.md）
2. 执行安全扫描，检查敏感文件和硬编码密钥
3. 验证提交消息格式是否符合规范
4. 如果检查失败：按照 references/failure-resolution.md 中的失败处理流程操作
5. 重新运行所有检查，直至全部通过

阶段 3：PR 组装与创建

目标：创建结构、元数据和链接均恰当的拉取请求。

操作：

1. 在推导任何内容之前，先处理 $ARGUMENTS。 它可以包含以下内容，任意组合：
   • 问题引用（Closes #456、Fixes #12 或单独的 #456）——在 PR 正文中将其原样用作自动关闭关键词；不要重新推导或质疑它。/github:resolve-issues 会将工作委托到这里，并以这种方式传入它刚刚解决的问题。
   • 自由文本描述——将其作为 PR 标题和 What/Why 部分的基础。
   • --draft——在第 6 步传递给 gh pr create。
   • --no-monitor——仅用于选择退出阶段 4；绝不能将其视为描述文本。
   • --auto-merge——在阶段 4 传递给 /github:review-pr；在审查循环中启用 CI 通过后自动合并。绝不能将其视为描述文本。 使用剩余内容作为描述／问题文本前，先移除这些标志。
2. 使用 GitHub CLI 识别并关联任何其他相关问题（除 $ARGUMENTS 中的引用外）
3. 生成 PR 标题（≤70 个字符，祈使语气，不含表情符号）
4. 按照 references/pr-structure.md 中的模板组装 PR 正文
5. 根据文件变更应用自动标签
6. 重要：只有当 PR 合并到仓库的默认分支时，自动关闭关键词才会生效。 如果目标分支不是默认分支（例如 develop），请明确警告用户，关联的问题不会在合并时自动关闭，必须手动关闭——完整规则和关键词表请参阅 references/auto-closing-keywords.md。
7. 使用 gh pr create 创建 PR，并填写所有元数据
   • 如果 $ARGUMENTS 要求使用 --draft，或者 PR 需要提前反馈或尚未完全完成，则使用 --draft
   • 按要求使用 --reviewer 设置审查者，并使用 --assignee 设置受派人
   • 对于简单变更，使用 --fill 自动填写标题／正文
8. 向用户报告最终 PR URL 和状态。此处不要在前台运行 gh pr checks --watch——阶段 4 会交由 /github:review-pr 处理，由其负责持续监控 CI；阻塞式的 --watch 会拖延当前轮次，并重复监控。
9. 重要：继续执行阶段 4。 创建 PR 并非此技能的结束。只有当 $ARGUMENTS 包含 --no-monitor 或用户明确选择退出时，才跳过阶段 4——绝不能因为 CI 看起来已通过、没有分配审查者或变更看起来很简单而跳过。

阶段 4：PR 创建后的交接（默认启用）

触发条件：默认行为——交接，除非 $ARGUMENTS 包含 --no-monitor 或用户选择退出。

目标：将 CI 监控和审查者评论分类工作委派给专用技能。

操作：创建 PR 后，调用 Skill("github:review-pr", "<PR#>")，运行基线审查并启动持续的 CI 和评论监控。review-pr 技能负责 Monitor 脚本、持怀疑态度的分类 Agent、审查 → 修复 → 提交并推送 → 等待审查循环，直至作出合并决定并完成合并后的分支清理（清理远程和本地分支头、fetch --prune、快进更新 main/develop）。CI 通过且所有评论都完成分类后，review-pr 会在收尾流程之前通过 AskUserQuestion 询问用户是否合并（合并提交/squash/rebase/不合并）——只有选择合并时，才会发布总结评论并改写正文。该合并询问由插件的 Stop hook 强制执行：review-pr 会在满足停止条件时立即启用收尾状态，并且在决定作出之前，每个用户回合结束时都会被阻止一次——交接流程无法悄然跳过该询问。有关交接约定（包括合并后的清理），请参阅 references/pr-creation-handoff.md。此技能不会重复执行该清理；这属于交接目标的职责。

--auto-merge 透传：如果 $ARGUMENTS 包含 --auto-merge，则将其透传给 review-pr 调用，写作 Skill("github:review-pr", "<PR#> --auto-merge")。此参数会指示 review-pr 跳过合并时的 AskUserQuestion——但仍会先执行收尾流程（总结评论 + 改写正文）——并在 CI 通过且所有非升级处理评论都完成分类后，使用 gh pr merge --merge 自动合并。有关约定和升级处理的回退方式，请参阅 references/pr-creation-handoff.md。只有在用户明确设置此参数时才透传；绝不能自行推断。

关键：此技能是插件唯一创建 PR 的途径。 其他技能（例如 /github:resolve-issues）会委派给此技能，而不是自行调用 gh pr create，正是为了确保没有 PR 逃过质量门禁或此交接流程。完整约定请参阅 references/pr-creation-handoff.md。不得添加绕过途径。

参考资料

• 要求：references/requirements.md - 创建前检查清单和提交规范
• 仓库模板：references/repository-templates.md - 贡献指南和 PR 模板
• 质量验证：references/quality-validation.md - Node.js/Python 验证命令
• PR 结构：references/pr-structure.md - 标题指南、正文模板、标签
• 自动关闭关键词：references/auto-closing-keywords.md - 默认分支限制和关键词表
• PR 创建交接：references/pr-creation-handoff.md - 唯一创建 PR 途径的约定
• 失败解决：references/failure-resolution.md - 协作修复失败的 Agent
• 示例：references/examples.md - 提交消息示例