prkit

prkit

将当前分支上的提交整理成一份规范的 GitHub 拉取请求：标题遵循仓库的提交风格，正文说明改了什么以及为什么，并附上测试计划；所有内容都从实际差异中推断，而非猜测。通过 gh CLI 创建；如果仓库中有 PR 模板，则沿用该模板。

何时触发

用户想要创建拉取请求：“open a PR”“create a pull request”“raise a PR”“submit this for review”“gh pr create”。如果用户只要标题和正文（“draft the PR description”），则走仅起草路线，该路线绝不会推送、提交，也不会编辑 PR 或议题。

预览与授权

除标签豁免外，prkit 会在每次变更前进行预览并等待确认：创建或编辑 PR，以及提交交接的路径。同步及其强制推送按 gitkit 的同步规则执行，无需预览。**如果调用方携带了用户记录的授权，则该授权所列明的操作无需预览。**afkkit 就是这种情况：用户的无人值守请求授权在议题自己的分支上提交、推送该分支以及创建 PR，因此 prkit 会在不提示的情况下提交交接的 QA 计划并执行 gh pr create，同时在交接说明中注明授权。超出授权范围的操作仍须预览；无人值守的调用方应升级处理，而不是代用户作答，例如：对已发布的分支执行变基并使用 --force-with-lease、推送到其他分支、合并。prkit 绝不会推断调用方未明确说明的授权。

仅起草路线

用户要的是标题和正文，而不是 PR。此路线只读取并打印内容。索引、引用、远程仓库、PR 和议题标签都保持原样。

1. 用一条命令记录初始状态：git rev-parse HEAD && git diff --cached --binary | git hash-object --stdin && git for-each-ref | git hash-object --stdin。不带 -w 的 hash-object 不会写入任何内容。
2. 执行预检中的只读检查。在默认分支或分离的 HEAD 上仍然起草，说明创建 PR 前需要分支，但不要创建任何内容。
3. 执行收集上下文，但不要运行 git fetch，因为这会移动远程跟踪引用。使用 git ls-remote origin refs/heads/<base> 读取远程基础分支的最新提交，并将其与 git rev-parse origin/<base> 比较；如果本地基础分支引用落后，则在草稿中说明。
4. 执行撰写标题和正文，并按照嵌入证明材料（如有）选择材料并检查其时效性。
5. 将标题和正文分别放入代码块中打印。如果 gh pr view 显示该分支已有开放的 PR，则说明此草稿会替换该 PR 的标题和正文。

完成条件：已打印标题和正文；结束时再次运行记录命令，输出相同的提交和相同的两个哈希；且未运行任何 git push、git commit、git rebase、gh pr create、gh pr edit 或 gh issue edit。用一行完成交接：说明没有任何内容发生变化，并指出下一步是让 prkit 根据此草稿创建 PR。

流程

1. 预检

开始撰写前，确认所需工具和分支均已就绪：

gh --version        # gh installed?
gh auth status      # authenticated?
git branch --show-current

• 如果缺少 gh 或尚未通过身份验证，请说明这一点，并指向 https://cli.github.com / gh auth login。不要尝试绕过。
• 如果 git branch --show-current 输出为空，则停止：分离的 HEAD 必须先有分支才能创建 PR。建议创建或切换到一个分支。
• 如果当前分支是默认分支，则停止：PR 需要功能分支。继续前建议创建一个分支（git switch -c <name>），并且从 gitkit 获取名称；分支命名由 gitkit 负责，不要在此处自行臆造格式。可追溯到议题的工作使用 issue-<n>-<slug>；直接在基础分支上修补的紧急问题使用 hotfix-<slug>；其他情况则沿用仓库约定或用户提供的名称。

2. 收集上下文

从 gitkit 获取基分支，然后阅读该分支实际做了哪些更改；这些差异就是标题和正文的原始素材。先获取最新内容，确保以下所有引用都指向真实的远程状态，而非过时的本地副本：

git fetch origin                                         # refresh remote-tracking refs before anything else
git log origin/<base>..HEAD --format='%s%n%b'            # commits in this PR, with their bodies
git diff origin/<base>...HEAD --stat                     # files touched

