issue-pr

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. 前置检查

1. 运行 gh auth status，失败则停止，提示运行 gh auth login -h github.com
2. 运行 git remote -v 确认仓库
3. 确认当前分支不是 main/master，否则停止
4. 运行 git status，如果存在未提交变更，提示用户先处理提交，再继续创建 PR

2. 检测运行模式

检查 .issue-flow/mode：

• 如果存在且内容为 auto → auto 模式
• 否则 → manual 模式（默认）

3. 关联 Issue

按以下优先级尝试提取 Issue 编号：

1. 分支名中的数字（如 feature/123-xxx → #123）
2. git log 中 Refs/Fixes/Closes/Resolves #N 引用
3. 当前分支已有的 PR（gh pr list --head <branch>）
4. $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 内容

1. 根据 references/templates.md 中的 PR 模板起草内容，优先使用 Write 写入 mktemp 创建的临时文件，避免依赖 shell 重定向
2. PR 标题必须使用中文，概括当前分支的最终交付内容，不使用英文 Conventional Commits 格式
3. 如果已关联 Issue，在正文中加入 Closes #N
4. PR 正文必须使用中文
5. 如果已关联 Issue，默认继承 Issue 的首个 label 作为 PR label；如果未关联 Issue，则按变更类型推断默认 label：新功能→enhancement、缺陷修复→bug、代码重构→refactor、文档更新→documentation、工具/CI/构建→chore、性能优化→performance、依赖升级→dependencies
6. 创建时默认将 PR 指派给当前登录用户（@me）
7. 变更说明必须严格来源于 git diff、提交记录和 Issue 内容，不编造

7. 创建 PR

Manual 模式

1. 先向用户展示 PR 标题和正文草稿，供其确认
2. 运行以下命令：

   TMPFILE=$(mktemp /tmp/pr-draft.XXXXXX.md)
   # 使用 Write 将 PR body 写入 $TMPFILE
   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 或通知。

3. 命令结束后清理临时文件

Auto 模式

直接执行：

TMPFILE=$(mktemp /tmp/pr-draft.XXXXXX.md)
# 使用 Write 将 PR body 写入 $TMPFILE
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 中提取