pr

创建拉取请求

将当前请求中的更改整理为一个可供审核的拉取请求，目标为指定的基分支；如果未指定，则使用远程仓库公布的默认分支。 完成必要的本地 Git 操作，不要要求安装其他技能。

保留无关工作，同时将本请求的更改作为逻辑清晰的 Conventional Commits 提交。不要将凭据和其他敏感文件纳入历史记录，遵守仓库检查，并将分离或受保护检出上的工作移至名称合适的分支。

基于已获取的目标分支创建分支并推送，避免覆盖意外的远程工作。对于相同的头分支和基分支，复用已有的拉取请求；如果该更改已存在于该远程基分支上，则报告当前状态，而不要重复创建。

创建可供审核的拉取请求，并在标题和正文中描述实际更改。如果仓库的 AGENTS.md 或 CLAUDE.md 中包含 ## Issue tracker 章节，请阅读该章节及其链接的详细约定（如果存在）；即使未安装设置技能，也可以使用旧版内联约定。 如果没有该章节，则跳过下方所有 issue 步骤，并保持正文不变。

将每个规格文件夹关联到一个 issue

如果配置了跟踪器，请在创建拉取请求前收集此 PR 涉及的规格文件夹：分支新增或修改的每个 docs/specs/<slug>/ 文件夹，以及每个由 Spec-Folder: docs/specs/<slug>/ 提交尾注指定且在头分支上仍存在的文件夹。跳过分支删除的文件夹。文件夹的 spec.md 中有一行 Issue: <tracker>:<id>，该 ID 即为其 issue；不要创建 issue。

对于每个没有该行的已收集文件夹，按照约定的创建操作创建一个 issue：标题为 spec.md 的第一个标题，不加前缀；正文为根据约定的规格章节标记，从 spec.md 中呈现的一个规格章节；issue 还应包含约定的审核标记，确保一般分流在 PR 关联该 issue 之前不会处理它。该章节应包含第一个章节的正文、其余章节标题、文件夹路径，以及 Blocked by: docs/specs/<other>/ 行所列文件夹对应的 issue（从这些文件夹自己的 Issue: 行读取）；如果某个阻塞文件夹没有 issue，请报告该文件夹。然后按照约定的 ID 格式，在规格文档其他链接旁写入 Issue: <tracker>:<id>，并在同一分支上提交；只有完成后才能推送并创建 PR。

绝不要通过标题搜索跟踪器来查找或复用 issue。如果 issue 已创建，但无法提交该行，则停止，不要创建 PR，并报告已创建的 ID，以便重跑时记录该 ID，而不是再次创建。

在 PR 正文中为每个已关联的 issue 添加一行 Issue: <tracker>:<id>，以便后续在分支消失后仍能找到 PR。对于没有规格文件夹、但直接修复已知 issue 的 PR，也应添加相同的行。只有在差异和验证表明确实交付了该 issue 的实现时，才在正文中添加约定的关闭引用；仅有提交尾注或 Issue: 行并不能证明已交付。仅包含规格的 PR 应关联其 issue，但不添加关闭引用。复用已有 PR 时，也执行相同步骤并使其正文符合要求。合并、必需审核和发布决策不属于此技能的权限范围。

如果无法读取关联的约定，请报告缺失的信息，不要猜测 issue 操作，也不要声称 issue 已关联或关闭。

让正文易于理解

面向不了解对话历史的评审者撰写：说明问题、具体的变更前后行为、变更原因，以及验证结果能证明什么。根据变更规模调整说明内容；修正拼写错误只需简要描述和相关验证。必要时说明实现机制、复杂流程的示意图、实际备选方案及其权衡、受影响的用户或集成，以及有助于评估变更的具体未决判断。确保整项变更都易于理解，而不只是突出这些判断；省略空洞的章节和编造的备选方案或问题。

对于界面变更，让评审者能直观看到他们要评估的行为。录制基准版本和头部版本运行相同流程的视频，并确保视口、数据和状态一致；或者复用已验证与这两个版本相匹配的证据。嵌入变更前后的视频，并简短说明差异及原因。如果动态效果无助于评估，例如文案、样式或静态布局变更，则改为并排比较截图；如果行为变更还伴有此类细微视觉差异，则在视频之外附上静态对比图。没有变更前状态的界面只需提供头部版本的视频。如果无法录制视频、无法安全处理视频，或裁剪到能展示所评估的行为后仍无法满足附件大小限制，则改为比较截图并说明缺少视频的原因。视频不需要替代文本，因此应为每段视频标注其版本、流程和条件，并指出录制过程中无法避免的差异。区分观察到的结果、从源码推断的结果和未经验证的状态；原型不是运行时证据。更新现有 PR 时，应使其说明和证据与最终变更一致，并替换过时的视觉描述。

上传前，检查截图和视频中是否包含凭据、个人数据和隐私信息。使用安全的预置数据，或在所有媒体中遮盖这些信息，同时确保对比条件和相关变更仍清晰可见。仅将检查过且安全的媒体作为 GitHub 附件上传，并使用当前环境支持的方式。对于 GitHub CLI，请确认是否支持附件：在受支持的版本中，gh pr create 和 gh pr edit 接受可重复使用的 --attach 参数，并会将 --body-file 中匹配的本地媒体引用替换为已上传的 URL。可使用 Markdown 表格将两张图片并排放置。每段视频都应单独放在一个前后有空行的段落中，并使用 ![](path) 引用，以便将其渲染为播放器；如果引用嵌在其他文本中，则会渲染为链接；未引用的附件会出现在正文末尾。将评审截图保存在仓库历史记录之外；无需单独的媒体托管服务。

如果无法执行基准版本、录制视频或上传媒体，请说明具体限制，并仅提供已获得的证据。报告证据可供评审者查看之前，先检查最终的远程正文和附件；本地路径并非已发布的附件。部分上传仍可能创建 PR：检查并修复该 PR，而不是重复创建。替换远程正文时，保留其中已成功上传的附件 URL；如果无法恢复，则将不可用的本地引用替换为如实说明的限制。

完成

在远程 PR 处于就绪状态，且用户已获得其 URL、基准版本、头部分支，以及任何仍待处理的检查或证据后，即可完成。