只有在提交信息无法说明更改时，才阅读完整差异（git diff origin/<base>...HEAD）。 按照此工作流创建的分支通常无需如此，因为 commitkit 会根据更改本身撰写每条提交信息，因此提交日志总结的内容正是 PR 正文所需的素材；从原始差异重新推导，往往会花费更多时间，描述效果却更差。遇到提交信息简略或笼统的情况时，请查看完整差异（例如由 wip 和 fix typo 提交组成的分支，或来自此工作流之外的工作）；如果统计信息显示有文件未被任何提交信息说明，也请查看；或者，当你需要测试计划中的具体细节时，也请查看。无论哪种情况，都跳过锁文件、构建输出和供应商目录。

基准引用解析由 gitkit 负责。 请向它询问基准分支，不要在这里重新推导分支选择顺序；默认分支为 develop 或 trunk 的仓库确实存在，弄错后会悄无声息地产生空差异或巨大差异。如果没有 gitkit，权威的备用方法是 gh repo view --json defaultBranchRef -q .defaultBranchRef.name；如果无法确定，就询问，不要猜测。将当前分支与 gitkit 返回的基准分支重新核对；如果两者相同，就停止。

堆栈中某一层的基准分支是它下方的分支，而不是仓库默认分支。 如果当前分支是堆栈中的一层，gitkit 会返回父分支，以下所有 origin/<base> 都指该分支。这会带来两个结果：差异只包含该层自身的小幅更改，而非整个堆栈，这正是堆栈的意义；并且“当前分支等于基准分支”这一停止条件不会触发，因为某一层的基准分支永远不会是该层自身。请向 gitkit 询问该分支是否属于某一层，不要自行推断；如果没有 gitkit，已有 PR 的备用方法是 gh pr view --json baseRefName，普通分支则与以往完全相同。

请与 origin/<base>（刚刚获取的远程分支最新提交）进行差异比较，而非可能落后的本地 <base>。否则，标题、正文和文件列表都是根据已不再是合并目标的提交计算出来的。

使用提交、分支名称（例如 issue-123-fix-login）和差异，确定范围、变更类型以及任何问题引用（#123、fixes #123）。如果某个关联问题显然很重要，但你找不到它，请先询问，不要凭空编造。

3. 与基准分支同步

推送前，确保分支已与刚刚获取的基准分支最新提交同步。基于过时分支创建的 PR，要么会合并过时的代码，要么会显示 GitHub 的“This branch has conflicts”提示：

git rev-list --left-right --count origin/<base>...HEAD   # "<behind>\t<ahead>"; left > 0 means behind

• 落后 0 个提交：无需操作，前往推送分支。
• 落后：需要将 origin/<base> 合并到分支中。同步规则由 gitkit 负责，具体采用 rebase（git rebase origin/<base>），使 PR 的差异保持简洁。在堆栈中，rebase 会级联执行（gh stack rebase --upstack），因为重放这一层会同时移动其上方的所有层；应交由 gitkit 处理，而不是只对一个分支进行 rebase，导致上方各层仍指向已不存在的提交。无论是否已发布分支，同步都会执行，无需确认；只有遇到问题时，gitkit 才会停下来询问，例如出现需要裁定的冲突或租约被拒绝。如果没有 gitkit，请执行 rebase 并使用 --force-with-lease 推送，遇到上述任何问题时都应停止。
• Rebase 冲突：如果 rebase 因冲突而停止，请自行解决冲突；用户绝不会编辑有冲突的文件。列出有冲突的文件（git diff --name-only --diff-filter=U）。冲突处理规则由 gitkit 负责：它会自行写入机械性解决方案，不会询问；遇到需要做出决定的解决方案时，则会询问用户裁定，然后写入选定方案。如果没有 gitkit，请直接解决可合并双方内容的冲突；任何会丢弃任一方代码的解决方案，都应先询问。然后完成 rebase（git rebase --continue）。工作树未清理且同步未完成前，不要推送，也不要创建 PR。如果用户拒绝同步，请告知 PR 可能会显示冲突，并且只有在用户确认后才继续。

成功完成 rebase 后，不要重新阅读差异。 Rebase 会将你的提交重放到新的基准上，不会改变提交的内容或行为，因此你之前拟定的标题和正文仍能准确描述该分支。唯一例外是你在 rebase 时解决了冲突，因为你在重放过程中实际修改了内容，解决后的结果与之前阅读的内容确实不同。只需重新阅读你在解决冲突时修改的文件（git diff origin/<base>...HEAD -- <paths>），不要阅读整个分支。

