yeet

前置条件

• 必须安装 GitHub CLI gh。检查 gh --version。如果未安装，请让用户安装 gh，然后停止。
• 必须已登录 gh。运行 gh auth status。如果尚未登录，请让用户先运行 gh auth login（然后重新运行 gh auth status），再继续。

命名约定

• 分支：从 main/master/default 开始时使用 {description}。
• 提交：使用简短的 {description}。
• PR 标题：使用概括完整差异的 {description}。

发现 PR 模板

创建 PR 前，先解析仓库根目录，并从该目录查找当前生效的 GitHub PR 模板：

repo_root="$(git rev-parse --show-toplevel)"

模板候选项，按顺序排列：

• .github/pull_request_template.md
• .github/PULL_REQUEST_TEMPLATE.md
• .github/pull_request_template/ 下的一个 *.md 文件
• .github/PULL_REQUEST_TEMPLATE/ 下的一个 *.md 文件

使用相对于仓库根目录的路径，例如 .github/pull_request_template.md，而不是 ./.github/pull_request_template.md。

如果恰好找到一个模板，请在编写最终 PR 正文前阅读该模板，并通过 --template "$template" 将其传递给 gh pr create。

如果找到多个模板文件，请在创建 PR 前停止，并询问要使用哪个模板。如果没有模板，则使用此技能中的备用正文格式。

工作流

• 如果当前位于 main/master/default 上，则创建分支：git checkout -b "{description}"
• 否则留在当前分支。
• 确认状态，然后暂存所有内容：git status -sb，接着运行 git add -A。
• 使用简短描述提交：git commit -m "{description}"
• 如果尚未运行检查，则运行检查。如果检查因缺少依赖项/工具而失败，请安装依赖项并重试一次。
• 使用跟踪信息推送：git push -u origin $(git branch --show-current)
• 如果 git push 因工作流身份验证错误而失败，则从 master 拉取并重试推送。
• 发现并阅读仓库 PR 模板（如有）。
• 检查当前分支是否已有 PR：gh pr view "$(git branch --show-current)" --json number,isDraft,url
• 如果 PR 已存在，就在该 PR 上更新。不要创建另一个 PR，也不要更改现有 PR 是草稿还是可供审查状态。
• 如果没有 PR，则创建新的草稿 PR：
  • 使用一个模板时：GH_PROMPT_DISABLED=1 GIT_TERMINAL_PROMPT=0 gh pr create --draft --fill --template "$template" --head "$(git branch --show-current)"
  • 没有模板时：GH_PROMPT_DISABLED=1 GIT_TERMINAL_PROMPT=0 gh pr create --draft --fill --head "$(git branch --show-current)"
• 编辑 PR 标题和正文，使其反映差异中的实际净变更。
• 将 PR 描述写入包含实际换行符的临时文件，并通过 --body-file 或 gh pr edit --body-file 传递，以避免使用 \n 转义的 Markdown。

确定 PR

更新之前在此流程中创建的 PR 时，尽可能根据当前分支推断 PR：

git branch --show-current
gh pr view "$(git branch --show-current)" --json number --jq '.number'

如果找到现有 PR，则保留其当前审查状态。执行 yeet 时，绝不要将已可供审查的 PR 改回草稿；只有通过此流程创建的新 PR 才应以草稿状态开始。

PR 标题

格式：<type>(<scope>): <subject>

<scope> 是可选的。scope 是用于描述代码库某个部分（组件、服务或子系统）的名词。

示例

feat: add hat wobble
^--^  ^------------^
|     |
|     +-> Summary in present tense.
|
+-------> Type: chore, docs, feat, fix, refactor, style, or test.

更多示例：

• feat：（面向用户的新功能，而不是构建脚本的新功能）
• fix：（面向用户的错误修复，而不是构建脚本的修复）
• docs：（文档变更）
• style：（格式调整、缺少分号等；不更改生产代码）
• refactor：（重构生产代码，例如重命名变量）
• test：（补充缺失的测试、重构测试；不更改生产代码）
• chore：（更新 grunt 任务等；不更改生产代码）

PR 正文内容

调用时，使用 gh 编辑拉取请求的正文和标题，使其反映指定 PR 的内容。请先检查现有拉取请求正文，确认是否有应保留的重要信息。例如，绝不要删除现有拉取请求正文中的图片，因为作者可能无法恢复已删除的图片。

如果仓库中有 PR 模板，请根据该模板调整最终 PR 正文。保留有意义的标题、必需的检查清单和仓库专属提示，但将占位文本替换为与最终差异相关的内容；如果模板要求填写相关内容，也可以写 N/A。不要仅仅因为下面的备用结构更短，就丢弃模板中的部分。

解释为何进行此更改至关重要。如果调用此技能时的当前对话中讨论了更改动机，请务必将其写入拉取请求正文。

正文还应说明更改内容，但应放在说明更改动机之后。

讨论范围限于提交的最终变更。通常不建议讨论在拉取请求开发过程中尝试过、后来又撤销的更改。重写拉取请求正文时，如有此类内容，可能需要删除不再合适或对未来读者无关的信息。

避免提及本地磁盘上的绝对路径。提及仓库中的路径时，直接使用相对于仓库根目录的路径即可。

默认省略 Verification。只有在有值得保留、可供审阅者参考的行为证据时才添加，例如：复现的缺陷、变更前后的检查、覆盖所改行为的定向测试，或输入与观察结果明确的手动场景。不要将通用命令或自动化结果用于此处，例如软件包测试、类型检查、代码检查工具、格式化工具、提交前／推送前钩子或 CI 状态。

如果仓库模板要求包含验证部分，请保留该部分，并避免填写泛泛的内容：提供有意义的命令及结果、定向手动场景，或说明原因并填写 Not run。

使用专业的 Markdown：

• 将代码、路径、命令、标志和标识符放在反引号中。
• 使用围栏代码块展示 Shell 命令记录或多行示例。
• 引用与变更相关的现有代码时，使用 GitHub 永久链接。
• 引用相关议题或其他 PR，但不要在正文中引用该 PR 自身。

建议的 PR 正文结构

如果仓库没有 PR 模板，请将此结构用作备用方案：

## Why

Describe the user-facing or maintainer-facing problem, including cause and effect where useful.

## What Changed

Describe the net implementation change in concise prose.