| name | issue-pr |
| description | 创建 Pull Request。支持 manual 模式（直接 API 创建）和 auto 模式（直接创建 draft PR）。 负责确认 PR 基本前提、关联 Issue、起草 PR 文案。 |
| argument-hint | [Issue 编号]（可选，默认自动推断） |
| disable-model-invocation | false |
| allowed-tools | ["Read","Write","Glob","Grep","AskUserQuestion","Bash(git status *)","Bash(git diff *)","Bash(git log *)","Bash(git branch *)","Bash(git show *)","Bash(git remote -v)","Bash(git rev-parse *)","Bash(git push *)","Bash(gh auth status *)","Bash(gh pr create *)","Bash(gh pr list --head *)","Bash(gh issue view --comments *)","Bash(gh issue view * --json *)","Bash(mktemp *)","Bash(rm *)"] |
创建 PR。该 skill 只负责 PR 草稿和创建，不负责测试、review、commit、push 或分支收尾。创建完成后，流程应进入 review 闭环，而不是直接结束。
前置条件
- 当前不在
main/master 等主分支
- 当前变更已经过验证，适合进入评审
- 本 skill 负责在创建 PR 前确保当前分支已推送到远端
执行步骤
1. 前置检查
- 运行
gh auth status，失败则停止，提示运行 gh auth login -h github.com
- 运行
git remote -v 确认仓库
- 确认当前分支不是 main/master，否则停止
- 运行
git status，如果存在未提交变更，提示用户先处理提交，再继续创建 PR
2. 检测运行模式
检查 .issue-flow/mode：
- 如果存在且内容为
auto → auto 模式
- 否则 → manual 模式（默认）
3. 关联 Issue
按以下优先级尝试提取 Issue 编号：
- 分支名中的数字（如
feature/123-xxx → #123）
git log 中 Refs/Fixes/Closes/Resolves #N 引用- 当前分支已有的 PR（
gh pr list --head <branch>）
$ARGUMENTS 中的 Issue 编号
提取到编号后，优先运行 gh issue view <N> --json title,body,labels 读取 Issue 标题、正文和 labels；如有必要再运行 gh issue view <N> --comments 补充上下文，用于生成 PR 标题、正文和默认 label。
如果所有来源都无法提取：
- 提示用户手动提供 Issue 编号
- 如果用户明确表示没有关联 Issue，可以继续，但不得编造关联关系
4. 检查是否已存在 PR
- 运行
gh pr list --head <branch>
- 如果当前分支已经存在 open PR，停止并返回已有 PR 信息，避免重复创建
5. 确保远端分支
确保当前分支已推送到远端：
- 若
origin/<branch> 不存在，manual 模式先展示将执行的 push 命令并等待确认，然后运行 git push -u origin <branch>
- 若
origin/<branch> 不存在，auto 模式直接 push 当前分支：git push -u origin <branch>
- 若远端分支已存在，运行
git push 更新当前分支
- push 失败则停止，不创建 PR，输出失败原因和下一步处理建议
6. 起草 PR 内容
- 根据
references/templates.md 中的 PR 模板起草内容，优先使用 Write 写入 mktemp 创建的临时文件，避免依赖 shell 重定向
- PR 标题必须使用中文，概括当前分支的最终交付内容，不使用英文 Conventional Commits 格式
- 如果已关联 Issue，在正文中加入
Closes #N
- PR 正文必须使用中文
- 如果已关联 Issue，默认继承 Issue 的首个 label 作为 PR label；如果未关联 Issue，则按变更类型推断默认 label：新功能→enhancement、缺陷修复→bug、代码重构→refactor、文档更新→documentation、工具/CI/构建→chore、性能优化→performance、依赖升级→dependencies
- 创建时默认将 PR 指派给当前登录用户（
@me）
- 变更说明必须严格来源于
git diff、提交记录和 Issue 内容，不编造
7. 创建 PR
Manual 模式
- 先向用户展示 PR 标题和正文草稿，供其确认
- 运行以下命令：
TMPFILE=$(mktemp /tmp/pr-draft.XXXXXX.md)
gh pr create --draft --title "..." --label "..." --assignee "@me" --body-file "$TMPFILE"
rm -f "$TMPFILE"
⛔ 禁止使用 --web：--web 会打开浏览器等待用户手动操作，在 CLI/TUI 环境中不可用。始终通过 API 直接创建 PR。Manual 模式默认创建为 Draft PR，由用户在 GitHub 页面确认无误后手动发布，避免过早触发 CI 或通知。
- 命令结束后清理临时文件
Auto 模式
直接执行：
TMPFILE=$(mktemp /tmp/pr-draft.XXXXXX.md)
gh pr create --draft --title "..." --label "..." --assignee "@me" --body-file "$TMPFILE"
rm -f "$TMPFILE"
捕获并输出 PR URL。
规则
issue-pr 不负责 commit 规范、测试规范、review 流程和分支清理- 成功创建 PR 后，后续流程进入
reviewing 阶段
- PR 标题和正文全部使用中文
- PR 创建时默认添加 label，并优先继承关联 Issue 的首个 label
- 创建 PR 时默认使用
--assignee "@me" 将其分配给自己
- auto 模式下默认创建 draft PR，避免过早进入正式评审
- 找到 Issue 时，正文应关联 Issue（
Closes #N）
- 创建 PR 前必须确保当前分支已推送到远端
- manual 模式下直接通过 API 创建 PR（⛔ 禁止使用
--web），由用户确认后提交
- 未找到关联 Issue 时提示用户，不编造关联关系
- 不要编造变更内容 — 严格从
git diff 和 Issue 中提取