4. 推送分支

首先，提交任何交接过来的路径。 如果调用方交给 prkit 一个必须随分支一起提交的文件，通常是 qakit 编写并在交接内容中注明的手动 QA 计划，路径为 docs/qa/NNNN-qa-<slug>-YYYY-MM-DD.md（可以直接交接，也可以通过 afkkit 交接），且该文件尚未提交，请在此处提交，而不是将其遗留或另行安排其他操作。prkit 本就是处理 git 的步骤，而且已获知该路径，因此无需重新查找：

git add -- <handed-in path> && \
git commit -m "docs(qa): add manual QA plan for <feature>" -- <handed-in path> && \
git show --name-only --format= HEAD

末尾的 pathspec 只会提交该路径。其他已暂存的内容仍会保持暂存状态，不会包含在此次提交中。pathspec 提交会使用该路径在工作树中的副本；这正是需要的，因为交接过来的文件应完整随分支提交。git show 这一行必须准确打印交接过来的路径。 输出中出现任何其他路径，都意味着提交有误；应停止并在推送前报告。

只能提交调用方明确指定的路径。这并不是清理整个工作树的许可：未提交且无人提及的工作仍受注意事项中的规则约束，因此应指出并提出处理建议，不要擅自提交。

创建 PR 前，远程分支必须存在：

git push -u origin HEAD

如果分支经过 rebase（与基准分支同步），且远程拒绝了普通推送，请使用 git push --force-with-lease（绝不要单独使用 --force）。此处无需询问：gitkit 的同步规则会执行 rebase，并在无需确认的情况下使用租约推送。租约被拒绝是例外，因为有人推送了新提交；请获取最新提交、展示对方的提交，并在重试前征求确认。

5. 编写标题和正文

• 标题：单行、使用祈使语气，并遵循仓库的提交风格（参照 git log，通常是 Conventional Commits，例如 feat(auth): add SSO login）。末尾不加句号。
• 热修复分支上的标题：名为 hotfix-<slug> 的分支使用 hotfix 类型，因此标题应为 hotfix(scope): restore session cookie on refresh。类型由分支名称决定，而非 Bug 的严重程度，这样在 PR 列表中两者就能一目了然。如果仓库的 PR 标题 lint 会依据 Conventional Commits 类型集进行校验，则改用 fix(scope):，并说明一次你已这样处理。
• 正文：如果存在 .github/pull_request_template.md（或 PULL_REQUEST_TEMPLATE.md），请读取并严格按原样填写，遵循其中的章节和复选框。否则，使用：一段说明改动内容及原因的 Summary、一个 Changes 项目符号列表，以及一个 Test plan（说明如何验证，或列出待运行事项的复选框）。如果有对应议题，请在正文中引用（Closes #123）。
• 优先写出替用户作出的决定。 如果调用方提供了未经用户确认的假设或决定（例如无人值守运行中的 Assumptions，或构建提示中的“我替你作出的决定”），请将它们写在正文第一部分中，置于 Summary 之前，或写在模板第一部分的开头。这些内容是审阅者首先必须核查的，也最容易被埋在长正文的末尾。
• 热修复正文：开头先写用户看到的症状及其触发条件，再写修复方案。添加一行 Rollback，注明还原命令（git revert <sha>），因为热修复通常会在时间紧迫时合并，审阅者需要一眼看到撤销方式。保留测试计划，并明确说明哪些内容无法验证。
• 仅适用于分层 PR 的 Stack map。添加简短章节，说明这一层的位置、其正下方的分支和 PR，以及哪个 PR 会先合并。GitHub 会显示自己的分层导航，因此这里写两三行即可；这样做是为了让通过通知邮件阅读差异的人了解上下文，因为邮件中没有该导航。明确说明此 PR 的目标是下方这一层，而非 trunk，因为误以为目标分支是 trunk 的审阅者会觉得差异不完整。
• 在分层 PR 中，Closes #123 虽然写在正文里，但重新指定目标分支前不会生效。 GitHub 仅会对目标为仓库默认分支的 PR 处理关闭关键词，因此，目标为其他分支时，该关键词只是普通文本，议题链接也不会登记。仍然要写上 Closes #123，因为下方一层合并后，GitHub 会将此 PR 的目标分支重新指定为 trunk，届时该关键词会自动生效。然后在 Stack map 中明确写出这一点，确保备用说明随 PR 一起保留：注明此层要关闭的议题，并说明重新指定目标分支后链接才会登记。如果侧边栏没有显示关联议题，审阅者可能会误以为缺少引用，继而重复添加。

6. 嵌入证明材料（如果存在）

此步骤为可选步骤，仅在存在 verifykit 证明包时运行。verifykit 会在 docs/verify/NNNN-verify-<slug>-YYYY-MM-DD/ 中留下一个带日期的包（slug = 关联的问题编号；否则为功能 slug；较早的包没有 NNNN- 序号），其中包含可直接嵌入的 proof.md。如果匹配项不止一个，使用序号最高的包；若没有序号，则使用创建日期最新的包；如果仍有多个，则询问要使用哪次运行的包。

仅当所选包显示的是此分支的 HEAD 时，才嵌入该包。 verifykit 会打开包中的 notes.md，其中包含以下固定行：commit: <full sha>、dirty: <yes|no>、url: 和 captured:。当文件显示 dirty: no，且记录的提交是 HEAD，或与 HEAD 的差异仅限于文档时，该包即为新鲜：

git diff --quiet <recorded commit> HEAD -- . ':!docs/qa' ':!docs/verify'   # exit 0 = no code change since the capture

排除文档的规则允许 QA 计划提交和包自身的提交在捕获后落地。若包没有 commit: 行、显示 dirty: yes、记录的提交无法通过 git diff 解析（例如 rebase 改写了该提交），或捕获后有任何代码变更，则该包已过期。不要嵌入已过期包中的任何内容，并在交接说明中指出哪个包已过期及其原因；解决方法是重新运行 verifykit。将所选的新鲜证明内容嵌入正文的 Proof 部分。图片已发布到隐藏的 refs/verify-assets/* 引用中，并带有固定 SHA 的原始 URL，可直接以内嵌形式呈现，因此无需上传；只需原样嵌入该片段。如果不存在包，则完全跳过此步骤，并照常创建 PR。如果存在包，但其 proof.md 指向本地路径（verifykit 无法发布，例如在私有仓库中），不要嵌入失效链接；添加简短说明，列出供手动附加的本地材料路径。

7. 创建或更新 PR

先检查此分支是否已有 PR，以便更新而不是重复创建：

gh pr view --json url,state 2>/dev/null

• 如果命令返回的 PR 的 state 为 OPEN：使用 gh pr edit --title "…" --body-file <file> 更新它，而不是再创建一个。
• 如果不存在 PR，或返回的 PR 已合并或已关闭：将正文写入临时文件并创建新的 PR。通过 --body 传递带复选框的多行 Markdown 不够可靠；--body-file 则可靠。

gh pr create --base <base> --title "…" --body-file <bodyfile>
# add --draft when the user wants a draft, or the work is incomplete

正文文件请使用系统临时目录中的路径，并在之后将其删除。

一次打开堆栈的多个层只需一条命令。 gh stack submit 会为每个分支创建一个 PR，并正确设置各自的 base；如果逐个使用 gh pr create，过程繁琐且容易出错。这是 prkit 负责的堆栈功能范围的一部分；gitkit 有意不执行此操作，因为 gitkit 从不打开 PR。

gh stack submit --auto        # a PR per layer, bases already correct

先按上述要求写好每一层的标题和正文，然后提交。只打开单个层时，继续使用简单的 gh pr create --base <parent>，这样更简单，也不会影响其上的层。

对于堆栈中的某一层，检查并报告关闭关联。 每个层级的 PR 创建或更新后，立即运行一次此检查；如果 PR 的 base 是默认分支，则完全跳过：

gh api graphql -f query='{repository(owner:"<owner>",name:"<repo>"){pullRequest(number:<n>){closingIssuesReferences(first:5){nodes{number}}}}}'

• 在堆栈层上结果为空是预期情况，并非失败。 如实报告，并说明解决顺序：下层合并后，GitHub 会将此 PR 的目标分支调整为默认分支，此时 Closes #123 关键字才会生效。没有任何问题，也无需修复。
• 在堆栈层上结果非空，表示 GitHub 已调整 PR 的目标分支。 报告返回的问题编号。
• 不要为了强制建立关联而将 PR 的目标分支改为 trunk。 这样会丢弃堆栈依赖的 base，并使这一层的小型差异变成整个链条的差异。在非默认分支上没有可用于注册关联的 API；gh issue develop 和 createLinkedBranch mutation 都会拒绝已存在的分支。等待下层合并是唯一可行的办法。

8. 推进关联 issue

打开 PR 时，关联的 issue 会从处理中转为等待审核，因此请将其生命周期标签从 in-progress 切换为 in-review（这与 PR 打开时 issuekit 的 sync 模式执行的转换相同）。仅当 PR 引用了 issue 时才执行此操作，也就是说，在收集上下文中找到了 #123 / Closes #123；如果没有，则完全跳过此步骤。

• 如果已安装 issuekit，优先使用它。 调用它来协调标签，以便将跟踪逻辑集中在一处。否则，请自行使用等效的 gh 调用：

gh issue edit <n> --remove-label in-progress --add-label in-review

• 无需询问，直接执行。 在每个步骤中，对所有调用者而言，标签写入都不受 prkit 预览规则限制：标签操作成本低、可见，而且可以通过一条命令撤销；相比未经确认的标签，更糟糕的是 PR 已打开等待审核，而 issue 仍显示正在处理中。请在交接说明中报告标签切换，而不是先提议再执行。
• 此转换仅涵盖两种起始状态，不包括其他状态；两种情况都要替换标签。 对于带有 in-progress 的 issue，执行上述切换。对于带有 ready 的 issue，执行相同形式的替换：--remove-label ready --add-label in-review，并在交接说明中指出该 issue 开始时尚未启动。ready 是一种合理的初始状态，因为 PR 可能是在从未运行过 issuekit start 的工作上创建的；当人类直接完成工作时，这就是常见情况。它不是 start 留下的状态：start 会用 in-progress 替换 ready，因此 PR 打开时仍标记为 ready 的 issue 从未经过该流程。
• 绝不能在已有生命周期标签旁再添加一个。 issuekit 的映射每次恰好只保留一个状态标签，因此带有 ready, in-review 的 issue 是有问题的记录，而不是信息更丰富的记录。所有下游读取方都将生命周期标签视为单一值；第二个标签会导致 statuskit、sync 和 ready 防护对同一个 issue 的状态产生分歧。
• 任何其他生命周期状态都属于状态偏差，而非转换。 如果状态为 blocked、needs-planning、triage、needs-info、已经是 in-review，或完全没有生命周期标签，请停止操作，不做任何更改。报告你发现的状态。有人在场时请询问；无人值守时请升级处理。未经检查的标签，比未设置的标签更糟糕。
• prkit 中的其他所有操作仍需预览。 豁免仅适用于标签写入。创建 PR 和提交已交付的路径仍须遵循预览和授权。
• 如果仓库中缺少 in-review 标签，请让用户联系 repokit，或提供 gh label create in-review --color 5319E7 --description "a PR is open, awaiting review or merge"，并且不要绕过这个缺口进行修改。此豁免免除的是提示，而不是标签配置检查。

9. 解锁此 PR 可堆叠的事项

创建 PR 是一个契机：依赖于此事项的问题可以开始处理，因为代码现在已存在于一个分支上，尽管尚未合并。这样的依赖事项可以从 blocked → stacked，并基于从此分支切出的层构建，而不是一直闲置到评审结束。仅当此 PR 关闭了其他事项所依赖的问题时才执行此步骤：

gh issue view <n> --json blocking                              # issues waiting on this one
gh issue view <dep> --json blockedBy,labels                    # every prerequisite of one dependent
gh pr list --state open --json number,headRefName,isDraft      # open PRs, read once
gh issue edit <dep> --remove-label blocked --add-label stacked

只有满足所有前置条件的依赖事项才能变更状态。 对每个标记为 blocked 的依赖事项，检查其所有前置条件，而不只是此事项。除当前事项之外，当前置条件已关闭，或其未关闭的非草稿 PR 位于当前分支已包含的分支上（git merge-base --is-ancestor origin/<head> HEAD）时，该前置条件才允许变更状态，因为从当前分支切出一层即可包含所有前置条件。通过前置条件的 issue-<p>- 头部分支查找其 PR。低于 gh 2.94.0 时，请读取正文中的 Blocked by #N 行，而不是 blockedBy。

• 某个前置条件尚未关闭且没有 PR → 保持依赖事项为 blocked，并说明是哪个前置条件阻止了它。
• 另一个前置条件有自己的未关闭 PR，且其分支未被当前分支包含 → 依赖事项需要两个堆叠父级，但一层只能有一个。保持其为 blocked，并报告这两个 PR。不要选择其中任何一个。

无需询问即可执行，适用与变更为 in-review相同的标签豁免规则。这些标签会变更一个不同于用户指定的事项，因此请用一行说明完整后果：

PR #51 已创建 → #52 和 #53 从 blocked → stacked，因此现在可以分别基于从 issue-51-oidc-provider 切出的层开始处理。#54 保持 blocked：#49 尚无 PR。

• 仓库中缺少 stacked → 提示使用 repokit，或运行 gh label create stacked --color 006B75 --description "prerequisite is in flight with an open PR; workable now on a branch stacked on it"，不要绕过这个问题进行更改。
• 没有依赖事项，或 PR 是草稿 → 完全跳过此步骤。草稿尚未准备好供后续构建。

**完成条件：**此事项的每个依赖事项都已在检查完所有前置条件后变更为 stacked，或仍保持原状态，并注明阻止它的前置条件或与之竞争的堆叠父级。

10. 交接

本节采用程序性语体：每句话只包含一条指令，使用主动语态和现在时，不使用比喻。

变更内容。 报告已创建或更新的 PR（标题和编号）、是否执行了同步变基、是否提交了移交的路径、是否嵌入了证明部分或因过期而跳过了捆绑包、关联事项是否变更为 in-review、哪些依赖事项变更为 stacked，以及哪些依赖事项保持 blocked 及其原因。当调用方的授权取代预览时，说明调用方以及授权涵盖的操作。

提交位置。 提供 PR URL 和其指向的分支。如果已配置，请说明 CI 将运行。在堆叠层上，请说明其目标分支，并指出该分支不是 trunk。在堆叠层上，还要报告关闭链接检查：说明该事项链接目前不起作用，并说明下层合并且 GitHub 重新指定此 PR 的目标分支后，该链接才会生效。

下一步。 PR 现在等待评审，因此接下来由评审者处理：如果已安装 mergekit，运行 start <n> 会将 PR 拉取到工作树中，以便进行本地评审和 QA；否则请在 GitHub 上评审。刚刚变更为 stacked 的依赖事项优先级更高，因为用户现在就可以开始处理，同时评审也在进行：为优先级最高的依赖事项提供 issuekit start <n>。适用时，先建议而不是自动执行以下小型后续操作：gh pr edit --add-reviewer <user>、--add-label <label>，或对草稿运行 gh pr ready。prkit 的工作到此结束。

备注

• 绝不能在未明确要求的情况下合并、关闭或强制推送。可以创建或编辑 PR；除非收到请求，否则不能运行 gh pr merge。
• 未提交的更改不会包含在 PR 中。如果 git status 显示有暂存或未暂存的工作，而且用户似乎希望将其包含在内，请指出这一点，并询问是否先提交，而不是默默将其遗漏或未经询问就提交。
• 如果分支没有领先于基线（没有提交），请停止并说明没有可创建 PR 的内容。
• 嵌入证明是可选且独立的。 prkit 只会读取 verifykit 的 proof.md 并将其嵌入；它不会运行发布操作（这是 verifykit 的职责，由其自带的脚本执行）。过期的捆绑包按没有捆绑包处理，并在交接说明中加一行提及。没有 verifykit 捆绑包 → 不添加 Proof 部分，prkit 的工作方式与以往完全相同。
• 推进关联 issue 是可选的，且不受预览规则限制。 只有当 PR 引用了 issue 时才会执行状态切换；如果已安装 issuekit，则优先使用，否则回退到普通的 gh issue edit。它会在状态为 in-progress 或 ready 时未经提示直接运行，并拒绝其他所有状态，因为 PR 合理的来源状态只有这两种。豁免适用于该步骤，而非调用方：无论是键盘前的用户还是无人值守的编排器，行为都完全相同，prkit 绝不会扩大豁免范围。没有关联 issue → prkit 按照以往方式创建 PR。
• 如果没有可用的 Shell 或 gh（例如基于浏览器的 Agent），就无法推送或调用 gh。此时请阅读用户提供的差异，并将最终 PR 标题和正文分别放入代码块中输出，供用户粘贴到 GitHub 的“新建拉取请求”表单。